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

← Back to Stories (view on slashdot.org)

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

Posted by timothy on Thursday December 20, 2012 @06:48AM from the well-that-puts-a-spin-on-things dept.

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.

62 of 268 comments (clear)

Min score:

Reason:

Sort:

Key theft != cracking encryption by Anonymous Coward · 2012-12-20 06:53 · Score: 5, Informative

Yeah, this is really just exploiting retarded key control. The encryption standards themselves are still secure
1. Re:Key theft != cracking encryption by iluvcapra · 2012-12-20 07:01 · Score: 2
  
  Yeah, this is really just exploiting retarded key control.
  I dunno, I've let my laptop go into hibernate with a TrueCrypt volume mounted. It's "retarded" but that doesn't mean it doesn't work.
  
  --
  Don't blame me, I voted for Baltar.
2. Re:Key theft != cracking encryption by Anonymous Coward · 2012-12-20 07:27 · Score: 5, Insightful
  
  It's still a key control problem.
  If Windows notifies programs about suspends/shutdowns (not sure it really does), TrueCrypt needs to dismount immediately and do whatever it needs to do to protect its key.
  None of these processes attack the encryption directly, just control of its keys. Of course, that still means data disclosure, but rather than meaning P=NP or some other news, it simply means that keys are being poorly protected by the software, which in the case of hibernation can hopefully be fixed.
  Firewire doesn't matter...it's equivalent to a malicious PCI device, without (as far as I know) the possible protection of VT-d. Epoxy or X-acto. If you can read the system's memory space, you can do a *WHOLE* lot more than just recovering the key...the data itself is likely in there while being read or even the entire unencrypted volume if it's memory mapped. Let alone kernel memory etc. So that is not news really.
3. Re:Key theft != cracking encryption by icebike · 2012-12-20 07:53 · Score: 5, Interesting
  
  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.
  
  --
  Sig Battery depleted. Reverting to safe mode.
4. Re:Key theft != cracking encryption by _Shad0w_ · 2012-12-20 07:53 · Score: 5, Informative
  
  You can register an interest in knowing about power events by calling RegisterPowerSettingNotification(); your application then gets sent the WM_POWERBROADCAST message when the the power setting changes, that includes suspending the system (PBT_APMSUSPEND). You get about two seconds to actually do something with this information.
  
  --
  Yeah, I had a sig once; I got bored of it.
5. Re:Key theft != cracking encryption by icebike · 2012-12-20 07:56 · Score: 2
  
  But holding it in volatile memory, and entering it once upon boot up is not all that bad. There are a lot of ways this can be done such that the private key never need be stored on the disk in unencrypted form.
  
  --
  Sig Battery depleted. Reverting to safe mode.
6. Re:Key theft != cracking encryption by Tawnos · 2012-12-20 08:01 · Score: 5, Informative
  
  Freeze the ram, remove, reinsert into a device to dump the RAM's contents. It's been done before: http://zedomax.com/blog/2008/09/29/memory-hack-how-to-hack-encryption-keys-by-freezing-memory/
7. Re:Key theft != cracking encryption by chis101 · 2012-12-20 08:04 · Score: 2
  
  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.
  I'm pretty sure that modern hibernate simply stores necessary information from RAM into a file on disk, and shuts off the computer. Then, on boot, it checks if this file exists, and if so attempts to resume from it. So, there is no difference between "off" and "hibernating." The boot sequence will just check if there is a file to resume from.
  So, you still need to find a computer that has the volume mounted (either running, in 'sleep' mode with power still being supplied, or from a hibernate file on the disk)
8. Re:Key theft != cracking encryption by Anonymous Coward · 2012-12-20 08:05 · Score: 5, Informative
  
  In Windows the hibernation file is never deleted (I assume to keep enough HDD space reserved). In fact, many systems automatically hibernate after they've been suspended for a certain period of time. I don't know how Linux hibernation works. You might have the key sitting in the hibernation file from weeks ago.
