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."

Re:Fascinating...

[planckscale]

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:only useful if you start off unencrypted

[haystor]

Stolen laptops would be the chief target I'd imagine. They are easiest to get physical access to and most likely to be considered "secure" through encryption software.

Re:Physical Access

[nachoboy]

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

[TheRaven64]

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:Secure DRAM

[postbigbang]

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:Fascinating...

[Anonymous Coward]

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:Clear the DRAM?

[compro01]

death code [catb.org]

Re:Fascinating...

[dpilot]

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:Clear the DRAM?

[sempernoctis]

If you had access to the system, running and encrypted bits unlocked, why on earth would you turn it off?

Because the OS has control of the system at that point. If the terminal is locked, even though the system is on, you won't be able to access anything until you get control of the hardware away from the OS. Also, when you start poking around on a system, you always have the potential of accidentally destroying evidence, and evidence is much weaker in court if there isn't an untampered version of the disk to allow the prosecution's claims to be verified.

Re:Clear the DRAM?

[SharpFang]

Still, power down without shutdown, then boot up operating system without such feature and you're gone.
The only way I see it to be sure, DRAM upon losing power uses on-board capacitor to erase its own contents, the feature built into the RAM die. Even BIOS is not sufficient if you just pull the plug and move the RAM to a different PC.

Re:Hardly the problem

[russ1337]

Next, you need to have a floppy, cdrom, or USB stick with your specially crafted OS on it and somehow get the system to reboot into that special OS (mind you at this point you probably don't know for sure if the laptop is using full disk encryption, or even what brand)

So simply setting the hard drive as the only boot device in BIOS, and password protecting BIOS could slow down the attacker enough. (they'd have to disasemble the laptop, reset the bios, reboot).

As someone pointed out to me a few days ago: Firewire (usually?) has DMA access, so it would be possible to interface the laptop via firewire and do a full memory dump. Then go to work on that to get the key. - requires physical access to the powered laptop of course. Of course, if you have no firewire devices you could have a script do a 'shutdown -H now' on detection of a firewire device.

Re:Very real concern

[Cruicky]

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.

Re:You can probably read the memory via Cardbus!

[TheRaven64]

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.

Re:Clear the DRAM?

[RAMMS+EIN]

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:Use capacitors

[AchiIIe]

I agree that the capacitor is the way to go. As a reminder, all harddrives are fitted with an emergency capacitor. If the hard drive looses power while the head is traveling there's a risk for a head crash. Thus, once power is lost, the capacitor will fire up the motor for one last push toward the parking space. if you have an external hard drive listen for the click that happens right after you pull the power.

I do not thin' it means what you thin' it means.

[The Monster]

it's a common tenant in systems security that anyone with physical access and sufficient time can disable or otherwise bypass any security system.

Does it pay rent?

I think the word you're looking for is "tenet [merriam-webster.com]".

Re:Another attack loop-AES thought about !

[DamnStupidElf]

Presumably, moving bits around in memory doesn't help in this case because the exact memory image is retained. Additionally, the code that moves the bits around is also present, making it straightforward to locate the bits and reassemble the key.

Re:Clear the DRAM?

[Detritus]

Some crypto hardware is designed with anti-tamper switches that will erase all keying data if the case is opened. There is often a front-panel switch (zeroize switch) to do the same thing upon operator command.

Re:Clear the DRAM?

[KublaiKhan]

-You- may practice proper procedure, but some contractor/low level drone/mindless bureaucrat might leave his system on screensaver (or just lock the console) when turning his back for a moment, which would allow for someone to snatch the laptop and run.

And while your program may indeed wipe the drive after 10 incorrect guesses, there's one very significant weakness to that proposition: the program must be -running- in order to do so.

So, in this case, the method of attack would be as follows: find someone with a laptop full of information who has it activated in an accessible location. Grab said laptop and remove it to a location where the RAM can be accessed per this hack. Then, after grabbing the key, remove the hard drive, hook it to a system you have control over, and either use the key to open the drive or, if the key is corrupted or incomplete, use the key as input to crack the drive conventionally--bearing in mind that if it is mounted in such a way that your fancy program does not activate, the program cannot erase the drive.

Re:Fascinating...

[cryptoguy]

> 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?

Truecrypt's keyfile is only a precursor to the actual decryption key. It is not accessed after the drive is mounted. Once the drive is mounted, everything that is needed to read the disk is in memory. (namely, the decryption key).

So, whatever drive or partition you have mounted (whether hidden or otherwise) is accessible to anyone who can read your computer's memory.

Re:Use capacitors

[tweak13]

I heard that mechanism in hard drives explained to me as using the spindle motor as a generator to get the heads parked. Makes sense, there's a lot of inertia in the spinning platters that you may as well use.

Re:Use capacitors

[greyhueofdoubt]

erm... I have taken many hard drives apart, and I've never seen a cap in them (modern ones, at least) that would have enough power to turn the platters or energize the voice coil of the read head armature. It's been a while since I've seen anything other than surface-mount components.

Usually what I find is a rare-earth magnet at one end of the voice coil's travel that locks the read heads away from the platter in the absence of voltage in the coil; this is aided as well by the torque exerted on the armature by the trace ribbons that feed voltage to the coil and read heads. Note that this magnet is separate and distinct from the two that control the lateral motion of the read/write armature.

The 'clink' that you hear is the armature knocking up against the magnet. If you take the cover off, you can recreate the sound yourself, even without power.

protip: HDD voice coils make great crude galvanometers.

-b

Re:Another attack loop-AES thought about !

[Mike1024]

This is yet another attack that the developer of loop-AES thought about while typically every other disk encryption tool out there is vulnerable. [...] "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."

I'm afraid it doesn't. Here is the code from Gutmann's paper:

Flipping:

while( TRUE )
{
acquire keyMutex;
key ^= 1111...1111;
keyState ^= 1;
release keyMutex;

sleep( 60 );
}

Using:

acquire keyMutex;
if( keyState == 1 )
key ^= 1111...1111;
encrypt/decrypt;
if( keyState == 1 )
key ^= 1111...1111;
release keyMutex;

The code above protects against detectable 'wear' that occurs if RAM holds the same value for a long time. With inversion, the RAM holds normal and inverted values for equal time, and therefore doesn't wear in one direction or the other.

The attack described in the article relies on removing the RAM from a targeted machine (or rebooting the target machine) and capturing the contents of RAM before it has a chance to clear (which takes a few minutes, they report). In the example of the code above, they would capture both 'key' and 'keyState' and would therefore know the key, and if the key was inverted or not (of course, even if they did not know whether the key was inverted, it would be trivial to try it both inverted and uninverted).

I suppose in a system with a write-back cache, it might be possible to keep the key permanently in the CPU's cache, where this attack would be substantially less practical. However, caches are not supposed to be used like that, so it may be difficult to implement.