Today eight colleagues and I are releasing a significant new research result. We show that disk encryption, the standard approach to protecting sensitive data on laptops, can be defeated by relatively simple methods. We demonstrate our methods by using them to defeat three popular disk encryption products: BitLocker, which comes with Windows Vista; FileVault, which comes with MacOS X; and dm-crypt, which is used with Linux. The research team includes J. Alex Halderman, Seth D. Schoen, Nadia Heninger, William Clarkson, William Paul, Joseph A. Calandrino, Ariel J. Feldman, Jacob Appelbaum, and Edward W. Felten.
Our site has links to the paper, an explanatory video, and other materials.
The root of the problem lies in an unexpected property of today's DRAM memories. DRAMs are the main memory chips used to store data while the system is running. Virtually everybody, including experts, will tell you that DRAM contents are lost when you turn off the power. But this isn't so. Our research shows that data in DRAM actually fades out gradually over a period of seconds to minutes, enabling an attacker to read the full contents of memory by cutting power and then rebooting into a malicious operating system.
Interestingly, if you cool the DRAM chips, for example by spraying inverted cans of "canned air" dusting spray on them, the chips will retain their contents for much longer. At these temperatures (around -50 °C) you can remove the chips from the computer and let them sit on the table for ten minutes or more, without appreciable loss of data. Cool the chips in liquid nitrogen (-196 °C) and they hold their state for hours at least, without any power. Just put the chips back into a machine and you can read out their contents.
This is deadly for disk encryption products because they rely on keeping master decryption keys in DRAM. This was thought to be safe because the operating system would keep any malicious programs from accessing the keys in memory, and there was no way to get rid of the operating system without cutting power to the machine, which "everybody knew" would cause the keys to be erased.
Our results show that an attacker can cut power to the computer, then power it back up and boot a malicious operating system (from, say, a thumb drive) that copies the contents of memory. Having done that, the attacker can search through the captured memory contents, find any crypto keys that might be there, and use them to start decrypting hard disk contents. We show very effective methods for finding and extracting keys from memory, even if the contents of memory have faded somewhat (i.e., even if some bits of memory were flipped during the power-off interval). If the attacker is worried that memory will fade too quickly, he can chill the DRAM chips before cutting power.
There seems to be no easy fix for these problems. Fundamentally, disk encryption programs now have nowhere safe to store their keys. Today's Trusted Computing hardware does not seem to help; for example, we can defeat BitLocker despite its use of a Trusted Platform Module.
For more details, see the paper site.
Front page posts
If the attacker has physical access to the system when it's powered up, I've always assumed all bets are off. Given that the attacker may have already captured the user's login password, they can certainly bypass the screen-saver lock, so they could easily have access to the mounted encrypted drive via that mechanism. If these products don't ditch the keys when the screen is locked, perhaps they'll start doing that in the future. If someone manages to access an unlocked, unattended machine, shame on whoever walked away from it. Presumably these encrypted partitions are never made accessible over the network (i.e. as a share), so they don't need to be accessible when the user isn't there. If the user has to re-type their disk password when they unlock the screen-saver, I suppose that's the price we need to pay for this level of security.
Cheers, I guess sharepoint java can get us some Freedom at the Disk Encryption with Microsoft's packs.
I don't like cold boots at the summer despite all ;-)
used compound bows unlocked apple iphone
[...] New Research Result: Cold Reboot Attacks on Disk Encryption This was written by Wayne. Posted on Thursday, February 21, 2008, at 10:35 am. Filed under Uncategorized. Bookmark the permalink. Follow comments here with the RSS feed. Post a comment or leave a trackback. [...]
Billb,
The whole point of disk encryption is to protect file contents if an adversary gets physical access to the computer. Our results show that most file encryption systems don't actually provide such protection, even if the adversary has no advance information (e.g., no knowledge of the user's password).
Are there solutions for this that wouldn't impose a possibly-unworkable burden on the user, say some kind of two-level scheme where a less-sensitive working set is available through a key that does persist in RAM, and the rest of the disk is encrypted with a volatile key?
Obviously persisting keys could be protected by some kind of security-through-obscurity mechanism (e.g. by having part of the key on a removable dongle) but ultimately that would get you only so far. Nice work.
Well, that's rather...unsettling.
Question: if the system firmware were reprogrammed so that it overwrote RAM with zeroes on startup, before booting an operating system, could this hole be closed? Or is that infeasible? Would it even work?
Avi,
As we explain in our paper, even that isn't enough. An adversary can remove the chips from the target computer and transplant them into another computer that doesn't overwrite RAM on startup.
I should have guessed as much. Rats.
Well, I shall have to read the paper carefully. I'm glad you and your colleagues chose to publish it online, freely available.
Does a similar attack work for SRAM cache memory in the CPU?
The moral of the story: for maximum protection, shut down the computer when you are not present.
Perhaps during shutdown, a small resident memory-eating program could be executed after the disk is unmounted, to overwrite memory prior to power-off.
Nick,
I don't know for sure. I would guess the CPU marks cache lines as invalid on boot, which would prevent a problem. But only experiment, or careful datasheet reading, can give a sure answer.
Another strike against suspend-to-RAM, I suppose. One way to protect against this method is to power down the laptop prior to allowing it to leave your personal possession. At operating temps, the values in the RAM would be gone by the time an attacker had the chance to read them. A laptop is suspend mode, however, will provide the attacker plenty of time to cool the chips prior to cutting power and attempting to read them.
Full Disk Encrypting (FDE) hard drives perform the encryption in hardware directly on the hard drive, using a key that never leaves the drive. Such FDE drives are protected against this attack on off-drive encryption.
This sounds like computer needs a battery-backed chip that erases memory after power is cut off.
Ed, I don't see how that addresses what I wrote. There's a difference between getting physical access while the computer is on and getting that access by stealing a powered off machine (say while it's turned off in your bag). If you're regularly leaving your drive-encrypted laptop lying about powered up and unattended, that's irresponsible. If the disk encryption folks don't let you automatically lock the drive (and scrub the key from RAM) when you lock the screen-saver, that's bad, too.
I personally don't keep my laptop iced down, so this only seems to be a worry for attackers who can get access to a powered up and unlocked machine.
BTW, I enjoyed the paper and think it's good work, but I don't think the circumstances are as dire as you suggest in your blog post (the paper itself seems less dire). Clearly one should lock one's encrypted drive when one locks one screen-saver. If these products don't make that easy, good on you for calling them out on it. But to say that there's no easy fix seems to over state the case to me. There's no reason to keep the encrypted drive unlocked and mounted when not in use by the user. These products should scrub their keys when the machine is asleep, hibernated, or locked. If these simple precautions are taken, I don't see what concerns remain.
For a fact seems that online offers are very often the right choice.
Any case to itself you know, but selling software systems might do the job with a strong machine and server which will be protected from attacks and backup for data at rest. Well protection on device is necessary.
Don't a lot of brownout/reset chips generate an interrupt when the power goes off? In that case, grab the irq (preferably an nmi), and wipe the relevant bytes. Should be quite doable in its last remaining gasps of activity.
[...] Via Freedom to Tinker. [...]
wow interesting read
still not yet sure i can believe it
but if this is true, how comes the design has such an apparent weakness?
i mean, people readily care about destroying data on hdd but i cant recall anyone bothering about the ram at all...
@dave-O: "Another strike against suspend-to-RAM"
No. Nothing prevents encryption code from clearing the passphrase from memory on suspend. Indeed, it *should*, just as the desktop will require re-login from screensaver and keychain will forget its keys.
Alan, Ed:
SRAM is a fundamentally different circuit than DRAM, so it's unlikely that this will work. A DRAM bit is a capacitor, which, by its nature, stores charge without requiring a power source. However, because the capacitor is leaky, it must be refreshed often.
An SRAM bit is a two inverters feeding each other. Without power, there's no storage of data. I suppose that there might be some parasitic capacitances in the bit, but they'd be much smaller than the purpose-designed DRAM capacitor.
Would something like memtest86 do for RAM what shred etc. does for physical drives? I.e. if one would reboot into memtest wouldn't the contents of the RAM chips be overwritten multiple times with fairly random data?
No big surprise. I've read multiple articles before about being able to actually recover even previous generations of RAM data with special equipment. So it's not terribly surprising that the current data set lives longer than people expect. Also, ages ago on my old PC/XT, I was typing a paper when we were hit with a 3-4 second power outage. When the power came back on I was quite surprised that the computer resumed right where it left off! I figured it was just capacitance in the power supply supplying just enough power to keep the RAM alive (even though the drive spun down).
As an imperfect solution, an OS could provide a service that carved out a small portion of the CPU cache or elsewhere on the CPU for a "master key" and provide an API where programs that needed to store encryption keys in RAM could have them encrypted by the master session key before storage and decrypted on-demand. Even better if the OS could guarantee that the clear-text keys never resided in RAM for more than a fraction of a second, if at all. On computers where there is on-CPU storage that is not "forced" back to RAM without an OS-veto, this can be done today.
Tomas, the technical term is, ASS-U-MEing, I believe. Everybody assumed the
memory would clear on powerdown. Well, turns out it just doesn't fade quickly
enough. Whoops.
Thinking about it for two seconds; implement quick encryption of the cpumemory bus for at least a ``safe'' storage for such things, possibly
anything that doesn't need to be written to disk, and keep the key only in the cpu.
That requires cpu support and extra logic on its memory bus, so it's not an easy fix. But once implemented in the cpu, it's a drop-in replacement in hardware, then add software support.
I will do the easier thing first and venture to read the paper. :-)
"This is deadly for disk encryption products because they rely on keeping master decryption keys in DRAM."
It would seems simple to insert malicious code into an exploitable kernel to extract the keys.
I don’t see how this chilled-RAM attack increases risks under normal circumstances. If the user is at the PC, the attacker cannot access the RAM unnoticed. When the user leaves, the attacker has a few seconds to run to the PC left alone, to boot into a malicious OS (from CD or external disk) and search for a key left in RAM. It can be a problem in public computers (library), but there you should never expose any secrets. In workplaces this attack is unrealistic. Maybe at unattended servers, where the attacker can get a memory dump this way? But he does not have to cold boot: just reboot from CD. The RAM content stays intact. The only danger is when you switch off your PC and immediately walk away. This is bad practice, anyway, because the PC sometimes hangs during shut down, so you always have to make sure that the PC is completely powered down.
However, it has been recommended for ages that encryption keys are never stored in RAM. They have to stay in a locked part of the processor cache. It was not because of the chilled-RAM effects, but because of virtual memory (swap file), or hibernation. The OS might write any info from RAM to disk, where an attacker can find it later. It is surprising that BitLocker does not follow this practice. TrueCrypt is known to be weak both in the choice of algorithms and their implementation (an example is their recent choice to implement the IEEE P1619 encryption standard meant for completely different type of applications).
billb says: "These products should scrub their keys when the machine is asleep, hibernated, or locked."
I would add: ... or when it is being powered down. This simple precaution would have prevented breaking these SW disk encryption products. Still, encrypting disk drives are safer: accessing their key store requires much more work: disassembling the drives, freezing the controller chip, shaving off its cover, inserting micro-probes or ion-implanted contacts, etc., which requires multi-million dollar investment.
Nice results, although not quite as surprising as it seems. For instance, the effect of cold on memory has been known for a while as a vulnerability for keys in DRAM (cf. the papers on the IBM 4758 secure co-processor, for example). There are also hardware methods of reading the memory if you can get to the board without shutting down the system.
The key is also vulnerable to root kits, trojan software with privileges to read memory, and other software attacks.
People who think that encryption is equivalent to security are always surprised by results like this. They should go (re)read Thompson's "Reflections..." piece. :-)
Nick and Dan: Need some SRAM? Check your video card, if it is one that has its own video frame buffer space. Some of them use SRAM for higher speed.
I've often wondered about a slightly different approach to the same purpose: a hot-pluggable expansion card that uses DMA to copy all of main RAM to an external device. PCMCIA is by design hot-pluggable and I wouldn't be suprised if through careful design it weren't possible to make a device that could be gently powered up on a standard PCI bus without crashing the CPU. Whether it's possible to get the DMA controller and other mobo hardware to allow unfettered DMA access without OS cooperation is beyond my hardware knowledge, but it wouldn't suprise me.(wholesale lingerie)
Bart van Deenen - Just what I was thinking! In fact, since power supply filter caps store enough energy for a few milliseconds operation, the power-down IRQ could potentially be generated as soon as the system senses the power switch or loses the AC line connection. This would require mods to the PC hardware and BIOS though, so it's no immediate solution.
Dan Bodoh - SRAM retains some data through a power cycle as well. I can remember an old machine I had that used SRAM for video memory. If I cycled power on it, the previous contents of the screen would still be there before the thing cleared it during the subsequent reboot. This effect could be observed even hours later.
Basically all these suggestions are interesting but don't work on current hardware, which I think was Ed's point.
A solution touched on by "xxx" would be to overwrite the memory containing the decryption key whenever the computer is locked/suspended/slept. The user is (or should be) required to re-enter their password when accessing the computer again, which would unlock the disk at the same time without undue burden on the user.
This seems trivially easy to implement for the OS-integrated protection such as BitLocker and FileVault. The only circumstances under which the disk would still be vulnerable is power removal when still logged in, but at that point an attacker has full access to the system anyway.
Sorry, Ed, I've been hearing about this technique since the 90s. It's not new. Rumour is that spooks have been using it for some time.
Here's an old message board threat a quick google search found...
http://www.madisonlinux.org/pipermail/madlug/2003-October/007264.html
Dan Bodoh: check out the paper by Skorobogatov cited in our paper; it reports retention in SRAMs at room temperature. An electrical engineer has explained the physical basis of this to me, although I do not entirely understand the explanation (it is somewhat more intuitive to understand for DRAM retention). If you have an SRAM somewhere outside of your CPU cache, you may be able to reproduce Skorobogatov's result. :-)
There are probably retention effects in CPU caches, but whether they can be exploited for anything does seem to depend crucially on whether the CPU (or firmware?) invalidates the cache before attack software could potentially read those caches.
Brad,
We've heard these rumors too, but we couldn't find anything in the published literature. Our study goes into considerable depth in evaluating the usefulness of these methods today, and in considering countermeasures.
Several posts have suggested clearing the key from memory when the computer is screen-saver locked but still powered up.
This is not possible, as the operating system and processes keep running while the computer is locked.
I'm not an EE, but I wonder if it would be easy / cheap to develop 'secure DIMMs' that would open the RAS/CAS wide and drain all the capacitors to some load the moment power loss occurs? The solutions that rely on motherboard / power supply capacitance to give the CPU a chance to clear the keys ignore the possibility that someone simply yanks the DIMMs out of a running system.
I'm going to +1 Laszlo here. Any claims of security should be, by nature, understood to have limitations and caveats. On-disk encryption protects against certain attacks, in particular someone getting access to the disk --- the surface, or via the disk heads. In this attack, someone must gain physical access to the device, be able to either disassemble it or act on it within minutes, or bring the appropriate pieces to near cryogenic temperatures within those minutes in order to prolong the retention, then be sufficiently technically sophisticated to extract the keys and then read the disk.
It would seem the conditional probability of success over this chain of events is pretty small; thus the actual risk would be relatively small.
Should this be considered for TOP SECRET or SECRET? Sure, there the hazard is large. For common data, where the actual hazard is tens or hundreds of thousands of dollars? not so clear.
Seth,
Assuming SRAM state can be retained, I doubt an invalidated cache is any more secure - a valid or invalid cache line is simply indicated with another SRAM bit, and not necessarily by destroying the actual contents of the cache.
[...] Felten writes on Freedom-to-Tinker: Today eight colleagues and I are releasing a significant new research result. We show that disk [...]
The real issue revealed by the paper is not weaknesses in disk encryption software, but a cheap way to go around DRM, and code privacy. You run the protected code, like a DVD player or a game in one PC, freeze and move the RAM to another machine (can be the same one rebooted to DOS), where you can analyze the memory at your leisure. You can disassemble protected code, find media keys, etc. It is simpler and cheaper than using high speed, logic analyzers on memory lines.
as Ed Felton said...Dram remanence has been known about for a long while.... SRAM remanence is harder but it exists... I've heard SRAM may also be induced to have power-on preferences through extended V and T.
Jeff Tyrrill Says: “…clearing the key from memory when the computer is screen-saver locked but still powered up… This is not possible, as the operating system and processes keep running while the computer is locked.†The disk encryption key can be erased, if the screen saver, log-on process, etc. run in memory. Preventing disk accesses there is not a trivial change to the OS, though.
A simple way to deter these sort of attacks would be to not accept USB boots and lock the bios.
Joshua,
Actually, that countermeasure isn't enough. An attacker could still remove the DRAM and transplant it into another computer that has a friendlier BIOS.
What about the fix suggested above, not to clear the key on screen-saver lock, but to clear the key on sleep (plus hibernate and shutdown of course)? Surely the great majority of computer thefts are laptops, and the great majority of laptop thefts would find the system in a suspended state. You're going to want to ask for the password again anyway on resume from any of these states. Isn't this an easy fix that addresses 90% of the problem?
Unintended retention of cryptographic materials has long been a threat known by intelligence agencies. They have a term for removing this information: "Zerosation"
See http://en.wikipedia.org/wiki/Zeroisation
FIPS Pub-140 places requirements on encryption devices used in providing various levels of protection. This document specifies when zeroisation must be used.
See http://csrc.nist.gov/publications/fips/fips140-2/fips1402.pdf
I suggest that you update the paper to cite FIPS 140.
Joshua, if you read the full article, you'll see that the RAM does not need to be booted in your system. Someone could theoretically walk in, detain you, open your PC case, chill your RAM, pull it out and boot it in some specialized hardware they may have available. Not that something like this happening is common place, but still very possible.
I wonder if the effort to impose security on boot up aren't approaching the problem from the wrong end--what about having some over-writing occur on power down?
Of course, I assume that the attacker wouldn't necessarily power down the system through the OS, but unplug-it.
This would require some special hardware, I would think that would be able to execute code upon detection of power down.
You wouldn't necessarily have to complete zero the contents--a certain amount of scrambling would do enough damage to the data, right?