9. Re:Key theft != cracking encryption by Synerg1y · 2012-12-20 08:06 · Score: 2
  
  Almost... but not quite, memory retains data for a while after the PC is powered off creating some interesting situations if the feds are banging on your door :)
  
  Also, this is by far not the first tool of it's kind to steal keys out of various mem locations, $300 isn't a bank breaker though like some of the other tools in the biz are, or law enforcement only type stuff. I'm sure if you look hard enough, you can find free programs esp. on the linux side of the wall that can do this.
10. Re:Key theft != cracking encryption by Anonymous Coward · 2012-12-20 08:15 · Score: 4, Informative
  
  hiberfil.sys is not scrubbed or deleted after resuming from hibernation, therefore it will persist after a subsequent shutdown. So if the hibernation feature was used while an encrypted filesystem was mounted, the keys will remain in it.
11. Re:Key theft != cracking encryption by icebike · 2012-12-20 08:39 · Score: 3, Informative
  
  So, there is no difference between "off" and "hibernating."
  The difference is the lack of a resume file. The computer is not hibernating if this file is missing or was never written because the power was switched off without taking the time to hibernate the computer.
  
  --
  Sig Battery depleted. Reverting to safe mode.
12. Re:Key theft != cracking encryption by mrbester · 2012-12-20 08:42 · Score: 2
  
  Windows deletes a hiberfil.sys if found after a shutdown (or a restart if updates require it) but only by the wiping of the allocation table entry. The contents are usually still on disk as the file tends to be placed at the end of the drive so it is possible that the sectors can be analysed.
  
  --
  "Wait. Something's happening. It's opening up! My God, it's full of apricots!"
13. Re:Key theft != cracking encryption by lister+king+of+smeg · 2012-12-20 08:45 · Score: 2
  
  the difference is in an encryption the attacker and the intended recipient are two different people. What DRM does is simply try to obscure and obfuscate the decryption buy hiding the keys that they give you but if you are determined you can dig around and find them. where with properly implemented encryption scheme you trust the recipient and give them the public key(or perform an handshake involving several key exchanges) and simply have to keep everyone else from seeing it.
  
  --
  ---Saying gnome 3 is better than windows 8 not so much a compliment as it is damning with light praise.
14. Re:Key theft != cracking encryption by Jane+Q.+Public · 2012-12-20 08:53 · Score: 5, Informative
  
  Others have mentioned that it does not attack the actual encryption, but they did not summarize what it does do:
  
  This only works if the encrypted item (drive or file) is in a mounted state at the time of "attack". And that applies if it is in a mounted state when the machine goes into hibernation. It gathers the encryption key from memory (or resume file if hibernating), it does not even try to "break" the encryption.
  
  Still, it must be said that this is a clever approach, and could be a nice tool in some (very limited) circumstances.
15. Re:Key theft != cracking encryption by Rakishi · 2012-12-20 08:54 · Score: 4, Informative
  
  "A while" is generally limited to a few seconds:
  No it's not, regular RAM retains memory for up to a few minutes (sort of) with no refreshes at regular temperatures. Freeze the memory and it's a lot longer than that.
  http://zedomax.com/blog/2008/09/29/memory-hack-how-to-hack-encryption-keys-by-freezing-memory/
16. Re:Key theft != cracking encryption by icebike · 2012-12-20 09:02 · Score: 5, Informative
  
  But if you are worried about this, you simply run after awakening from hybernation mode:
  POWERCFG -H OFF
  POWERCFG -H ON
  That turns off hibernation, which deletes hiberfil.sys then enables hibernation which will allow its recreation.
  
  --
  Sig Battery depleted. Reverting to safe mode.
17. Re:Key theft != cracking encryption by icebike · 2012-12-20 09:15 · Score: 4, Informative
  
  I am not confusing anything, you are.
  Hibernation is a choice you make every time you shut down your computer.
  Stop doing that.
  Just choose shutdown instead of hibernation.
  In fact you can disable hibernation all together, and simply use sleep for short trips to the bathroom, and actually shut the damn thing down when not using it.
  Security conscious people never hibernate a machine.
  
  --
  Sig Battery depleted. Reverting to safe mode.
