[dm-crypt] keys from RAM dumps, hibernation files

[dm-crypt] keys from RAM dumps, hibernation files

[Lars Winterfeld]

[-- 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 --]

Re: [dm-crypt] keys from RAM dumps, hibernation files

[Michael Enßlin]

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

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.

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,
> 
> 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
> 
> 
> 
> _______________________________________________
> dm-crypt mailing list
> dm-crypt@saout.de
> http://www.saout.de/mailman/listinfo/dm-crypt
> 



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

Re: [dm-crypt] keys from RAM dumps, hibernation files

[Sven Eschenberg]

On Thu, November 13, 2014 17:35, Michael Enßlin wrote:
> Hi,
>
> LuksClose _should_ wipe all remains of the key from memory.

Actually unmapping the crypto target in dm-crypt should do that. The
luksClose operation of cryptsetup is one example that initiates unmapping.

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

HW hotplugging creates plug events which can trigger an unmapping in turn.
Assuming the hotplug is not compromised on HW-level in a way that a plug
event's IRQ can be completely suppressed that is. Pulling the RAM needs
opening the case which can be detected and the targets can be unmapped. So
cut power, open case and freeze would be the steps for a cold boot attack
- the time frame will be the limiting factor of a success.

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

If the disk with the image is encrypted the key will not be easily
available. But you'll need to supply the PW on a resume and move all the
way through early boot to get to this point. So it's probably pointless to
use hibernation anyways.

>
> If you suspend-to-RAM, the key will obviously stay in RAM and be suspect
> to the above attack.

The cryptovolumes can be suspended though ...

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

Which assumes these registers cannot be easily dumped outside the active
OS. If there's debug registers there's usually an easy way to monitor/dump
them even without OS interaction. That possibility might be 'undocumented'
though and might need some sort of NDA to get an insight on ;-).

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

One of the nasty things with cryptsetup is, that cryptsetup is required to
suspend/resume and that cryptsetup may not reside on any of the suspended
volumes. (Making cryptsetup available in some tmpfs can probably work
around this easily, I guess).

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

dmcrypt will have to store the key in memory as long as the mapping is
active (and not suspended) ...


Regards

-Sven

>
>  ~ Michael
>
> On 13/11/14 15:21, Lars Winterfeld wrote:
>> 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
>>
>>
>>
>> _______________________________________________
>> dm-crypt mailing list
>> dm-crypt@saout.de
>> http://www.saout.de/mailman/listinfo/dm-crypt
>>
>
>
> _______________________________________________
> dm-crypt mailing list
> dm-crypt@saout.de
> http://www.saout.de/mailman/listinfo/dm-crypt
>

Re: [dm-crypt] keys from RAM dumps, hibernation files

[Milan Broz]

On 11/14/2014 12:33 AM, Sven Eschenberg wrote:
> On Thu, November 13, 2014 17:35, Michael Enßlin wrote:
>> Hi,
>>
>> LuksClose _should_ wipe all remains of the key from memory.
> 
> Actually unmapping the crypto target in dm-crypt should do that. The
> luksClose operation of cryptsetup is one example that initiates unmapping.

Yes and it does it. As the same as if you use low-level "dmsetup remove".

Anyway, you can try it:
I tested it with the AES key finder (cold boot utilities)
on memory image from suspended virtual machine
(plus you need to find dmcrypt crypt structure with plain key).
After luksClose and luksSuspend all previously visible keys in RAM
must disappear.

Milan

Re: [dm-crypt] keys from RAM dumps, hibernation files

[Heinz Diehl]

On 13.11.2014, Lars Winterfeld wrote: 

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

Whole disk encryption only protects your data when your computer is
off. Thus, there's no memory dump to catch. 
 
> 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?

Don't do that. Of course, it depends on the level of security you want
to have, and your threat model.
 
> When I suspend to RAM and they wake the device up again, they need to
> hack the login screen?

In general, when an adversary can get physical access to your running
machine, all bets are off. You can regard this machine as compromized.