Slashdot Mirror
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."
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.
I am TheRaven on Soylent News
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.
death code
upon the advice of my lawyer, i have no sig at this time
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.
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.
Please correct me if I got my facts wrong.
-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.
In Xanadu did Kubla Khan
A stately pleasure dome decree