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@xxxxxxxx > http://www.saout.de/mailman/listinfo/dm-crypt >
Attachment:
signature.asc
Description: OpenPGP digital signature
_______________________________________________ dm-crypt mailing list dm-crypt@xxxxxxxx http://www.saout.de/mailman/listinfo/dm-crypt
