[dm-crypt] Retrieve the Passphrase from RAM Memory

[dm-crypt] Retrieve the Passphrase from RAM Memory

[Eduardo Schultze]

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

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.

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.

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

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

Thanks in advance,
Eduardo Schultze.

[-- Attachment #2: Type: text/html, Size: 747 bytes --]

Re: [dm-crypt] Retrieve the Passphrase from RAM Memory

[ken]

These questions first require an understanding of RAM and how it 
functions in any computer.  That said, the short answers to your two 
questions is no, except that recently some researchers have found it 
possible to freeze RAM shortly after a machine was turned off-- within 
seconds-- and thereby preserve it's state and so then retrieve data from 
it.  This is not a procedure most of us could carry out.  And then 
whether the password still is (or ever was) in RAM is another question. 
  Having written a little code in my time, I would sincerely guess not; 
limiting a variable's scope and even overwriting the value of a variable 
are too easy and here obvious *not* to do.  A better answer than mine, 
however, would be found by examining the code.

hth,
ken

-- 
War is a failure of the imagination.
         --William Blake



On 09/26/2011 10:34 PM 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.
> 
> 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.
> 
> If not, would it be possible to dump the RAM memory and retrieve the 
> passphrase (now with the system turned on)?
> 
> I looked for these answers at the FAQ section but couldn't find it.
> 
> Thanks in advance,
> Eduardo Schultze.
> 
> 
> ------------------------------------------------------------------------
> 
> _______________________________________________
> dm-crypt mailing list
> dm-crypt@saout.de
> http://www.saout.de/mailman/listinfo/dm-crypt

Re: [dm-crypt] Retrieve the Passphrase from RAM Memory

[Arno Wagner]

On Mon, Sep 26, 2011 at 11:34:05PM -0300, 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.
> 
> 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.

No. The passphrase is not stored and the PBKDF2 iterations
prevent reconstructing it.

However, you can get the master key. DRAM keeps state only for 
seconds after turn-off. You can freeze the RAM (I pelive some people 
around Ross Anderson have done that with some success) to extend that 
time.
 
> If not, would it be possible to dump the RAM memory and retrieve the
> passphrase (now with the system turned on)?
> 
> I looked for these answers at the FAQ section but couldn't find it.

They are not there, because they have low relevance in practice. 
If somebody gets access to the physical machine while
the container is unlocked, you should assume they can get access
to the data. They would still not get the passphrase.

For the memory-dump, you can extrapolate the techniques used
in FAQ item 

   "How do I recover the master key from a mapped LUKS container? 

Or you can just try every 256 bit word from the memory dump. 
As you do not need iterations if you have the master key, that 
should be doable pretty fast. Incidentally, that is one of the
ways DeCSS (break of DVD encryption) got the key from a software
player.

As to your paper, good choice! I also suggest you put in
a section about LUKS usability (of paramount importance
with security software, but often forgotten) and the typical
problems people have. The mailing-list archive should 
provide plenty of examples.

Is the paper going to be in english? If so, I would like
to get a copy once it is finished. Might be instructive to
get an outside view.
 
Arno
-- 
Arno Wagner, Dr. sc. techn., Dipl. Inform., CISSP -- Email: arno@wagner.name 
GnuPG:  ID: 1E25338F  FP: 0C30 5782 9D93 F785 E79C  0296 797F 6B50 1E25 338F
----
Cuddly UI's are the manifestation of wishful thinking. -- Dylan Evans

If it's in the news, don't worry about it.  The very definition of 
"news" is "something that hardly ever happens." -- Bruce Schneier 

Re: [dm-crypt] Retrieve the Passphrase from RAM Memory

[Roscoe]

Hey Eduardo,

What's your C like? :)

It used to be that cryptsetup would do a lot of `memset(p, 0, n);
free(p)', I always wondered if that memset could optimized away but
never bothered to look.

Are you wanting to retrieve the passphrase or the key? The former is
only required on the system for a short period while luksOpen (amongst
others) is running. That should hopefully not be recoverable
afterwards - though potential bugs like the above mean it may be.

The key is much different as it is always there as long as the mapping
(# dmsetup table --showkeys |grep crypt) exists.

If you pulled the power, I expect the key would still be in RAM. I'd
like to think after a clean shutdown it wouldn't be. Keep in mind that
while the key is most obvious thing to look for, other structures used
by the respective algorithm may be just as useful (I'd start by
looking at the key schedules for which ever ciphers you're interested
in).

-- Roscoe


On Tue, Sep 27, 2011 at 12:34 PM, Eduardo Schultze
<duduschultze@gmail.com> 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.
>
> 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.
>
> If not, would it be possible to dump the RAM memory and retrieve the
> passphrase (now with the system turned on)?
>
> I looked for these answers at the FAQ section but couldn't find it.
>
> Thanks in advance,
> Eduardo Schultze.
>
> _______________________________________________
> dm-crypt mailing list
> dm-crypt@saout.de
> http://www.saout.de/mailman/listinfo/dm-crypt
>
>

Re: [dm-crypt] Retrieve the Passphrase from RAM Memory

[Roscoe]

On Tue, Sep 27, 2011 at 8:17 PM, Arno Wagner <arno@wagner.name> wrote:
...
> No. The passphrase is not stored and the PBKDF2 iterations
> prevent reconstructing it.
...

Looking into the PBKDF2 function would also be valuable, I notice the
buffer for T_i is allocated off the stack and doesn't look to be
explicitly wiped. Presumably some but hopefully all of it gets
overwritten as the program runs :)
(I notice the gnupg devs use a burn_stack() function that attempts to
explicitly achieve this).

So much fun to be investigated!

Re: [dm-crypt] Retrieve the Passphrase from RAM Memory

[Milan Broz]

Hi,

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 ;-)

Milan

p.s.
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 ;-)

Re: [dm-crypt] Retrieve the Passphrase from RAM Memory

[octane indice]

En réponse à Eduardo Schultze <duduschultze@gmail.com> :
> 
> 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.
> 
> 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.
> 
The passphrase, I don't think so, but the master key, yes
for sure.
Here is a paper in french (maybe google translate can
help) where somebody gets the master key, then use it 
for reading data:
http://sylv1.tuxfamily.org/2008/240/gout-de-luks.html

Hope this helps

> ------------------------------------------




Envoyé avec Inmano, ma messagerie renversante et gratuite : http://www.inmano.com

Re: [dm-crypt] Retrieve the Passphrase from RAM Memory

[Milan Broz]

On 09/27/2011 01:53 PM, octane indice wrote:
> The passphrase, I don't think so, but the master key, yes
> for sure.
> Here is a paper in french (maybe google translate can
> help) where somebody gets the master key, then use it 
> for reading data:
> http://sylv1.tuxfamily.org/2008/240/gout-de-luks.html

hm this is naive approach but just illustrate the problem
that distros ignore deactivation of dmcrypt mapping during shutdown.

if you are superuser, you can always get volume key (so far)
dmsetup table --showkeys

also see
http://code.google.com/p/cryptsetup/source/browse/trunk/misc/luks-header-from-active
(recreating LUKS header from active device & volume key)

Milan

Re: [dm-crypt] Retrieve the Passphrase from RAM Memory

[Karl O. Pinc]

On 09/27/2011 06:50:32 AM, Milan Broz wrote:

> 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 ;-)

Speaking of patches, I sent some doc patches to this
list a month or so ago and there was never any comment
or acknowledgment.  Is this the right place to send
such stuff?




Karl <kop@meme.com>
Free Software:  "You don't pay back, you pay forward."
                 -- Robert A. Heinlein

Re: [dm-crypt] Retrieve the Passphrase from RAM Memory

[Milan Broz]

On 09/27/2011 04:44 PM, Karl O. Pinc wrote:
> Speaking of patches, I sent some doc patches to this
> list a month or so ago and there was never any comment
> or acknowledgment.  Is this the right place to send
> such stuff?

Sorry, seems it was lost in my unread mail while I was traveling. 

Man page fix is applied now, specification changes will be applied
later (I'll include that file in 1.4 release).

Thanks,
Milan