All of lore.kernel.org
 help / color / mirror / Atom feed
From: Lars Winterfeld <lars.winterfeld@tu-ilmenau.de>
To: dm-crypt@saout.de
Subject: [dm-crypt] keys from RAM dumps, hibernation files
Date: Thu, 13 Nov 2014 15:21:26 +0100	[thread overview]
Message-ID: <5464BE66.1090508@tu-ilmenau.de> (raw)

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

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


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

             reply	other threads:[~2014-11-13 14:45 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-11-13 14:21 Lars Winterfeld [this message]
2014-11-13 16:35 ` [dm-crypt] keys from RAM dumps, hibernation files Michael Enßlin
2014-11-13 23:33   ` Sven Eschenberg
2014-11-14  7:31     ` Milan Broz
2014-11-14  7:06 ` Heinz Diehl

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=5464BE66.1090508@tu-ilmenau.de \
    --to=lars.winterfeld@tu-ilmenau.de \
    --cc=dm-crypt@saout.de \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.