So, straight off the hotplug post, now there is a paper discussing the recovery of encryption keys from RAM after a machine has been powered off. [hat tip to a friend and Metzger's list]
Contrary to popular assumption, DRAMs used in most modern computers retain their contents for seconds to minutes after power is lost, even at room temperature 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 successful attacks on popular disk encryption systems 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.
In my previous post, I said “However, if you pulled the plug, then the plaintext key would be lost.” without qualifiers – I generally thought a 10 second rule was appropriate, that is, remove power and 10 seconds later the key would be too difficult for most attackers to recover. Well, it looks like a 60 second rule is a better baseline and perhaps a 515 minute rule is the fairly conservative way to go.
Our first tests measured the decay rate of each memory module under normal operating temperature, which ranged from 25C to 44C depending on the machine (see Figures 1, 2, and 3). We found that the dimensions of the decay curves varied considerably between machines, with the fastest exhibiting complete data loss in approximately 2.5 seconds and the slowest taking an average of 35 seconds. However, the decay curves all display a similar shape, with an initial period of slow decay, followed by an intermediate period of rapid decay, and then a final period of slow decay.
And,
Imaging residual memory contents requires no special equipment. When the system boots, the memory controller begins refreshing the DRAM, reading and rewriting each bit value. At this point, the values are fixed, decay halts, and programs running on the system can read whatever data is present using normal memory-access instructions.
In other words, if someone quickly powers the system back up after the plug is pulled, the decay is stopped. So, turn the system back on within a few seconds, and it is likely quite easy for anybody to quickly reboot the machine from, say, a USB token that has just enough software to dump the memory and then pull the key from that dump. Throw in some error correcting algorithms based on, say, the key schedules used in AES, and key recovery in the presence of some memory degradation improves drastically.
Our experiments (see Section 3) show that it is possible to recover memory contents with few bit errors even after cutting power to the system for a brief time, but the presence of even a small amount of error complicates the process of extracting correct cryptographic keys. In this section we present algorithms for correcting errors in symmetric and private keys. These algorithms can correct most errors quickly and uniquely even in the presence of relatively high bit error probabilities in the range of 5% to 50%, depending on the type of key.
And, yes, they demonstrated all of this on TrueCrypt,
We tested TrueCrypt versions 4.3a and 5.0a running on a Linux system. We mounted a volume encrypted with a 256-bit AES key, then briefly cut power to the system and used our memory imaging tools to record an image of the retained memory data. In both cases, our keyfind program was able to identify the 256-bit AES encryption key, which did not contain any bit errors. For TrueCrypt 5.0a, keyfind was also able to recover the 256-bit AES XTS tweak key without errors.
As well as, on dm-crypt (for those, say, using FDE setup during the installation of Ubuntu Gutsy).
We tested a dm-crypt volume created and mounted using the LUKS (Linux Unified Key Setup) branch of the cryptsetup utility and kernel version 2.6.20. The volume used the default AES-CBC format. We briefly powered down the system and captured a memory image with our PXE kernel. Our keyfind program identified the correct 128-bit AES key, which did not contain any bit errors. After recovering this key, an attacker could decrypt and mount the dm-crypt volume by modifying the cryptsetup program to allow the raw key to be input.
What to do?
Memory imaging attacks are difficult to defend against because cryptographic keys that are in active use need to be stored somewhere. Our suggested countermeasures focus on discarding or obscuring encryption keys before an adversary might gain physical access, preventing memory-dumping software from being executed on the machine, physically protecting DRAM chips, and possibly making the contents of memory decay more readily.
So, shutdown and remove power from that machine when not in use. And, make sure no one accesses that machine for 515 minutes (or more) after removing power. You may even want to create a bootable CD-ROM or USB token that specifically scrubs all system RAM, and boot from that after finishing up using encryption tools.
Good stuff.
Update: Here is the site covering the paper’s release, which includes a FAQ.
Update: Declan McCullagh has a slide show demonstrating the attack conducted against his laptop, as well as, an article on the topic.
Update: Just a quick note, since this post has given me some grief in my circles – you know, if the value of the data you are protecting is such that an attacker would be willing to, say, employ electron microscopes and such in the process of analyzing your DRAM, then you really need to start looking into very specific hardware setups (e.g., hardware cryptographic modules, physical destruction mechanisms, etc.) to meet your needs, because that generic Dell machine running that generic flavor of Windows with whatever cryptographic software on top is very likely not going to cut it for your purposes.
Update: Look at that.
When the idea of memory retaining state for a short time was first brought to my attention a little over a year ago, I ran a few experiments similar to this one, just to prove it to myself. The desktop machines I tried would hold state for anywhere between 5 and 10 seconds without power, whereas my laptop, with no battery or wall power, would maintain state for an amazing 10 minutes.[...]
The Princeton researchers applied this method to the recovery of encryption keys, with great results. They also cooked up a way to image the contents of RAM with a very small footprint, only overwriting a small amount of memory in the process. Unfortunately, at the time of writing this, their tool, ram2usb, hasn’t been released. I decided that it wouldn’t be hard to go ahead and implement one myself, based off their paper and youtube video posted above, so that I (and others) can go ahead and start having fun.
So, as a small side project, I’ve written “msramdmp”, the McGrew Security RAM Dumper. Enjoy!
Update: Yes, yes, if the wire is available, why boot cold when you could just use fire.
Update: The software created by the original researchers has now been released http://citp.princeton.edu/memory/code/.
July 16, 2008 — This page contains source code for some of the software that we developed in the course of this research. These prototype applications are intended to illustrate the techniques described in the paper http://citp.princeton.edu/memory/; we are unable to provide technical support.