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."
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.
Crackin' Wise - Blogging about whatever we want
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 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.
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
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.
Method of processing duck feet
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.
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.
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-AES is the 3rd most popular disk encryption tool in Linux. See the KEYSCRUB=y option in its README file:
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
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).
I'm surprised no one has mentioned the Cell processor yet. I guess everyone hates it.
The first power word that a toddler learns is "mine!" It's the capstone to a complete working vocabulary: mommy, daddy, more, enough, and mine. My laptop, my hardware, my data, my privacy. The word "mine" has a direct bypass to the neurological circuit "you can't make me", which as adults lingers as a deeply-rooted fascination with rubber-hose cryptography, and bravado propositions such as "if the Feds bust through your windows". Wrong answer.
Let's look at this from Sony's perspective: my media, my hardware, my design, my copyright, my profits. But guess what? They have a small physical access problem. Millions of zit faced kids with access to liquid nitrogen can get their paws inside the PS3.
This is why an entire SPU is locked down on the PS3 for security / DRM purposes. The SPU contains 256K of SRAM which is carefully guarded. The instruction set is synchronous and deterministic to guard against timing attacks. They were aware of power attacks as well. These can be partially mitigated in software for critical routines by executing non-conditional instruction sequences and then discarding the portions of the computation you didn't want. By design, the SPU doesn't dance on the power line the way most modern speculative out-of-order processors do to begin with. You can't use latency effects, because the local SRAM has constant access time. You can't use contention effects because there aren't any below the level of DMA bursts, which are controlled by a companion processor within the SPU. Plus I think it is possible to schedule SPU-SPU and SPU-memory DMA transfers deterministically, if you really need to. None of this was accidental.
The hardest part of the problem is bootstrapping the secure SPU with the security kernel. I've forgotten how they went about it. There must be some kind of decrypt key buried in the Cell hardware which functions during initial code upload during processor initialization.
In the long run it might be an unwinnable battle, but the PS3 certainly has a far better facility to maintain data security in the complete absence of hardware security than your average PC.
Why can't the average hacker Harry wants to enjoy the same security as Sony/IBM, why can't you achieve this? You've already got the PS3 in your living room. Impediment: the secure system init decrypt key is probably burned into the silicon. It's probably a one-way key, so even if you crack the key, you won't be able to encrypt a replacement block of your own code that matches the decrypt key. But let's suppose you break that too. Problem: Sony knows the decrypt key for the SPU initialization sequence. Game over.
Let's suppose you figure out how to physically change the silicon with an initialization decrypt code known only to yourself. Congratulations, you now enjoy the same protection for your secrets that Sony enjoys for "Untraceable". In doing so, you have now upgraded yourself to a sufficiently threatening fish to swim in a tank in Syria, where your nervous system will be similarly reconfigured.
Ew, I feel like I've just written the script for "Adaptation".