
Popular disk encryption systems' keys recoverable from memory dump - ColinWright
http://simonedwards.blogspot.co.uk/2012/12/popular-disk-encryption-systems-cracked.html?utm_source=feedburner&utm_medium=feed&utm_campaign=Feed:+SecurityBloggersNetwork+(Security+Bloggers+Network)
======
casca
TL;DR: Elcomsoft releases tool to recover keys from memory from BitLocker, PGP
Whole Disk Encryption and TrueCrypt.

This attack is not news, but Elcomsoft makes excellent tools that work so it
makes it easier. There is no cracking going on. There is a question around
hibernation - Truecrypt can dismount drives before hibernating so might be
protected.

~~~
gpcz
It also means that organizations that only accept commercial software due to
bureaucratic concerns such as requiring a support contract, needing a
corporate name on their tools to be considered "respectable," etc now have
access to a technique that the research community discovered how to do years
ago. Effectively, it's now an "enterprise solution."

------
trebor
This is a linkbait title that has nothing to do with cracking. It does,
however, have to do with the recovery of your encryption keys from a memory
dump. And yes, if your computer is running or put into hibernation your
encryption keys will be at risk—guaranteed.

For better security shut your system off. Especially if you have a firewire
port (because most computers with them can have a direct memory dump taken
without any need to interact with the victim's computer).

~~~
Dylan16807
>And yes, if your computer is running or put into hibernation your encryption
keys will be at risk—guaranteed.

Don't get too hasty there. The default for Truecrypt at least is to dismount
upon hibernation.

~~~
trebor
Does it burn the encryption key out of memory prior to hibernation? I should
hope so or else I'm still right.

And if the system requires that the volume be mounted when resuming the
hibernated state, just turning the system on _could_ compromise the system.

~~~
Dylan16807
<http://www.truecrypt.org/docs/?s=unencrypted-data-in-ram>

Short answer: Yes, it clears the keys upon dismount.

Longer answer: If you have a non-critical volume encrypted, set to dismount on
hibernate, it clears the keys. Beware programs that still have files in in
memory, though. If you have the system volume encrypted, then nobody can get
the keys out of the hibernation file. Truecrypt is forced to leave the keys in
memory here, but you just hibernated. The system is shut down. Give it a
minute and the RAM will clear.

------
ColinWright
I see the mods have just changed the title to one that is _not_ the title on
the article, but which _does_ more accurately reflect the contents. For that I
applaud them.

The interesting thing is that over the past few months I've been trained by
the mods _not_ to put a more accurate title, but always to go with the literal
title as embedded in the article. Whenever I've tried to be helpful it's
simply got changed back to the less informative version, so I've stopped
bothering.

Does this indicate a change of policy? Should I now go back to providing
accurate, informative titles?

------
trotsky
A properly configured IOMMU (VT-d in intel parlance) should prevent most
physical ram dump attack vectors. The good news is that almost all x86 chips
are shipping with one on die these days. The bad news is that support is thin
- many vendors don't ship good firmware for it. Software wise support is mixed
- your OS needs to manage what drivers have access to what pages. Since it's
seen as primarily a virtualization technology, virtualization platforms handle
it best - xen is top notch and works well out of the box. Other OS's can
mostly be well configured with some patience with the notable exception of
darwin (apple hardware also lacks vt-d firmware support).

If you're in a situation where you're truly concerned about your door being
busted down you're almost guaranteed to be subject to a ram dump if you're
vulnerable, primarily via firewire, unlocked workstations and local exploits
but a myriad of less common vectors exist.

~~~
sweis
IOMMU does not protect against non-volatile RAM or bus analyzers. Plus,
"properly configured" is essential; most operating systems are not.

------
deutronium
So it relies on taking a memory dump, this doesn't sound like anything new,
for example you can do similar things with
<https://citp.princeton.edu/research/memory/code/> which is open source.

And you can perform the firewire attack using
<http://www.breaknenter.org/projects/inception/>

Additionally memory can also be dumped via PCI e.g.
<http://www.grandideastudio.com/portfolio/tribble/>

If you're concerned about such attacks you could use an external device which
lets you enter a password using its own keyboard, meaning the key is stored in
volatile memory on the external device - not accessible via a memory dumping
tool. And then don't leave the device plugged into the computer when you're
not around.

And bruteforce attacks have been around for a while using GPUs for instance
Passware's forensic program.

------
mikeash
Why don't these tools flush the encryption keys when hibernating, and require
the user to re-enter their password to resume? That's what Apple's FDE does,
anyway.

~~~
drcube
I have to re-enter my passphrase on my LUKS encrypted laptop when resuming
from hibernation. Does anybody know if LUKS (which uses cryptsetup/dm-crypt)
is safer in this regard?

~~~
yungchin
If you stick to a recommended partition layout, the swap partition (which will
contain the hibernation image) should be contained in the LUKS partition, so
yes, that's safe from this type of attack.

~~~
drcube
Yeah, my swap partition is encrypted. The only thing that isn't is a small
/boot partition. I figured as much, but I would have figured TrueCrypt and the
like would be the same way. Being a relative novice with encryption, I just
wanted to clarify. Thanks.

------
drucken
There are more secure tools than the ones mentioned available, and have been
for a while.

For example, Bestcrypt from Jetico ([http://www.jetico.com/encryption-
bestcrypt-volume-encryption...](http://www.jetico.com/encryption-bestcrypt-
volume-encryption/)) supports two-factor authentication with removable disks
(including USB sticks) or hardware tokens or over the network. That is, the
encryption keys are simply not available on a computer that may be stolen, for
example.

In addition, all kinds of memory dumps, including hibernation and even crash
dumps are fully encrypted.

I imagine in time, at the minimum the PGP and Truecrypt products will
eventually catch up with similar features.

~~~
SageRaven
Sure, the key _files_ won't be on the computer, but the decryption key must
necessarily be resident in RAM or otherwise accessible by the CPU (in a
register, such as with TRESOR mentioned elsewhere) to encrypt/decrypt disk
blocks of a running system.

~~~
drucken
My point is that there are security products with configurations where the
keys are cleared from RAM when the system is not running (including
hibernation modes). Therefore, in those configurations they are at most only
vulnerable while they are running.

Used in that way, this greatly mitigates the risks mentioned in the article.

------
sweis
Shameless self-promotion here:

PrivateCore (<http://www.privatecore.com>) defends against memory extraction
attacks like this. We treat main memory as a hostile device and encrypt all
data before it leaves the CPU.

We're venture-backed and hiring a memory-management researcher if you're
interested: [http://www.privatecore.com/careers/memory-management-
researc...](http://www.privatecore.com/careers/memory-management-
researcher.html)

------
revelation
This is blogspam and the monospace font is hurting my eyes. Nothing was
cracked or broken. This is a long known vulnerability that to effectively
exploit requires physical access to the computer in question. This tool
doesn't even solve the hard problem, which is getting a memory dump in the
first place.

Of course, if you have physical access, theres a multitude of ways to get the
keys that are not time critical or depend on the machine running at the time
of access.

------
lucb1e
This vulnerability has been known for years and has been effectively
demonstrated many times in the past. The title should rather be something
along the lines of "New tool to use memory dumps of running systems to read
encrypted harddrives."

I've seen options to store the key in the L1-cache instead of the RAM-memory
to make this attack much harder. I'm not sure whether I remember correctly or
if it's even possible with common tools though.

~~~
WinnyDaPoo
Adding to your point that this is old news:
<https://citp.princeton.edu/research/memory/> [LEST WE REMEMBER: COLD BOOT
ATTACKS ON ENCRYPTION KEYS]. I think this was on HN awhile ago...

The real news is the commercial tool that implements the memory dumping and
key extraction.

------
DanBC
See also:

Enclosed but not encrypted:
([http://www.h-online.com/security/features/Enclosed-but-
not-e...](http://www.h-online.com/security/features/Enclosed-but-not-
encrypted-746199.html))

------
spgedwards
Elcomsoft is answering similar questions to yours in the original article's
comments section. Simon Edwards

------
foxhill
i seem to remember reading about somebody running disk encryption, and storing
the keys in the x86 debug registers - i believe this method would be
completely immune to this "crack".

as has been said before, recovering keys from memory dumps is nothing new
(although this makes it much easier).

~~~
sillysaurus
Hmm, are x86 debug registers not stored along with all of the other registers
during context switch? Or why is that more secure?

~~~
foxhill
no, they are only accessible in ring 0, so only the kernel has access to them.

turns out there was a patch for the linux kernel[1] to do it.

[1] - <http://en.wikipedia.org/wiki/TRESOR>

------
shared4you
Does this apply to TrueCrypt on Linux as well?

