On Thu, November 13, 2014 17:35, Michael Enßlin wrote: > Hi, > > LuksClose _should_ wipe all remains of the key from memory. Actually unmapping the crypto target in dm-crypt should do that. The luksClose operation of cryptsetup is one example that initiates unmapping. > > 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. HW hotplugging creates plug events which can trigger an unmapping in turn. Assuming the hotplug is not compromised on HW-level in a way that a plug event's IRQ can be completely suppressed that is. Pulling the RAM needs opening the case which can be detected and the targets can be unmapped. So cut power, open case and freeze would be the steps for a cold boot attack - the time frame will be the limiting factor of a success. > > 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 the disk with the image is encrypted the key will not be easily available. But you'll need to supply the PW on a resume and move all the way through early boot to get to this point. So it's probably pointless to use hibernation anyways. > > If you suspend-to-RAM, the key will obviously stay in RAM and be suspect > to the above attack. The cryptovolumes can be suspended though ... > > 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. Which assumes these registers cannot be easily dumped outside the active OS. If there's debug registers there's usually an easy way to monitor/dump them even without OS interaction. That possibility might be 'undocumented' though and might need some sort of NDA to get an insight on ;-). > > 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). One of the nasty things with cryptsetup is, that cryptsetup is required to suspend/resume and that cryptsetup may not reside on any of the suspended volumes. (Making cryptsetup available in some tmpfs can probably work around this easily, I guess). > > 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. dmcrypt will have to store the key in memory as long as the mapping is active (and not suspended) ... Regards -Sven > > ~ 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 >> > > > _______________________________________________ > dm-crypt mailing list > dm-crypt@xxxxxxxx > http://www.saout.de/mailman/listinfo/dm-crypt > _______________________________________________ dm-crypt mailing list dm-crypt@xxxxxxxx http://www.saout.de/mailman/listinfo/dm-crypt
