Popular options include Microsoft's BitLocker, Symantec's PGP Whole Disk Encryption and the open source TrueCrypt software.
That news sounds frightening for those who use the above products to secure their data.
For those who work in digital forensics, however, the arrival of this tool will be welcome.
Elcomsoft has just announced that all of these encryption systems can be cracked by its new product, Elcomsoft Forensic Disk Decryptor.
 |
| Elcomsoft Forensic Disk Decryptor |
For those who work in digital forensics, however, the arrival of this tool will be welcome.
Until now data protected by these products was essentially unrecoverable without a suspect's cooperation.
It is important to note that the decrypting software will only be able to access the data under the following conditions:
- The target PC is running and...
- ...the attacker/investigator is able to obtain a memory dump.
Actually, there is an exception. If the computer was powered off, but had been put into hibernation mode while the encrypted disks/partitions were mounted, the investigator can also recover the necessary encryption keys.
Elcomsoft's blog post reminds us that it is possible to take a memory dump via a Firewire port.
There is a brute-forcing option available via the company's distributed processor cracking system (think SETI@home for password breaking).
If you use these encryption tools the safe option is to either shut down your computer completely, when leaving it unattended, or to unmount encrypted volumes before putting the computer into hibernation mode.
If using full-disk encryption and the computer is hibernated, then you will NOT be able to recover the keys since they are in the hibernation file...which is on the disk...which is encrypted. (unless thee is some huge flaw in a full-disk encryption software that I'm unaware of)
ReplyDeleteI believe when they say they can recover keys from hibernation files that Elcomsoft is referring to unencrypted disks where an encrypted file container has been opened and then the computer is hibernated. This means that the decryption key that was in memory is now written to an unencrypted disk, and is therefore recoverable.
None of this is news, but it all being in one product is something that I have not seen before.
-fiasco_averted
Well if the OS boots from the hibernation file, and how would it be able to decrypt it if the disk encryption service hasn't been started yet? The OS must save the hibernation file in a format readable at an early stage of the boot process. It's not encrypted.
ReplyDeleteIf the boot loader is capable of reading the O/S kernel (plus the necessary storage drivers) into main memory from an encrypted system volume, there's no reason why it cannot load the hibernation file as well. That said, I think the kernel usually handles the hibernation file, not the boot loader, so there's no problem either way. (The same goes for the swap file, by the way.)
DeleteMaybe the first poster was thinking of the page file?
ReplyDeleteAren't the keys saved on the TPM? You shouldn't be able to get them without a secure boot. I'm with the first poster on this one.
ReplyDeletePerhaps they are using the best scenario approach from an attackers standpoint, and the worst scenario from the target in this article, but the underlying message was they have a way to get passed the best & worst case scenarios when dealing with these encryption software protections.
ReplyDeletePerhaps, they'll spike your MBR(Master boot record) and extract the data from memory or plug a Firewire cable in(even a PCIMCIA card for Firewire)
My laptop is trucrypted and when it goes into hybernation I have to re-type my password to decrypt the harddrive to boot back in.
DeleteFirst poster is correct! The hibernation file is encrypted! Chicken and the egg situation here. If you can get to the hibernation file, you can view the memory. However, if you can view the hibernation files, you've already authenticated and have access to the system!
ReplyDeleteSecond poster is incorrect. The system must authenticate (pre-boot) before it can access the hibernation files. The hibernation files are 100% encrypted. (All bets are off however if you do not have pre-boot authentication enabled. And some organizations will disable pre-boot authentication.)
If you use file/folder encryption only (not Full Disk Encryption), then yes, it would be possible to grab the information from the hibernation file since the OS itself is not protected. This is why security experts recommend a layered approach to security.
The first poster is correct. The hibernation file is completely encrypted, and can only be decrypted after the user enters his pre-boot passphrase. The boot loader that allows entry of the passphrase is the only readable section of the drive, and contains no cleartext confidential information...even the AES key is encrypted to a key which is dynamically generated based on a conversion of the user's passphrase. If the passphrase is wrong, the disk key can't be decrypted.
ReplyDeleteOnce the bootloader authenticates the user, it hooks the BIOS (or UEFI) file I/O system to insert an on-the-fly decryption routine then starts the Windows boot process. Once the encryption product's Windows-based disk driver gets loaded, there's a hand-off and in-memory decryption gets performed by the 32-bit (or 64-bit) driver. The boot loader doesn't "read" the hibernation file, that's all handled through the Windows boot process (post secure boot loader and authentication).
Products like Elcommsoft require access to the system when it's already in a running (authenticated) state to get the hibernation file or memory dump. This could be due to a trojan that exfiltrates the hibernation file to a command and control site, or by inserting a rogue firewire device when the user steps away from the system.
Either way, this product does not let you steal some random person's hibernated laptop in an airport and expect to crack the encryption. THAT is the primary threat model which people buy disk encryption products to protect against.
This does raise the question: as an attacker, if I already have access to the system in a decrypted state (to exfiltrate the hibernation file), why not just copy the data I'm looking for? Seems a lot easier than extracting the hibernation file, then going back and stealing the laptop.
If you're concerned of a targeted attack involving a combination of malware and theft, or a breaking&entering to physically insert a firewire device, then you need better comprehensive security than just an off-the-shelf encryption product.
Disclaimer: I used to work for PGP and have pretty intimate knowledge of how these things work.
Great discussion. I have disabled moderation for a while and invited Elcomsoft to contribute.
ReplyDeleteSimon, I'd second that - excellent discussion!
ReplyDeleteI'm CEO and co-owner of ElcomSoft and will be more than happy to answer all questions you may have. Sorry, not right now -- it's almost midnight here in Moscow :)
In brief, I mostly agree with POV of the last poster (who worked for PGP). Sorry, I don't know your name, but you're welcome to get in touch with me directly (at v.katalov@elcomsoft.com), and probably that would be a good idea to post your thoughts into our (ElcomSoft) blog as well. And I'd like to provide you with the free license on EFDD! :)
Get your questions ready, and I'll be back to you tomorrow :)
Some articles aren't making it clear that the encryption per se isn't being "cracked". What is happening is that keys are being located in memory and files are decrypted using the keys.
ReplyDeleteIn addition, this is not new, although perhaps the ease of use of this tool may be.
In my view the term "cracked" should be used to describe breaking encryption without the use of keys and the term "decrypted" used to describe what this tool does.
A semantic nitpick but a valid one, I think.
Richard, you're absolutely right!
ReplyDeleteVladimir, great offer to answer questions - here are a few:
ReplyDelete1. How much does Elcomsoft use the source code available for TrueCrypt and PGP when creating your products? Or is it all reverse engineering?
2. What do you think of encrypting hard drives (Opal) and how will that affect forensics?
3. People have asked whether using TPM to store the keys makes a difference in the decryption abilities of EFDD - does it?
4. Do you recover the AES key, or just grab the key schedule and run the encrypted data through that to decrypt the drive?
Sorry for delay answering your questions, it's been a very hard week...
ReplyDelete1. For BitLocker, it is copletely reverse-enineering. For PGP, we just looked at the soorces and used them a little bit; for TrueCrypt -- more intensively.
2. To be honest, we have not investigated such (hardware-based) HDD encryption yet. There is a chance that the same method would be applicable, but not 100% sure, sorry. In any case, that's a good challenge for forensics, obviously. We should definitely put some research there (as well as for USB flash drives with built-in encryption).
3. No difference. TPM (or smartcard) only affects the authentication, but we don't care how the encryption keys are being generated -- we catch them at the later stage.
4. We do recover the AES key. For PGP, you can even select what particular keys to search for (if you know the encryption algorythm and key length, searching is much faster). And we do find all the available keys, not just for the disk (but all others that also reside in memory).
Hi,I think you did not respond to previous discussion about using whole disk encryption with TrueCrypt where hibernation file is encrypted and user has to type the passphrase to resume from hibernation,too. Is this case now vulnerable or not?
ReplyDeleteSorry for that!
ReplyDeleteHibernation file cannot be encrypted 'alone' (itself). It is always located on the system (bootable) partition, and so it is either encrypted with that partition, or not encrypted at all. So just use whole disk encryption for your system disk -- and you're safe (of course, if you switch your computer off, so there is no way to run FireWire attack or dump the memory).
About the situation when "user has to type the passphrase to resume from hibernation": this case is vulnerable (until system partition is encrypted, see above). The hibernation file is there -- just boot from USB stick and grab it; or read this disk on the other machine.
So, to summarise (and to quote the first comment), it is possible to retrieve the keys easily if using encrypted containers or non-system partitions.
ReplyDeleteHowever, "if using full-disk encryption and the computer is hibernated, then you will NOT be able to recover the keys since they are in the hibernation file...which is on the disk...which is encrypted."
Thanks to everyone for contributing to a very interesting and sometimes in-depth discussion.
Moderation is now active again, but please feel free to submit further comments and I'll review them in a few days.
Hi all,
ReplyDeleteAfter reading the article, the only way to bypass the ecryptation system is getting a memory dump or the pagefile.sys / hybernation file after mounting an encrypted volume.
From my point of view:
-if you have full disk encryption and the system in hibernate, it is not possible to get not encrypter RAW data.
- If the computer is suspended with password, you are not able to dump the RAM as you are not able to execute programs.
- In that case, it is point out to get the memory dump by the FireWire attack, but all the documentation found in the net is quite all (2008-2009), and it appears that latest operating system are not vulnerable to these kind of issues, at least after installing the latest service packs available.
- So IMHO, the only remaining chance it is performing a Cold Boot Attack in order to get the memory dump
However if you are able to reach an unlock computer with an encrupted volume mounted (the main hard disk or an USB drive, an specific file), with the use of this tool you could bypass the barrier.
Finally, does this tool bypass Check Point (PointSec) solution?
Thanks,
José Corbacho Gil