18. Re:Key theft != cracking encryption by EdIII · 2012-12-20 09:36 · Score: 3, Insightful
  
  Or you disable hibernating completely.
19. Re:Key theft != cracking encryption by EdIII · 2012-12-20 09:41 · Score: 5, Insightful
  
  Or you could, you know, not do anything with the system that would give the feds a reason to be banging on your door.
  More, and more, just living free and being vocal about others living free, and god forbid, helping others living free, is more than enough reason to have the feds banging down your door .
  Let's not forgot that moron FBI guy that took out hundreds of companies in a data center because he could not understand how hundreds of different companies and legal entities could cohabitate in the same space.
  At this point just being innocent and never doing anything wrong is not protection enough to be raided by the feds.
20. Re:Key theft != cracking encryption by Anonymous Coward · 2012-12-20 09:51 · Score: 2, Informative
  
  That doesn't wipe the data, only frees the sectors.
21. Re:Key theft != cracking encryption by AmiMoJo · 2012-12-20 09:53 · Score: 3, Informative
  
  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. It was specifically designed to defeat attackers with full access to the contents of RAM, including rootkits and the like.
  Shame TrueCrypt doesn't support TPM as well.
  
  --
  const int one = 65536; (Silvermoon, Texture.cs)
  SJW, n: "Someone I don't like, and by the way I'm a fuckwit" - AC
22. Re:Key theft != cracking encryption by gmueckl · 2012-12-20 10:46 · Score: 3, Informative
  
  Hibernation in Linux uses a swap partition. So depending on the size and usage of the swap space the key may be overwritten almost instantly or sit in swap space for eternity.
  
  --
  http://www.moonlight3d.eu/
23. Re:Key theft != cracking encryption by Eric+Smith · 2012-12-20 11:02 · Score: 3, Interesting
  
  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.
24. Re:Key theft != cracking encryption by KookyMan · 2012-12-20 11:51 · Score: 3, Interesting
  
  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.
25. Re:Key theft != cracking encryption by Zan+Lynx · 2012-12-20 13:10 · Score: 2
  
  You need hardware support to securely encrypt a hibernation file. Otherwise it is a chicken and egg problem. Where do you get the key to decrypt the hibernation file? It would have to be in the hibernation file.
  Either that or ask the user for the security code on resume. Which is valid but obnoxious.
I bet EFDD is... by Anonymous Coward · 2012-12-20 06:53 · Score: 5, Funny

...just a hammer.
Obligatory: http://xkcd.com/538/
1. Re:I bet EFDD is... by mar.kolya · 2012-12-20 07:28 · Score: 5, Funny
  
  In Russia this often called 'thermorectal cryptanalysis' and soldering iron is a tool of choice for this sort of job.
Not as clever as it sounds by Anonymous Coward · 2012-12-20 06:54 · Score: 5, Informative

It reads the encryption key from memory.
1. Re:Not as clever as it sounds by blueg3 · 2012-12-20 07:13 · Score: 5, Funny
  
  What did you expect it to do? Magic?
2. Re:Not as clever as it sounds by smittyoneeach · 2012-12-20 07:18 · Score: 5, Funny
  
  I, for one, expected a pagan ritual involving Cthulhu; Natalie Portman, naked and petrified and covered in hot grits; and a traveling salesman walk of all your base.
  
  --
  Get thee glass eyes, and, like a scurvy politician, seem to see things thou dost not.--King Lear
3. Re:Not as clever as it sounds by HeckRuler · 2012-12-20 07:20 · Score: 4, Insightful
  
  Yeah, I would consider the ability to crack hard-encryption in a reasonable amount of time and processing power as a good definition for "magic". I'm under the impression that such a feat is mathmatically impossible. At least as far as we know. And the summary lead me to believe that they had somehow found a flaw in the underlying encryption scheme.
