Cold Reboot Attacks on Disk Encryption

jcrouthamel writes "Contrary to popular assumption, DRAMs used in most modern computers retain their contents for seconds to minutes after power is lost, even at operating temperatures and even if removed from a motherboard. Although DRAMs become less reliable when they are not refreshed, they are not immediately erased, and their contents persist sufficiently for malicious (or forensic) acquisition of usable full-system memory images. We show that this phenomenon limits the ability of an operating system to protect cryptographic key material from an attacker with physical access. We use cold reboots to mount attacks on popular disk encryption systems — BitLocker, FileVault, dm-crypt, and TrueCrypt — using no special devices or materials. We experimentally characterize the extent and predictability of memory remanence and report that remanence times can be increased dramatically with simple techniques. We offer new algorithms for finding cryptographic keys in memory images and for correcting errors caused by bit decay. Though we discuss several strategies for partially mitigating these risks, we know of no simple remedy that would eliminate them."

Clear the DRAM?

Could probably implement an algorithm at the operating system level that attempts to clear out DRAM except for what is actually needed for the operating system to power down/boot up. I am not sure of the exact logistics but it seems silly to just power down and leave the DRAM however it was, no matter if its instant cleared or take a few minutes.

Re:Clear the DRAM?

It is possible; I remember reading about a class of programs in the Jargon File that exploited certain machine code instructions to clear out the whole of the machine's memory, including itself.

Can't remember the name of 'em, though.

Re:Clear the DRAM?

death code [catb.org]

Re:Clear the DRAM?

So, that would stop me from physically turning off the computer and popping out the RAM, how exactly? What we need is a battery backed up hardware module that scrambles the RAM when the system loses power.

Use capacitors

You could use a capacitor to power this mechanism instead of a battery. It wouldn't need to last very long -- just long enough to scramble the RAM on power-down. It would be more reliable than a battery.

Re:Clear the DRAM?

As the4thdimension already pointed out, it's a common tenant in systems security that anyone with physical access and sufficient time can disable or otherwise bypass any security system. The fact is, if they're in a position to swipe the RAM out of your computer, they can just as easily take the HD to a secure location to try to brute force it, and/or attach some probes to the RAM and just read the bits straight off it, wouldn't even need to power the system down. Hardware security is just that, hardware, so there will never be an adequate software solution to a hardware security problem. Likewise, software security means nothing if the hardware is vulnerable. It's like building a safe with the most complex and impenetrable locking mechanism ever designed, and then using 1/4" aluminum for the body of the safe, sure no one's going to crack the locking mechanism, but all it takes is 5 minutes with a power drill to bypass it.

That being said, some sort of physical security mechanism probably wouldn't be out of the question for scenarios that actually called for it. For instance, on systems that contain highly sensitive data such as nuclear launch codes or some such, I could envision a tripwire type system on the computer case that detonates shaped charges on the HD and RAM when the case is cracked. This does open up a possible DOS attack vector, but the alternative seems to justify it.

Re:Clear the DRAM?

I think you've missed the point. Hard drive encryption *is* supposed to protect against someone having physical access to your machine.

Re:Clear the DRAM?

Exactly! That is why this news item is actually big news. The idea of encrypting your disk is _exactly_ that someone without the key will not be able to access the data (within a reasonable amount of time - any encryption can be broken), even if they have physical access. And encrypting your disk does indeed prevent someone without the key from reading the data. What TFA tells us is that there is a way to get the key that we may not have considered, and I'm willing to bet many of us indeed hadn't. But now that we know of this attack vector, we can work against it.

As long as we can keep the key hidden, the encryption will protect our data.

Re:Secure DRAM

No, this is the problem; even with a ground, there's a charge held. DRAM isn't a charged-coupled device (CCD), instead, the charge drain doesn't work quickly, allowing DRAM to be read for a short while until things go to zero. The only protection you can give (see other posts) is to forcibly write a charge to all locations, or a sufficient number to scramble the eggs. All DRAM will eventually have cell decay to an unreadable point when the vcc is dropped. Several aforementioned schemes tell how to keep vcc on (capacitors, batteries, who knows-- maybe a DRAM fuel cell-- give your DRAM a drink). SRAM, photo-sensitive RAM, flash, and other ROM-ish RAM devices 'hold' a charge somewhat indefinitely depending on the technology in the device. DRAM eventually loses a detectable charge.

Re:Clear the DRAM?

Thermite grenades, actually, taped to the case. Classified computers in sensitive areas get turned into slag if the position is overrun. (From my days working for one of the giant US 'aerospace' companies.)

Re:Clear the DRAM?

