Disk encryption security flaw found; notebooks in ‘Sleep’ or ‘Hibernation’ mode most vulnerable

A team including the Electronic Frontier Foundation (EFF), Princeton University, and other researchers have found a security flaw in several popular disk encryption technologies that leaves encrypted data vulnerable to attack and exposure.

“People trust encryption to protect sensitive data when their computer is out of their immediate control,” said EFF Staff Technologist Seth Schoen, a member of the research team, in the press release. “But this new class of vulnerabilities shows it is not a sure thing. Whether your laptop is stolen, or you simply lose track of it for a few minutes at airport security, the information inside can still be read by a clever attacker.”

The researchers cracked several widely used disk encryption technologies, including Microsoft’s BitLocker, Apple’s FileVault, TrueCrypt, and dm-crypt. These “secure” disk encryption systems are supposed to protect sensitive information if a computer is stolen or otherwise accessed. However, in a paper and video published on the Internet today, the researchers show that data is vulnerable because encryption keys and passwords stored in a computer’s temporary memory — or RAM — do not disappear immediately after losing power.

“These types of attacks were often though to be in the realm of the NSA,” said Jacob Appelbaum, an independent computer security researcher and member of the research team, in the press release. “But we discovered that on most computers, even without power applied for several seconds, data stored in RAM seemed to remain when power was reapplied, We then wrote programs to collect the contents of memory after the computers were rebooted.”

Laptops are particularly vulnerable to this attack, especially when they are turned on but locked, or in a “sleep” or “hibernation” mode entered when the laptop’s cover is shut. Even though the machines require a password to unlock the screen, the encryption keys are already located in the RAM, which provides an opportunity for attackers with malicious intent.

The research released today shows that these attacks are likely to be effective against many other disk encryption systems because these technologies have many architectural features in common. Servers with encrypted hard drives are also vulnerable.

“We’ve broken disk encryption products in exactly the case when they seem to be most important these days: laptops that contain sensitive corporate data or personal information about business customers,” said J. Alex Halderman, a Ph.D. candidate in Princeton’s computer science department, in the press release. “Unlike many security problems, this isn’t a minor flaw; it is a fundamental limitation in the way these systems were designed.”

In addition to Schoen, Appelbaum, and Halderman, the research team included William Paul of Wind River Systems, and Princeton graduate students Nadia Heninger, William Clarkson, Joseph Calandrino, Ariel Feldman as well as Princeton Professor Edward Felten, the director of the Center for Information Technology Policy and a member of EFF’s Board of Directors.

The researchers have submitted the paper for publication and it is currently undergoing review. In the meantime, the researchers have contacted the developers of BitLocker, which is included in some versions of Windows Vista, Apple’s FileVault, and the open source TrueCrypt and dm-crypt products, to make them aware of the vulnerability. One effective countermeasure is to turn a computer off entirely, though in some cases even this does not provide protection.

The full paper “Lest We Remember: Cold Boot Attacks on Encryption Keys,” a demonstration video, and other background information is here.

[Thanks to MacDailyNews Reader “JB” for the heads up.]

31 Comments

  1. Yes, any method of encryption does have to decrypt the information at some point. This mean that the key or data have to be in the free and clear to be used and access.

    You could freeze the chips and tap the bus. This is not breaking the encryption. You are just reading the data in the system.

  2. FileVault is not useful for real security, for a number of reasons. This is one. Compartmentalized disk images that are only in use when necessary are a much better solution – and Apple supports that very nicely.

  3. Brian Allen: Follow-up: They knew the key and searched the memory for it.

    That’s not really necessary – you simply need to check out the typical data pattern around the password structure which stays constant (or at least similar enough) and search for that.

    In Tiger the hibernation RAM image file (which is written every time when going to sleep in the default setting) was unencrypted and thus vulnerable to password extraction.

    My own conclusion was that I simply switched to “suspend to RAM” (the “classic” sleep mode which simply doesn’t write a hibernation file) whenever I was on the road and I did a secure delete of an existing hibernation file.

    Leopard now seems to properly encrypt the hibernation file, so it should not be quite as dangerous any more. And of course this only matters really when you’re using File Vault to begin with.

    The RAM extraction method described above is more difficult to prevent – Apple would have to purge any clear text form of any password from RAM as well – there are more secure methods around, and apparently they are necessary. Dynamic RAM is only gradually different from flash memory, not fundamentally! ” width=”19″ height=”19″ alt=”wink” style=”border:0;” />

    Hint: When you’re coming back to your machine and it has inexplicably been rebooted (check the uptime on the command line or the system logs for traces of a reboot when in doubt!), it may have been compromised. Better yet: Don’t leave a computer with critical data unattended in an uncontrolled environment at all!

  4. Me: FileVault is not useful for real security, for a number of reasons. This is one.

    How so? The actual FileVault mechanism is not in question here. It’s only the password entry itself which can be compromised.

    Me: Compartmentalized disk images that are only in use when necessary are a much better solution – and Apple supports that very nicely.

    Indeed, that is exactly how FileVault works, which contradicts your previous statement…

    Apple needs to redesign its password prompts and the code behind them, that’s it.

    Simple remedy: Immediately after validating the clear-text password (or even after rejecting a mistyped one), overwrite the buffer array with zeroes. Important: Also flush and overwrite all communication buffers (USB, Bluetooth…) through which the password may have been entered and which could otherwise retain another copy!

    When the clear-text password has been erased from RAM immediately after it has been entered, there is no more possibility to “harvest” it from RAM either and the data it may protect is one step safer again.

    Another step would be writing out the RAM to an encrypted hibernation file (when going to sleep) and then erasing the RAM content before shutting down.

  5. What about…: Encypted memory? Can Macs do that? Or only encrypted virtual memory?

    Not for RAM, only on disk for FileVault, virtual memory and the hibernation file.

    Current CPUs and chip sets don’t support RAM encryption yet (among other reasons because of performance costs), but I can see it coming some time down the road.

    Introducing a lock for the RAM compartment would be another option (PowerMac G5s and Mac Pros can already be locked completely).

  6. Well, the article does not specify if the “Use secure virtual memory” is enabled in the System Preferences=> Security under Mac OS X.

    If not that would be the “easy fix” to protect against mentioned risks.

  7. Truecrypt is the best encryption software out there right now for the mac (and every other platform including windows and linux). It doesn’t save your passwords in RAM unless you ask it to (by default it doesn’t).

  8. Name: Truecrypt is the best encryption software out there right now for the mac (and every other platform including windows and linux). It doesn’t save your passwords in RAM unless you ask it to (by default it doesn’t).

    The Apple mechanisms don’t “save” the password in RAM either – they just don’t explicitly delete it after using it. It’s just still lying around even when the program isn’t looking at it any more. That is the problem, and it might very well apply to Truecrypt as well.

  9. Now, I don’t know squat about encryption security etc, but do know how to read and figure things out.

    First saw notice of this story via NY Times, and theirs is a nice article, BUT –

    NO ONE anywhere, no website – especially a windoze site, nada nobody …

    Will have the intelligent and insightful comments we find here on a regular basis, and probably take for granted way too often

    Thanks to all of you posting (relevant) information.

    (others of you having ‘fun’, well, a little levity never hurts. ‘Little’ being key word there ” width=”19″ height=”19″ alt=”wink” style=”border:0;” />

    Again, thank you all for your continued sharing of knowledge, and especially when it involves a really/truly/big-time matter of this nature.

    Appreciate it, BC in Tally

Reader Feedback

This site uses Akismet to reduce spam. Learn how your comment data is processed.