From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-wi0-f170.google.com (mail-wi0-f170.google.com [209.85.212.170]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mail.server123.net (Postfix) with ESMTPS for ; Thu, 13 Nov 2014 17:35:16 +0100 (CET) Received: by mail-wi0-f170.google.com with SMTP id r20so2467131wiv.3 for ; Thu, 13 Nov 2014 08:35:15 -0800 (PST) Received: from [10.4.2.42] (p5DDE5B53.dip0.t-ipconnect.de. [93.222.91.83]) by mx.google.com with ESMTPSA id cv7sm36167214wjc.3.2014.11.13.08.35.13 for (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 13 Nov 2014 08:35:14 -0800 (PST) Message-ID: <5464DDBF.7080903@ensslin.cc> Date: Thu, 13 Nov 2014 17:35:11 +0100 From: =?windows-1252?Q?Michael_En=DFlin?= MIME-Version: 1.0 References: <5464BE66.1090508@tu-ilmenau.de> In-Reply-To: <5464BE66.1090508@tu-ilmenau.de> Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="6X2PPuCWMDJKeQ6OHGb57vneEpmon6f8s" Subject: Re: [dm-crypt] keys from RAM dumps, hibernation files List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: dm-crypt@saout.de This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --6X2PPuCWMDJKeQ6OHGb57vneEpmon6f8s Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable 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= =2E 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, >=20 > 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 >=20 > 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? >=20 > Suppose THEY have the device in their hands. >=20 > 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? >=20 > 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? >=20 > What about later, when the volume is luksClosed? Are there left-overs o= f > previous suspend files (e.g. on swap), that can be used for an attack? >=20 > 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 provid= e > the key-file again etc.)? >=20 > Best wishes, > Lars >=20 >=20 >=20 > _______________________________________________ > dm-crypt mailing list > dm-crypt@saout.de > http://www.saout.de/mailman/listinfo/dm-crypt >=20 --6X2PPuCWMDJKeQ6OHGb57vneEpmon6f8s Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQIcBAEBAgAGBQJUZN3CAAoJEOGPxFKGw/SGOGIP/AgHJ0oBfe7uXko5wAWS8x2I i+RrghOZx4J/P8JRw5qh5JLCvLf6l6exlRunS7aPGZ3cX0dgcMtHenVN6Voq70lT AmkJxJly2KeqNtZ4Fu/t5tssbf4NiE4vG5eeVet9TnOJLOmU52SBAi5GvMGtRKwG eG0Sv5d2RyL+YXFhk7frm/tr38z8ogmtqHvD64RXkOQ5Ufl5Fhr1gywAiaStG5gu DMA9wT8fQ0BItnK3qDZMhT4vliawSStX5Z0zhrnMm6kSBlUc9auqh2b2QTelXKmJ sYLRORm6kXXQC1qe2PBzy1bsw+phU3XtQH1lyll1c1BSZwEDSTXqp2nk4ZTtMNfz 8xFMygyG56lA7W/W30OWYu1YqX/yj0nlMoLwQK8VvY4I4Kk5lH6dFAoOlbL+eBkZ Q6ii/qkSSWVISESD8V4+cY3rRMM3qVEYrUU1c7h4/Kz+2LlHLe5q/rD0V0wrj9jx BdnHuswWgnoo9zOJqvkQAeQwXN21mntt2NygeO+yVBkvbxXbKcXTTK+WLG7ryfFK LdB8SuWZsAkcRMopS5fewKQkvBz/s9UferbDXbh/xmb815P8r17HaCIrwZXncdXd rkrem1SjgCsKq3LP/aq38juQz7sSIEObgqo8TV1Y3m//MtPa5uSxyzXw1jHZot69 W+1Z0RjAZ2xMoOG9j3/O =NMk2 -----END PGP SIGNATURE----- --6X2PPuCWMDJKeQ6OHGb57vneEpmon6f8s--