Message-ID: <5464BE66.1090508@tu-ilmenau.de>
Date: Thu, 13 Nov 2014 15:21:26 +0100
From: Lars Winterfeld <lars.winterfeld@tu-ilmenau.de>
MIME-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha1;
 protocol="application/pgp-signature";
 boundary="q7iVejAh6gFxKMv7IVjoojANIePB0oS7I"
Subject: [dm-crypt] keys from RAM dumps, hibernation files
To: dm-crypt@saout.de

This is an OpenPGP/MIME signed message (RFC 4880 and 3156)
--q7iVejAh6gFxKMv7IVjoojANIePB0oS7I
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable

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


--q7iVejAh6gFxKMv7IVjoojANIePB0oS7I
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

iQIcBAEBAgAGBQJUZL5nAAoJEA4jvzLPLJH4eEMP/1yugvTATMNX5WuGTpdjARwO
mwqaBu82n9cmRlkvUsrrBi6VWxGw+ybuNGTroJyiHZmIYuYuwfoaoCOx7iHX5A4Y
COVLxYPVe6AMLXou7emvqhH3mb8Vh7xsw/VFOG/y6k3f67Pv1vPn+XyveMavRFjw
z1UEIZj4/VyUZGUgpFx//jUbj+yuPRCiJgDBkLGqmHh97GekM8AAGKxnaKmU6TWu
yw7WzOjMSHZOpggJnV7q062vxbrEUCtjnZthTQEiW9Vh8/AbO0RM7qFV+309k9lw
7Xeba0Q1Vc2ZUu6Iscu6GKQ2pIkLw5D1yxtweAbWb9cELiJGTveV2QZam/jtluVM
qV/rJ8qvVWdUMja8t69KfsNoPw3e08sRzJ2DqYyc7wlSQqd+/0RipIfo1d3zlKk3
pCcx3cecwT4U/TjLw1Vb04udD4E4Z2ChOdP8NC+gD9zWxKQLsnDtWEce1J6QRZAf
G7no6VIXjoAL1NA6VqEvG7kUFQFI6YHqhoi4V6bfuokDG1+HTLJxQCIZjhl+E5wh
2lGvBPDK7ISpN+wlE17J3uvlpKtFcyO2Wh1d6CRVIEsaYFiC9w316Bi9NhQhwCkr
xyj0F6hwdFTztagqQVTmcELVEaBQlgpMcuXYRzxvFq1ewNV0AJ3F7AQWqIDuXGfE
/sKgu73LYePDEqg+80vA
=scz2
-----END PGP SIGNATURE-----

--q7iVejAh6gFxKMv7IVjoojANIePB0oS7I--