Re: [dm-crypt] keys from RAM dumps, hibernation files

["Michael Enßlin" <michael@ensslin.cc>]

[-- Attachment #1: Type: text/plain, Size: 3433 bytes --]

Hi,

LuksClose _should_ wipe all remains of the key from memory.

It's possible to dump the memory without "logging in", e.g. via PCMCIA
and Express Card slots, or by quick-freezing the DIMMs and plugging them
into a different machine.

If you suspend-to-disk, the key will obviously be written to disk;
depending on your disk type it will be hard to safely wipe it again, ever.

If you suspend-to-RAM, the key will obviously stay in RAM and be suspect
to the above attack.

There is a kernel module called
[TRESOR](https://www.usenix.org/event/sec11/tech/full_papers/Muller.pdf)
that allows storing the Key in the CPU's debugging registers instead of
the memory; this should greatly add to the security of the system; An
attacker would require root permissions on your system.

A much easier solution is to use LuksSuspend, which will wipe the key
from RAM and make the partition/filesystem in question block until
LuksResume is called and given the new password. I'm using a script that
automatically calls LuksSuspend on my /home partition before calling the
screen locker, and calls LuksResume on PAM authentication (my LUKS
password equals my login password).

Lastly, there's of course always the (very small) possibility of a
backdoor in LUKS and/or dmcrypt; e.g. LUKS could write the key to some
point of the LUKS header, dmcrypt could store the key somewhere in
memory, or LuksSuspend/LuksClose could simply not fulfill its guarantee
to wipe the key from memory.

 ~ Michael

On 13/11/14 15:21, Lars Winterfeld wrote:
> Hi,
> 
> today, the German news site heise leaked a list of password hacking
> software, that the German police buys and is particular happy with. One
> of those tools is the "Elcomsoft Forensic Disk Decryptor" promising
> access to BitLocker, PGP and TrueCrypt volumes:
> http://www.elcomsoft.co.uk/efdd.html
> 
> What they say about their method is only that it "acquires protection
> keys from RAM dumps, hibernation files". Now I wonder, how does this
> attack work exactly and how vulnerable is cryptsetup against it in a
> linux environment?
> 
> Suppose THEY have the device in their hands.
> 
> I guess the attack is easiest when I suspended to disk, because all
> information needed for decryption (of the mounted crypt volumes) is
> stored in plain on the disk?
> 
> When I suspend to RAM and they wake the device up again, they need to
> hack the login screen? (It was screwed up in Ubuntu in the last version,
> but that is not an issue here.) Nevertheless, they might press
> Ctrl+Alt+Entf to reboot, insert a CD or flash drive, boot from that,
> while the RAM was still powered all the time and read the necessary
> information (...?) from the RAM?
> 
> What about later, when the volume is luksClosed? Are there left-overs of
> previous suspend files (e.g. on swap), that can be used for an attack?
> 
> I guess there is a conceptional problem: if the device comes back from
> sleep without having to re-type the password, something allowing access
> to the encrypted volume needs to be stored in plain? Would it increase
> the security if everyone is required to re-type the password (or provide
> the key-file again etc.)?
> 
> Best wishes,
> Lars
> 
> 
> 
> _______________________________________________
> dm-crypt mailing list
> dm-crypt@saout.de
> http://www.saout.de/mailman/listinfo/dm-crypt
> 



[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]