[dm-crypt] Retrieve the Passphrase from RAM Memory

Milan Broz mbroz at redhat.com
Tue Sep 27 13:50:32 CEST 2011


On 09/27/2011 04:34 AM, Eduardo Schultze wrote:
> Hello,
> I'm a Security Information student at Unisinos College, Brazil. As a
> paper during this semester it was me and my colleagues choice to
> write a paper about LUKS on Ubuntu 10.4.

Better to not analyze beta versions of cryptsetup which
Ubuntu uses in some stable distros (1.1.0~rc2) but check latest upstream.
(And there are some new things related, see below.)

> My question is -  Is it possible to retrieve the passphrase from RAM
> memory after a successful authentication and shutdown? Is this case
> we would turn the system on, authenticate, turn off, and then check
> if the passphrase would still be in the RAM memory even with the
> turned off computer.

Firstly, I guess you want to get encryption key from RAM, not passphrase.
Passphrase should never be in memory after it was used to unlock
encryption key.

Secondly, this is mainly about kernel dm-crypt, not LUKS.
(userspace cryptsetup just configure dm-crypt mapping and no longer
resides in memory. But it should wipe memory as well of course).

Dm-crypt mapping always wipe keys on deactivation from memory.
So proper deactivation (luksClose) is enough.

The problem is that most of current distros (including Ubuntu)
cannot correctly deactivate dmcrypt mapping if it is used below
root filesystem.

This means that key remains in memory after reboot (dmcrypt device
was not deactivated at all here).

I have several discussions about this problem suggesting "shutdown ramdisk".
Similar idea is already implemented in Fedora rawhide
(dracut/systemd is able to deactivate root mappings properly - not
sure if it works but code was in place already).

For dmcrypt & encryption key:

1) configuration path
Key for configuration is sent through dm-ioctl to kernel.
Recent cryptsetup & kernel has DM_SECURE_SUPPORTED flag which tells
device-mapper to wipe all buffers immediately after use
(in fact this was inspired by FIPS140 requirements.)

So when key is set, all kernel buffers for ioctl should be wiped.
(The same applies for userspace cryptsetup, for key there is
crypt_free_volume_key() wrapper which wipes memory after use).

2) active state:
There are two places, where key in memory resides when dmcrypt
device is active.
First is copy of key inside dmcrypt structure (we need to have this
available for "dmsetup table" ioctl.)
Second is active key in cryptoAPI engine.

Both cases above are analyzed, read
http://events.ccc.de/camp/2007/Fahrplan/events/2002.en.html (first case)
http://citp.princeton.edu/research/memory/ (cryptoAPI keys)

(All mentioned programs above need some slight changes but works
in principle.)

(side note: most of the ideas trying to use cpu registers for AES
like TRESOR, Loop Amnesia or Frozen cache usually ignore the first
problem and focus only on AES implementation.)

3) dm-crypt (and cryptsetup through luksSuspend command) provides
way how to temporarily wipe key from memory.
Search list archive, I replied several times here how it works.

> If not, would it be possible to dump the RAM memory and retrieve the
> passphrase (now with the system turned on)?

(In theory, passphrase can remain in is some tty buffers or so,
this is generic problem not related to dmcrypt.)

> I looked for these answers at the FAQ section but couldn't find it.

Google search is your friend ;-)


I spent quite a lot of time to fix kernel side but if anyone do some
independent review (both of userspace and kernel) it is always welcome,
patches of course welcomed too ;-)

More information about the dm-crypt mailing list