4. Re:Not as clever as it sounds by gmuslera · 2012-12-20 07:29 · Score: 4, Insightful
  
  The first thing you think about "PGP encryption cracked" is that a random .pgp file that you got isolated somehow (i.e. intercepting a mail with it attached) could be cracked and decrypted in minutes, no extra hardware required.
  But this goes to the RAM of the computer where still resides somehow the passphrase to decrypt the file. Is a bit more serious, but not so much different than claiming that you cracked pgp encryption because you had a keylogger installed.
5. Re:Not as clever as it sounds by blueg3 · 2012-12-20 07:46 · Score: 4, Insightful
  
  Security articles pretty much always dramatically overstate what they are capable of. Generally "cracked" gets used any time something is decrypted and the person who encrypted it didn't intend for it to be.
  It sounds like it should be super easy, since the encryption key is "just sitting in memory", but it's not. A lot of those programs actively take steps to try to prevent the key from being captured from memory. Elcomsoft is by no means the first person to demonstrate this attack, but they like to aggressively promote whenever they make tools for applying techniques that researchers have already developed.
6. Re:Not as clever as it sounds by crazyjj · 2012-12-20 08:02 · Score: 3, Funny
  
  My father was a pagan, you insensitive clod!
  
  --
  What political party do you join when you don't like Bible-thumpers *or* hippies?
7. Re:Not as clever as it sounds by wierd_w · 2012-12-20 08:14 · Score: 2
  
  Cthulu?
  Don't be silly! Clearly you didn't actually graduate from Miskatonic U.
  All the 300 level students know that Yog Sothoth holds all the keys!
  Honestly.....
With a huge exception by Anonymous Coward · 2012-12-20 06:55 · Score: 5, Informative

It requires a memory dump of the system where the keys are used. Bad submitter. Is anyone filtering the submissions? This is starting to look like reddit.
1. Re:With a huge exception by BradleyUffner · 2012-12-20 06:59 · Score: 5, Insightful
  
  It requires a memory dump of the system where the keys are used. Bad submitter. Is anyone filtering the submissions? This is starting to look like reddit.
  Which you can get VERY easily if the computer has a firewire port.
  http://blogs.gnome.org/muelli/2010/04/reading-ram-using-firewire/
2. Re:With a huge exception by kagaku · 2012-12-20 07:51 · Score: 3, Informative
  
  This works with anything that provides DMA access - including FireWire, ExpressPort, PCMCIA, Thunderbolt, etc..
  
  --
  everyday is another shooter.
3. Re:With a huge exception by torkus · 2012-12-20 07:59 · Score: 5, Insightful
  
  That article is 2+ years old and deals with XP. Also the author chews on words for the first paragraph or two and makes me want to shoot myself (not to mention being wrong on a few points...) but anyhow..
  Does the memory dump apply to Win 7/8? Fully patched XP? FW ports are a niche and rather uncommon. Of more interesting concern - are hibernate files encrypted on a bitlocker encrypted drive?
  I agree with GP - this is a terribly written submission (and/or just an advertizement.) Bitlocker, PGP, and trucrypt ALL decrypt in realtime already - if you provide them with keys!!!
  
  --
  You can get rich if you own a politician, but you have to be rich to buy one in the first place.
4. Re:With a huge exception by GodBlessTexas · 2012-12-20 08:50 · Score: 2
  
  The OS has nothing to do with it. Firewire ports are DMA, as are Thunderbolt ports if I remember correctly, which means access to the port means direct access to the RAM. That means you can not only read the data, but you can also potentially manipulate it (killing processes, injecting code into already running processes, etc.).
  
  --
  Remember the Alamo, and God Bless Texas...
5. Re:With a huge exception by amorsen · 2012-12-20 09:06 · Score: 2
  
  Only on systems without an IOMMU or with an OS which does not properly limit access. Both of which are becoming rarer.
  
  --
  Finally! A year of moderation! Ready for 2019?
