PGP, TrueCrypt-encrypted files CRACKED by £300 tool ElcomSoft has built a utility that forages for encryption keys in snapshots of a PC's memory to decrypt PGP and TrueCrypt-protected data. Forensic Disk Decryptor attempts to unlock information stored in disks and volumes encrypted by BitLocker, PGP or TrueCrypt. The tool is designed for criminal investigators, IT security bods …
If anyone has ever read the Truecrypt site and forums they would already know 2 things.
Hibernation and encryption don't work securely together. and,
Disk encryption doesn't protect an open encrypted volume.
Only a system that is designed to clear the encryption key out of memory at hibernation and ask for it again when waking up is secure to go to sleep. Other then that, turn it off. I need to to experiment with SSDs using full disk encryption to see what the performance is like for full shutdowns and startups. Oh, and if you ever use a SSD on for an encrypted disk and want to change your key, move all your data off and do a factory wipe on it.
Precisely. And PGPDisk goes as far as to disable hibernation by default. And clears the key from memory when no longer needed. And has a timeout after which it dismounts the disk (as does TrueCrypt).
Plus, if this tool can sniff the disk encryption key only when the drive is mounted - what is the point? If the drive is still mounted, you can simply copy its contents - the disk encryption software will decrypt it on-the-fly for you. Not to mention that it is much simpler to install a keylogger (even a hardware one) than to sniff the computer's memory.
This whole thing sounds like a lot of self-serving hype from the part of ElcomSoft.
"Plus, if this tool can sniff the disk encryption key only when the drive is mounted - what is the point? If the drive is still mounted, you can simply copy its contents - the disk encryption software will decrypt it on-the-fly for you."
Exactly. The point is that you're tainting the evidence. I presume the way this is meant to be used is that you read the key from memory and save it somewhere such as a USB stick, then you power off the computer, make a forensic copy of the discs, and decrypt the copy with the key you have availed yourself of.
Of course, you need prior intelligence or a keen instinct to know that encryption might be in use, as the standard forensic procedure is to walk up to the computer (take video, pics, notes, etc.) and pull the cord from the back of the machine (not the power outlet), or remove the battery in the case of a laptop or similar portable device. If you only discover that the target uses encryption by the time you have cloned the disks you'll be banging your head against the desk for a bit and eventually resort to some hopefully legalised form of rubber hose cryptanalysis.
The option to do Whole-Disk Encryption in TrueCrypt will encrypt the hibernation file as well. You are required to enter your decryption key upon start-up/resume, where it then decrypts the boot volume (with the hibernation file) and then continues to boot as normal. So even Hibernation with whole-disk encryption is safe for TrueCrypt installs.
Absolute silliness.
First, one never caches passwords.
Second, one ALWAYS unmounts encrypted devices before entering hibernation.
Third, one sets up a high explosive charge on the device in hibernation, as the BOFH and I agreed was a proper security practice.
And DO look up BOFH, if you don't know what that is before you spill idiocy in the false form of grief over the last bit of humour.
I was investigating a discrepancy between [used+free space] and [total space] of roughly 8GB (his RAM size) as displayed by Explorer on my mate's Win7 computer the other day... first Google result suggested a hibernation file could be responsible. It was. He has never used hibernation, so is this file just reserve the space for OS feature, or does it actually contain RAM contents?
No biggie, just curious.
[Edit: Ryan's comment below would suggest that it contains RAM contents]
What happens is that, when hibernation is enabled, a file called HIBERFIL.SYS is allocated in the boot root directory. It's as big as your RAM allocation and is created to ensure the necessary space for hibernation is ready at hand. Once you hibernate once, the file will contain the RAM contents at the point of that hibernation. I would think HIBERFIL.SYS at any given point will thus contain the RAM contents of the last hibernation.
> you'd have to have made someone enter the password in the first place?
Which is exactly what the article says. You have your nice secure laptop using an encrypted disk. When you boot it, it asks for the key to access files on the disk. When you enter that key it saves it somewhere handy in RAM so you don't need to enter it again and again.
One way around that would be to not store the key, but as the article says, you'd then get a popup asking for it every time you open a file or folder, or write to a file.
I'd have thought an obvious fix for the hibernate/sleep situation would be for the encryption software to catch whatever "hibernate beginning" signal gets sent, and rapidly zap the key. You'd need to enter it again after wakeup, but that's no major hardship.
Let's say you've only ever used Hibernate once, by accident, two years ago, and you happened to have a TrueCrypt volume mounted at the time. Now, two years later, an investigator can look at that once-used hibernation file, extract your TrueCrypt password - assuming you haven't changed it since - and have unfettered access to the current disk contents in that volume.
It only takes one slip in the complete life history of an encrypted item to invalidate any protection against a determined foe. That's why crypto is worse than useless in less-than-expert hands - it's actually harmful, as it gives a completely false sense of security unless utterly faultless data hygiene is observed.
This ^
If you're using whole disk encryption, then oddly enough, the whole disk is encrypted.
Of course, if you were planning to had over the password for the whole disk, and you had encrypted containers with the really secret stuff on them, then you're at risk.
Hibernate's a pain in the backside nowadays. With a few gigs of RAM hibernating takes ages and it's quicker to boot from scratch.
Are you using "hibernate" or "sleep"?
Laptops have a sleep mode where the computer goes into a low power mode and keeps memory in RAM.
"Hibernation" is possible on any PC: Windows writes the full system state to disc then powers down.
If your computer takes a few seconds, it's just taking a nap, not bedding down for the winter, so it keeps the power connected to RAM while cutting the processor and hard-drive.
'My 64-bit Win7 lappy hibernates in a few seconds and it has 8 gig of ram...."
Really? On a laptop? Well my desktop with the hibernate file located to it's own physical drive away from the O/S drive has 16GB and it still takes in excess of 90 seconds to fully hibernate the system and a full power down. You sure you're not getting confused with sleep ( ultra low power mode but RAM still powered )?
I have a Corei5 Win7 Laptop with 6GB of Memory and a Samsung 256GB SSD - encrypted with whole disk encryption which does slow it down - at a guess maybe 20% performance degradation.
I ran a quick test. It takes 21 seconds to hibernate. (Yes definitely hibernate not sleep)
It resumes from hibernate in 30 seconds to the desktop with all my programs running.
That's roughly the same time the same machine takes to boot with none of my programs running.
Definitely worth it in my opinion. I always use it. Have used it with various machines for about 10 years. Never had a problem with it. It's just nice to start off where you left off, and also means the machine isn't sucking juice when you don't need it.
Maybe once every couple of months I give it a reboot simply because the up time starts to become quite ramp up significantly quickly .... probably isn't necessary but kind of a habit.
Which is why you should use full disk encryption or set your truecrypt drives to unmount themselves after some time of inactivity. When you unmount a drive Truecrypt actively erases they key from memory. Truecrypt also tries to make sure master keys don't hit the page file.
http://www.truecrypt.org/docs/unencrypted-data-in-ram
Would that really work? - it is windows that deals with "resurrection" from hibernate, and I don't think it has the option within this low-level code to put up a screen and ask you for the password? Maybe it does.
Clearly the answer is to type the key in every time you return to the computer.
I find yellow sticky-notes are useful aides to remembering these sorts of tediously long numbers.
Windows does deal with resuming from hibernate. It doesn't deal with the Truecrypt password though. There's a boot loader in the MBR which Truecrypt uses to prompt for the password. If the password is correct, it hands over to the boot loader on the partition (ntldr or whatever....)
The Register 
Biting the hand that feeds IT
Copyright. All rights reserved © 1998–2024
