[dm-crypt] Dmcrypt and hibernate key disclosure
mbroz at redhat.com
Tue Jan 11 18:08:14 CET 2011
On 01/11/2011 05:35 PM, Richard wrote:
> On Tue, Jan 11, 2011 at 11:31:37AM +0100, Milan Broz wrote:
>> What is not safe is suspend to RAM. Maybe someone should start to use
>> luksSuspend to at least clear encryption key from memory but it is not
>> as easy implement as it seems:)
> surely luksSuspend would make it safer but still complete RAM would be left
> unprotected which can be a lot of information. Did anyone look inot encrypting
> RAM before suspend?
That's not probably easily done and I think it is not worth to try - simple
use hibernation here.
(Of course if there is support in hw it is easy.)
> As it is now it is also not trivialy broken - getting the filesystems would
> involve breaking screen saver locking, breaking in through network or other
> interfaces or freezing the computer to retrieve and examine ramchips.
Just reset and boot memory dumper, chances that you get the encryption key are
very high (memory dumper uses just few pages and BIOSes do not wipes memory
during reboot). It is quite easy.
(of course you can disable USB/PXE/CDROM boot etc but in principle it is still problem.)
> seems dm or something else is slow enough that id does not matter at all.
LVM (linear mapping) will not slow down it, with comparison to encryption
time for remapping is completely insignificant.
If you have some strange numbers, report a bug and add your configuration description,
but I know how the kernel works - there is really nothing complex on this path.
Usually problem is with some misaligned devices - but this can happen even with partitions.
More information about the dm-crypt