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.
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."
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).
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.
Windows 8's shut down now does some sort of kernel hibernation. Shutting down isn't really a full shutdown in the traditional sense anymore apparently. Anyone know whether this means Windows 8 machines with Bitlocker are vulnerable?
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?
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.
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.
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.
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?
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.
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.
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...) 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.
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.
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.
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.
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.
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.
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.
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).
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.