Slashdot is powered by your submissions, so send in your scoop


Forgot your password?
Encryption Privacy Security Software Technology

ElcomSoft Tool Cracks BitLocker, PGP, TrueCrypt In Real-Time 268

An anonymous reader writes "Russian firm ElcomSoft on Thursday announced the release of Elcomsoft Forensic Disk Decryptor (EFDD), a new forensic tool that can reportedly access information stored in disks and volumes encrypted with desktop and portable versions of BitLocker, PGP, and TrueCrypt. EFDD runs on all 32-bit and 64-bit editions of Windows XP, Windows Vista, and Windows 7, as well as Windows 2003 and Windows Server 2008." All that for $300.
This discussion has been archived. No new comments can be posted.

ElcomSoft Tool Cracks BitLocker, PGP, TrueCrypt In Real-Time

Comments Filter:
  • by icebike ( 68054 ) on Thursday December 20, 2012 @03:53PM (#42351715)

    Exactly: They aren't breaking encryption, they are simply surfing for keys.

    Quote TFA:

    So, how does it work? Elcomsoft Forensic Disk Decryptor acquires the necessary decryption keys by analyzing memory dumps and/or hibernation files obtained from the target PC. You’ll thus need to get a memory dump from a running PC (locked or unlocked) with encrypted volumes mounted, via a standard forensic product or via a FireWire attack. Alternatively, decryption keys can also be derived from hibernation files if a target PC is turned off.

    Note the basic misunderstanding embedded in that last sentence: Turned off != Hibernated.

    While this tool might help you break into a computer you found hibernated, or running while locked, it won't do any good if the power cord is yanked, or the encryption software was intelligently written to only store its key an some volatile memory.

  • by Jane Q. Public ( 1010737 ) on Thursday December 20, 2012 @04:46PM (#42352277)

    "memory retains data for a while after the PC is powered off creating some interesting situations if the feds are banging on your door"

    "A while" is generally limited to a few seconds: the amount of time it takes for your power supply and/or capacitors on the board to discharge.

  • by Eric Smith ( 4379 ) on Thursday December 20, 2012 @07:02PM (#42353565) Homepage Journal

    Doesn't work with BitLocker and a TPM chip. The key is kept in protected memory on the chip and only authenticated code can use it.

    I don't think that's true. The passphrase (perhaps hashed?) pay only be in the TPM chip, but the actual cryto key used to decrypt disk sectors is in main memory, because the main CPU is used to do the decryption. There's nowhere near enough bandwidth to and from the TPM chip to let it do the actual disk encryption/decryption. There's not even enough bandwidth to ask the TPM for the key each time you want to do a disk transfer, and erase it from memory after the disk transfer is completed.

    This means that software that extracts the encryption key from memory probably can't turn it back into the passphrase that the user enters, but if you have a copy of the disk and the key, you don't actually need that passphrase.

    The TPM is not a high-performance device and doesn't do anything but give out the keys on (authenticated) request. What the software does with those keys is up to the software. If someone has privileged or physical access to the machine while the keys are in use, all bets are off.

  • by KookyMan ( 850095 ) on Thursday December 20, 2012 @07:51PM (#42353979)

    And, while I forgot about it at first, TrueCrypt should be encrypting the hibernation file if you are using System Encryption (on Windows) and the hibernation file is stored on the system drive (generally is). So again, this appears as it would be even more limiting for finding keys in a file, since someone who is "security conscious" most likely has their system drive encrypted, and is making sure hibernation file is on it.

    As a result, you would actually be further ahead to hibernate your computer for your little bathroom break than you would be to sleep it (Since sleep leaves everything in RAM).

    *I say should because there are various little nuances to that, OS, hibernation file placement, TrueCrypt Version, etc that may result in your key being written in a non-encrypted state.

"If it's not loud, it doesn't work!" -- Blank Reg, from "Max Headroom"