Pieter de Boer wrote:
> Atom Smasher wrote:
>> article below. does anyone know how this affects eli/geli?
>>
>> from the geli man page: "detach - Detach the given providers, which
>> means remove the devfs entry and clear the keys from memory." does
>> that mean that geli properly wipes keys from RAM when a laptop is
>> turned off?
>>
>>

> The attack you're referencing is carried out by cold rebooting a system.
> Simply put: pull power cord, insert power cord. The volumes are never
> detached, as the shutdown sequence is never run.
>
> This attack has to be defended against in hardware; it exploits a
> 'feature' of modern day RAM chips, which can not be controlled by
> software. Anything that is in RAM when the attack is carried out, will
> be compromised. As encrypted volumes simply require keys to be in memory
> to be able to use the volumes, the encryption software is vulnerable to
> this attack. I see no reason why GELI/GBDE wouldn't be affected.
>
> A possible counter-measure would be to add wiping features to the RAM
> modules themselves. When power is lost, the memory could wipe itself.
> Still not perfect, but would certainly help.
>


There are (at least) two attack methods. One is indeed based on memory
chips that retain their data after a shutdown, and software can't easily
protect against this attack. The only way I can think would be to
reserve a processor register for storing the encryption key.

However, a second attack method is based on rebooting a hibernated
machine with a different operating system and retrieving the encryption
keys from the hybernation dump. One can protect against this attack by
having the hybernation sequence unmount the encrypted filesystems and
wipe out the keys from memory.

Diomidis Spinellis - http://www.spinellis.gr
_______________________________________________
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/lis...reebsd-hackers
To unsubscribe, send any mail to "freebsd-hackers-unsubscribe@freebsd.org"