6. Re:With a huge exception by threephaseboy · 2012-12-20 09:11 · Score: 3, Informative
  
  Recent MacOS blocks DMA from Firewire when the user is not logged in:
  http://support.apple.com/kb/HT5002 (search CVE-2011-3215)
  
  --
  .
Not by Maximum+Prophet · 2012-12-20 06:56 · Score: 5, Informative

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.
That's not really cracking. It's more like looking under the keyboard for sticky-notes.

--
All ideas^H^H^H^H^Hprocesses in this post are Patent Pending. (as well as the process of patenting all postings)
1. Re:Not by Kjella · 2012-12-20 07:41 · Score: 2
  
  Yes, except certain standards basically give your peripherals practically free reign to roam through your memory, specifically Firewire and Thunderbolt or if the attacker can add such a port through extension cards and the drivers are installed automatically. This is rather well documented behavior, and the small price you have to pay for closing this loophole:
  
  The drawback of this mitigation is that external storage devices can no longer connect by using the 1394 port, and all PCI Express devices that are connected to the Thunderbolt port will not work. Because USB and eSATA are so prevalent, and because DisplayPort often works even when Thunderbolt is disabled, the adverse effect caused by these mitigations should be limited.
  
  --
  Live today, because you never know what tomorrow brings
2. Re:Not by bill_mcgonigle · 2012-12-20 07:47 · Score: 3, Insightful
  
  Net result is the same. If there's a whole in the security, it's a flaw regardless of whether you think it's k3wl or not.
  Yes, there's a hole in the security, but not in the WDE products. Identifying the correct attack surfaces allows the security-minded to mount proper defenses.
  From this perspective, the article title is misleading and counter-productive.
  Better: "ElcomSoft Demonstrates Bypass Tool for BitLocker, PGP, and TrueCrypt".
  
  --
  My God, it's Full of Source!
  OUTSIDE_IP=$(dig +short my.ip @outsideip.net)
Misleading title by RenHoek · 2012-12-20 06:58 · Score: 5, Insightful