Or we could get rid of this easy to work with RAM that computers have now and go back to the olden days when you had to curse and scream and rip your hands to shreds on sharp metal corners to get at the RAM, which, once you got at was a pain in the ass to remove. Ah, the good old days.

Macbook Air...

has the RAM soldered in the motherboard! I knew Apple was thinking of our security all along!!!

/*ducks*/

Firewire and USB can access memory

Heck, with physical access to a running machine, jack into the firewire or USB port and you have clear access to reading and writing all the memory you want.
I wrote a small paper here http://www.friendsglobal.com/papers/FireWire%20Memory%20Dump%20of%20Windows%20XP.pdf [friendsglobal.com] for a forensics class on using firewire to access memory, subverting the operating system.

All bets are off once physical access is gained. Best bet would be to store the keys, somehow, in the CPU's caches and never let it stay in main memory.

Very real concern

I run my FreeBSD (7.0RC3) system with some geli-encrypted volumes, and one-time encrypted swap and /tmp. Very little data can leak out to non-encrypted space (yeah, /var/tmp is one).

However, for grins one day, I decided to run "dd if=/dev/mem bs=1m count=[mem size] | strings | grep [whatever]" and found not only various passwords, but URLs for sites visited *weeks* ago, even after reboots. So, I installed the "secure_delete" port and ran "smem". No luck -- some stuff got wiped, but some remained in memory. So I booted to a memtest86 CD-ROM, and ran the full test (this test does all kinds of writes/reads to memory). Then, I booted *back* to the normal system, and I was *still* able to recover juicy bits from /dev/mem. WTF?

We need a kernel module for the common OSes that can encrypt virtual pages (is that the right term?) so that whether in core or paged, they won't be vulnerable.

Re:Very real concern

If you are running "dd if=/dev/mem bs=1m count=[mem size] | strings | grep [whatever]" on the machine, your search term will be stored in memory, so you are certain to get a result. You would need to take a memory dump, then run strings on that instead, preferably after it's been transferred to another machine.

Countermeasure here:

This attack is very powerful.

It's not possible to "clear the DRAM" (as others have suggested), because the attacker will boot his own CD and not give control to your OS after the reset. Thus you won't be able to clear anything.

Anything? Not so quick, my dear! For the CD to boot, first there is the BIOS. And BIOS needs memory as well (for the menus, the screen, the ElToro floppy image etc).

Now the countermeasure is obvious: Keep the sensitive key material in memory areas that is erased during the early boot procedure. Then the attack complexity is raised from "no hardware required" to "specicialists hardware necessary, no guarantees given".

It might seem difficult to find out which memory is of that category. But it isn't, either! Just prepare two boot CDs. One that fills all memory with a known pattern (eg 0x55). Boot it. Then reset and insert the second CD, which identifies all memory areas that have lost the known pattern. These areas have either suffered DRAM fade, or they have been overwritten during the BIOS boot process. Use heuristics to find out which of the two was the cause. Done!

As simple as that.

Regards,
Marc

DRM attack vector

While an issue for whole-disk encryption, this is also an issue for DRM. Just flick the power while the interesting media is being decrypted, and even if the OS had been protecting the key in some "safe" location, you can now find it. It might be little more tricky, but if you can pull the RAM on a video game console, you can do the same thing.

Another attack loop-AES thought about !

This is yet another attack that the developer of loop-AES [sourceforge.net] thought about while typically every other disk encryption tool out there is vulnerable. Loop-AES is the 3rd most popular disk encryption tool in Linux. See the KEYSCRUB=y option in its README file [sourceforge.net]:

If you want to enable AES encryption key scrubbing, specify KEYSCRUB=y on make command line. Loop encryption key scrubbing moves and inverts key bits in kernel RAM so that the thin oxide which forms the storage capacitor dielectric of DRAM cells is not permitted to develop detectable property. For more info, see Peter Gutmann's paper [cypherpunks.to].

I have used loop-AES as a full disk encryption tool on my laptop for 2+ years. I am glad I took the time to carefully research which tool would the most secure before deploying it ! For example even TrueCrypt and dm-crypt are vulnerable to other (arguably minor) security issues that loop-AES is impervious to: http://article.gmane.org/gmane.linux.cryptography/2321 [gmane.org]

Surprisingly, the research paper TFA talks about doesn't even directly mention loop-AES (its name only happens to be in the title of a webpage in the reference section describing a safe suspend/resume setup when using disk encryption).

Re:Fascinating...

