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.
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
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
If somebody has the kind of access to cut power to your system and then immediately reboot with a malicious thumb drive, they probably have enough access to install something like an inconspicuous hardware keylogger, which I would be much MUCH more worried about than this if you're doing something sensitive enough to warrant it.
And aside from that, couldn't you just encrypt the important parts of your memory and swap as well as your hard drive? Seems like that would defeat this quite handily, and again, if I were doing something so sensitive I'd probably be taking such precautions.
Honestly though, aside from people doing stuff like maybe international or corporate espionage, I can't imagine where any of this would be a problem.
Easy fix: install a BIOS/boot ROM with a non-bypassable memory test of all memory. This will clear all memory at power-up before reading the boot device.
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".
Memory is reliably addressed -- writing to the address you wrote to earlier will change the same physical part of the ram. There are already existing tools that erase passphrases after a certain period without use. All you need to do is make those tools also scrub the addresses used to store it. A simple patch would cover that.
What's more of a problem is: how to make this timeout+prompt for passphrase thing work with disk-level encyption regardless of whether you're a console or in a GUI, on an otherwise decent OS like unix? I wouldn't trust Windows to implement disk-level encyption safely anyway, so all bets are off there. But unix still has serious issues regarding the simple presentation of a dialog box to the user no matter what part of the system they're looking at, in a reliable and secure way.
I believe that the C3 processor made by VIA and probably other processors in that family allow some of the cache to be configured as SRAM and mapped into physical memory. So, you could store the key in SRAM, which I believe really will lose its data upon power loss, although you may also want to take countermeasures such as those used in loop-AES to avoid detection by physical changes to the chip if key is store for a long time in the same place.
Newever VIA processors also have some hardware AES support available under Linux, which they call "Padlock. So, if they still retain the SRAM feature, then, at that would make a pretty good choice for the little fanless mini-ITX Linux box that receives your email.