Unlike the title claims, it doesn't _crack_ in real time, it just allows you to mount the encrypted volume and lets you decrypt it with the keys you found. I.e. make it work just like truecrypt when you mount a partition.
If they were able to _crack_ in real time, then they'd have just solved P = NP.
1. Re:Misleading title by Anonymous Coward · 2012-12-20 07:47 · Score: 2, Informative
  
  If they were able to _crack_ in real time, then they'd have just solved P = NP.
  Neither AES nor Public Key Crypto (atleast as far as I'm aware) has ever been shown to be polynomial-time reducible to an NP-Complete problem..
  So your claim is not tue...
Encryption is not broken by RatRagout · 2012-12-20 06:58 · Score: 5, Informative

They are simply extracting the encryption keys from the memory of a running computer using DMA and firewire. @breaknenter has been doing this with inception and some scripts for years.
1. Re:Encryption is not broken by RatRagout · 2012-12-20 06:59 · Score: 5, Informative
  
  Link to inception: http://www.breaknenter.org/projects/inception/
2. Re:Encryption is not broken by SeaFox · 2012-12-20 07:40 · Score: 2
  
  You didn't include the link in your first post, and make us go deeper to get to Inception? ;-)
Encrypted swap? by Anonymous Coward · 2012-12-20 07:00 · Score: 5, Informative

I don't use windows, but on other OSs, the swap where "hibernation" data goes, is encrypted to avoid such trivial exploits.
As for the firewire attack, that was first developed on Linux, and immediately prevented on Linux. On Windows, it has been available since XP days, and MS notified of the issue back then. So, no excuse it is still trivial to unlock, disk dump, mem dump a windows box through the DMA firewire hack, now 3 major versions on since this attack was well known.
No. by Anonymous Coward · 2012-12-20 07:07 · Score: 2, Informative

This tool IS NOT capable of "cracking" disks encrypted by these methods. It is capable of locating the keys, should you be able to get a memory dump of the running system or obtain hibernation files, and decrypting the disks using the keys. In short, if you have something to hide, do not use hibernate and always power off your machine when you are not actively using it.
extracting keys from RAM by interiot · 2012-12-20 07:09 · Score: 4, Informative
This tool extracts the keys from RAM dumps. There are free tools that do this too, of course.
But isn't it difficult to get a RAM dump, you say? Not really:
- Hibernating a computer writes this data to disk. Starting in Windows 8, "shutdown" actually writes some hibernate data by default.
- VMs also have their own suspend functionality that does a RAM dump, as well as non-SAN VM migration.
- Firewire ports actually allow devices to scan RAM of the machine they're connected to.
- Obviously, if you have access to a live machine, you can get the keys directly from RAM.
1. Re:extracting keys from RAM by bill_mcgonigle · 2012-12-20 07:44 · Score: 2
  
  Disable Firewire in your BIOS if you can.
  If you can't, snip the leads on your motherboard.
  If you can't, fill the port with hot glue.
  
  --
  My God, it's Full of Source!
  OUTSIDE_IP=$(dig +short my.ip @outsideip.net)
Re:DRM? by NemosomeN · 2012-12-20 07:10 · Score: 2

Elcomsoft is a legitimate business, at least I always had that impression. (They are well known, in fact I've known of them for years, I think. Never knew they were Russian).

--
I hate grammar Nazi's.
Re:System drive encryption? by marcello_dl · 2012-12-20 07:15 · Score: 4, Funny

>My setup is the following: win...
first mistake? ;)

--
---- MISSING MISCELLANEOUS DATA SEGMENT --- [sigdash] trolololol
It's really a decryption key finder by girlinatrainingbra · 2012-12-20 07:26 · Score: 2

I would actually call this more of a "finder of the decryption key if left hiding in RAM or hibernation file while encrypted partition is mounted":
It works only if
(1) you can get a volatile memory dump while the encrypted partition is mounted and the decryption key currently resides in the volatile memory or
(2) if you can get access to a hibernation partition/file which contains the decryption key from when the encrypted partition was mounted.
From the linked article 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â(TM)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. So saying that this software is capable of decrypting PGP / Bitlocker / Truecrypt partitions is hyperbole. A more accurate assessment of this software is capable of finding the decrpytion/encryption key in RAM or hibernation files.
I thought Truecrypt, et al were smarter about RAM by swb · 2012-12-20 07:27 · Score: 4, Insightful

I thought TrueCrypt,et al were smarter with their RAM-based keys than that and made them more difficult to sniff in RAM, as this has long been a well-known weakness of any encryption software.
Or is there something about whole-disk encryption software that makes this more difficult (which I can see from a performance perspective)?
You would think they would randomize memory locations or have some kind of method of encrypting the keys in-memory and decrypting them and wiping as they did disk I/O. A race condition that would expose them, but with a smaller window for exploitation than leaving them in memory.
These guys make IT people look like gods.... by Lumpy · 2012-12-20 07:43 · Score: 5, Funny

I used to have their password kit for enterprise and it would make me look like a complete computer GOD to the users.
"I lost the password to my spreadsheet...."
"what is the password I used on this zip file?"
etc....
I would crack about 5-10 passwords a week with their tools and ended up never having to buy drinks when going out with office workers after work because of it.

--
Do not look at laser with remaining good eye.
Strong Doubt About "Cracking" PGP by DERoss · 2012-12-20 09:42 · Score: 2

OpenPGP as implemented in Pretty Good Privacy (PGP), Gnu Privacy Guard (GPG), and possibly other applications is a private-key/public-key encryption method. You encrypt with the public key, which cannot decrypt what it encrypts. Thus, the whole world can have copies of your public key. You decrypt only with your private key, which does not encrypt. Thus, you try to keep your private key truly private.
However, there is another consideration. You have a pass phrase that is used to encrypt your private key for storage on your computer. That is, your private key exists on your computer only in an encrypted form that cannot be used without first decrypting it with your pass phrase. My pass phrase has well over 30 characters (over 240 bits), including blank spaces and special characters. It exists only in my head plus on a piece of paper in a very secure and remote location in case I drop dead.
I use PGP. To decrypt a file, I must enter my pass phrase, which PGP then uses to decrypt my private key. PGP then uses the decrypted private key to decrypt the file. The decrypted key is in a cache and can be reused so that I do not have to keep typing my pass phrase. The cache is automatically purged after a user-set interval of time. I can also manually purge the cache, which I always do when I am through decrypting. Purging the cache should be standard procedure for anyone concerned about keeping encrypted data secure.
Thus: (1) Even if my private key is compromised (e.g., captured), it is really useless without my pass phrase, which does not exist electronically. (2) Proper procedures prevent access to the cached decrypted copy of my private key.
Of course, all this is overcome if a key-logger or other means is used to capture the input of my pass phrase. If that happens, I have greater problems than someone decrypting files I want to protect.
regarding true-crypt and the hibernation file by clovis · 2012-12-20 11:01 · Score: 5, Informative

I don't think that it is interesting that someone has figured a way to hack a running computer that they have physical access to.
However, the hibernation file inspection hack had bothered me, or rather didn't bother me after I read the document.
Check out http://www.truecrypt.org/docs/hibernation-file
from the link:
Note: The issue described below does not affect you if the system partition or system drive is encrypted* (for more information, see the chapter System Encryption) and if the hibernation file is located on any of the partitions within the key scope of system encryption (which it typically is, by default), for example, on the partition where Windows is installed. When the computer hibernates, data are encrypted on the fly before they are written to the hibernation file.
When a computer hibernates (or enters a power-saving mode), the content of its system memory is written to a so-called hibernation file on the hard drive. You can configure TrueCrypt (Settings > Preferences > Dismount all when: Entering power saving mode) to automatically dismount all mounted TrueCrypt volumes, erase their master keys stored in RAM, and cached passwords (stored in RAM), if there are any, before a computer hibernates (or enters a power-saving mode). However, keep in mind, that if you do not use system encryption (see the chapter System Encryption), TrueCrypt still cannot reliably prevent the contents of sensitive files opened in RAM from being saved unencrypted to a hibernation file. Note that when you open a file stored on a TrueCrypt volume, for example, in a text editor, then the content of the file is stored unencrypted in RAM (and it may remain unencrypted in RAM until the computer is turned off).
Note that when Windows enters Sleep mode, it may be actually configured to enter so-called Hybrid Sleep mode, which involves hibernation. Also note that the operating system may be configured to hibernate or enter the Hybrid Sleep mode when you click or select "Shut down" (for more information, please see the documentation for your operating system).
To prevent the issues described above, encrypt the system partition/drive (for information on how to do so, see the chapter System Encryption) and make sure that the hibernation file is located on one the partitions within the key scope of system encryption (which it typically is, by default), for example, on the partition where Windows is installed. When the computer hibernates, data will be encrypted on the fly before they are written to the hibernation file.
Note: You may also want to consider creating a hidden operating system (for more information, see the section Hidden Operating System).
Alternatively, if you cannot use system encryption, disable or prevent hibernation on your computer at least for each session during which you work with any sensitive data and during which you mount a TrueCrypt volume.
* Disclaimer: As Windows XP and Windows 2003 do not provide any API for encryption of hibernation files, TrueCrypt has to modify undocumented components of Windows XP/2003 in order to allow users to encrypt hibernation files. Therefore, TrueCrypt cannot guarantee that Windows XP/2003 hibernation files will always be encrypted. In response to our public complaint regarding the missing API, Microsoft began providing a public API for encryption of hibernation files on Windows Vista and later versions of Windows (for more information, see the Version History, section TrueCrypt 5.1a). Since version 7.0, TrueCrypt has used this API and therefore has been able to safely encrypt hibernation files under Windows Vista and later versions of Windows. Therefore, if you use Windows XP/2003 and want the hibernation file to be safely encrypted, we strongly recommend that you upgrade to Windows Vista or later and to TrueCrypt 7.0 or later.