If you RTFA you would know that the times can be anywhere from seconds to minutes, but that if you rapidly cool them with an inverted air duster, you can keep the info retained in the chips for 10 minutes or so. I you use some liquid nitrogen, even longer. Requires that you "cut" power to the computer. So I guess that means for a laptop, pulling the battery first, then pulling the plug, spraying the chips with liquid cool, then plopping them into another machine and booting to an evil OS that will read the contents of the memory. I wonder if even TrueCrypt's keyfile function is even thwarted. I mean even if they get your encryption passphrase, wouldn't they still need the keyfile to mount the partition? And how would they know the location of a hidden partition? Also, if someone has physical access to the computer, then there is no security. I mean why not just plop in a keylogger, or set up a hidden webcam to shoulder-surf?

Re:Fascinating...

It depends on many factors, including the technology, the density of the part, and the ambient temperature. Years ago I ran some experiments on 128MB SDRAM (not DDR) and found that even at elevated temperatures (60C) the minimum retention time with zero ECC errors (it was ECC memory) was around six seconds.

I ran those tests because we were using a large chunk of SDRAM (16MB) as a RAM disk to capture log data on an embedded platform. On system failures we had the logs that led to the failure plus a small crash dump to support debugging. The hardware restart cycle was always fast enough to preserve the RAM disk image. I became curious as to how close we were to the edge, so tried a series of experiments, including extracting the blade from the chassis, watching the sweep hand on my watch, and reinserting the blade to let it boot. Even in a temperature chamber (60C is really warm...) the RAM FS was sane after a four second pack pull, allowing about two seconds for the power management to reboot the pack, that gave a six second power off window.

On reboot, the boot monitor checked the reserved area by clearing the ECC status bits, then reading the entire reserved block, which would trigger ECC counters in the memory controller if there were flipped bits. If there were any (even one) ECC counts, it zeroed the block, triggering the kernel to rebuild an empty file system.

So there is my experience on DRAM data retention in power off situations. YMMV.

If someone would like to try this with DDR2 or DDR3 with ECC, it would be interesting to see your results. I have DDR2/ECC blades coming on line now, if I get ahead of my work, I may recreate this test and post back the results. Given my current calendar, it will be a while (months).

PS: Under normal room temp, ~20C, it was very reliable at 16 seconds, and I saw a couple of tests that passed twenty.

Re:Fascinating...

At the time I quit working with commodity DRAM, the common spec was for 128mS data retention at 85C. For various reasons, such as guardbanding, we tested well beyond that. I'd seen further data that suggested that most of the data in the DRAM was still good for several seconds, with no refresh. I seem to remember once hearing something to the effect that retention typically increased an order of magnitude for every 10C drop in temperature. So that 128mS @ 85C becomes 1.28S @ 75C, 12.5S @ 65C, etc. Yeah, I guess I can believe the "minutes" figure if you can chill the chips. By the way, that 85C is junction temperature, which is typically 10C-20C above ambient temperature, when running at full tilt. That offset can be even higher depending on airflow, etc. That also means that if the system is quiescent, the DRAM temperature is likely to be well below 85C, with correspondingly greater data retention.

At any rate, even with low temperatures, with such delays I'd never count on being able to get 100% of the contents successfully.

Re:Physical Access

Don't expect to have time to do anything if the feds bust down your door and want your boxes. Plus, now your machine doesn't even have to be turned off for someone to remove it to a forensic lab: introducing HotPlug [wiebetech.com].

Re:Physical Access

on your personal machine they'd have to physically take it off you

Like when your laptop is stolen while it's in sleep mode. This is rather a common situation.

Re:Physical Access

Think laptops. Laptop users with a half-decent OS don't turn their machines off, they just put them to sleep. When you turn the machine on, you enter your passphrase and it mounts the encrypted disk volume. When you close the lid, the OS locks the machine. You can't get in again without entering your pass phrase. If someone steals the machine, they can't log back in without knowing your password. If they shut the machine down and boot from a different disk then they can't access your data because it's encrypted and turning off the machine wiped the decryption key from RAM.

Except, apparently, it didn't. With the new scenario, the thief takes the cover off the machine and then pulls the battery. They then cool the RAM chips and dump the contents. They can then scan through the dump looking for the decryption key. Once they've found it, they mount the encrypted volume from another OS and get at all of your confidential data.

Re:You can probably read the memory via Cardbus!

True, although it is worth noting that this (and the equivalent FireWire attack) can be mitigated on laptops with newer AMD CPUs (and possibly the latest Intel ones if VT-d is now shipping). Newer AMD chips (or, more specifically, their on-board memory controllers) have a Device Exclusion Vector (DEV) which is a simple bitfield with an entry for each page in physical memory indicating whether a each device is able to DMA to or from that page. A well-behaved OS will set this up so that no device can access any memory unless the driver explicitly permits it. As long as the OS keeps the pages containing encryption keys in the 'never let any device access this' part of memory it will be safe.