If you're encrypting the data on your hard drive using OS-level software encryption (e.g. Windows EFS, Vista BitBlocker, MacOS FileVault, Linux DM-Crypt, or TrueCrypt ), then a research study at Princeton University, partially funded by the Department of Homeland Security, has figured out how to read that data without your password.  Well, that's just great.

Let me see if I can summarize the essential elements of the story:

• In order for OS-level encryption to work, the unencrypted keys must be held in RAM
• This includes when your system is powered on after a suspend or hibernation sequence.  As soon as you see the Windows/Mac/Linux login prompt, the unencrypted key is now in RAM.
• Data stays in RAM after it's powered off, from seconds to minutes
• Here's the exploit:
1. Black hat steals laptop & powers it on
2. Laptop comes up to login prompt
3. Black hat plugs in USB device with special hack/boot software
4. Optionally the black hat sprays an upside-down can of compressed air on your RAM chip to freeze it.  This causes the RAM chip's residual image to last much longer after power off, as in 10 minutes or longer.
   
5. Black hat unplugs system (with battery out), then immediately plugs it back in
6. This time the special boot/hack software copies the residual image in RAM to a file on the USB stick/drive
7. Now they've got all day to scour the RAM image to find the unencrypted key.  Of course they don't need that long.
8. Once the find the key, they can use it to access all the encrypted data on the drive -- even without your password

And there you have it.  With a little bit of know-how (which they don't divulge any more than I have), and a can of compressed air if you want to take your time (good thing those are hard to find), you can render OS-level encryption completely worthless.  They've demonstrated the exploit against Windows EFS, Vista BitBlocker, MacOS FileVault, Linux DM-Crypt, and TrueCrypt -- and they broke every one of them.  They believe that pretty much all versions of OS-level encryption will be vulnerable to this attack.

What are you to do?  It sucks that you have to do this, but the answer is simple. If you are using OS-level encryption, the following two steps would work.

• Don't suspend, hibernate, or leave your system powered on when you leave it
• When you do power it off, wait a few minutes for the residual image in RAM to fade before you leave it unattended
  

They did mention in the report that some systems require you to enter a hard-drive level password before it will read the OS image and wake up from being suspend, and that systems so configured were also not vulnerable to this attack.  But if when your system wakes up from hibernation/suspension, it comes right to a Windows/MacOS/Linux login screen, you are SOL.

Read the whole study here. Watch their YouTube video of a sample attack here.  There's something about watching how easily they do it that's just downright eerie.  If you're curious what a frozen RAM chip looks like, here you go.

Have a nice day. ;) 

Comments

Add New Search

ddierickx   | 170.86.15.xxx | 2008-02-27 01:34:13 Well, security is a whole package, you cannot just install one tool or adjust one setting and then call the system secure. Also, as the world and systems evolve you'll need new security measures to protect yourself. Anyway, what i want to say is this: - disable any boot devices in the bios, except the internal HD - put extra password protection on bios & hd boot only with those 2 additional protections it should already be much harder to get your encrypted HD data hacked. Putting the HD in another laptop wont do you any good because it is protected by a password.

cpreston - I think that's the point of the story   | Super Administrator | 2008-02-27 11:49:01 I think my point (and apparently their point) is that people are installing OS-level encryption systems specifically to protect them in the case their laptop is stolen, and they're NOT being protected -- unless they put a boot password on their hard drive. Here's a question that I just thought of. If the true protection is the boot password on the hard drive, why encrypt? If the user has a boot password and you don't have it, can you get around that by putting it in another computer and reading the unencrypted data?

cdevidal - re: I think that's the point of the story   | 71.137.136.xxx | 2008-04-18 02:41:46 cpreston wrote: Here 's a question that I just thought of. If the true protection is the boot password on the hard drive, why encrypt? If the user has a boot password and you don't have it, can you get around that by putting it in another computer and reading the unencrypted data? ddierickx has a point; if you combine OS-level encryption with a bootup BIOS password and disable any form of booting except the internal hard disk, the Princeton black hats won't be able to run their program. On the other hand, they could just pop the RAM into another computer and fetch the keys, then later at their own convenience pop the hard drive into another computer and bingo, there goes your data. From their FAQ, this is the best way to mitigate this risk: [i]Q. What can vendors do to protect against these attacks? A. We discuss several potential mitigation strategies in our research paper, though many of these would require...

cdevidal   | 63.95.64.xxx | 2008-02-29 14:49:51 Oops the rest of the FAQ got cut off: [i][b]Q. What can vendors do to protect against these attacks? A.[/b] We discuss several potential mitigation strategies in our research paper, though many of these would require hardware modifications or substantial changes to the way disk encryption software is designed and used. The best software-only solution would be to encrypt the disk key with a password whenever the computer enters an inactive state, so that it will not be useful to an attacker even if it is copied from RAM. Unfortunately, this means the computer itself would not be able to access the disk until the user enters the password, so this approach might not be practical when the computer is in certain states, such as at a locked screen saver. (Some disk encryption products, including Microsoft?s BitLocker in ?advanced mode,? implement a form of this protection when the computer is powered off or hibernating.)[/i] I think I'll go ...

res66 - Passwords...   | 170.40.160.xxx | 2008-04-16 01:46:04 This may well have changed, but the HD passwords can be circumvented by connecting the laptop drive to a standard desktop with an adapter. Thus, putting a password on the drive does not decrease the need for encryption. Assuming the system has no hardware feature to reset the BIOS, removing the boot devices from startup and locking the BIOS (and HD) is a good measure, for a number of reasons.

ddierickx   | 170.86.15.xxx | 2008-04-17 03:01:02 no, i wasn't saying that only password protection is good enough. it's the whole picture that makes it more secure. just think about where we came from. in the early days, you just turned on your pc and you got a prompt, anybody had access. then you had to use a username & password to login to the desktop. it didn't stop there and what we have now (passwords, encryption, etc.) won't be enough 5 years from now.

Hummdis - Firm belief...     | 24.56.11.xxx | 2008-04-18 22:57:04 I've always had a firm belief, that once someone has physical access to a system, they may do whatever they want. A jumper on the motherboard will by-pass a BIOS password (I've done it several times) or the same jumper can reset the whole BIOS (password and all) that give you access to boot from any device that you want...say a live Linux distro. Once booted, you can hack away at the "encrypted data" and read everything back as it was originally on the disk. I have first hand witnessed users that use the Apple FileVault actually corrupt the users folder! Now, from a logic standpoint, why would you use a utility that was even capable of doing such a thing? Bottom line - the whole picture increases the odds for your data, but there is no rock-solid way to protect your data. Seriously.

Only registered users can write comments!

Powered by !JoomlaComment 3.12

Copyright (C) 2007 Alain Georgette / Copyright (C) 2006 Frantisek Hliva. All rights reserved.