Even in my drug-addled state last week it was hard to miss the cold boot encryption attack released by Ed Felten and the Princeton Center for Information Technology Policy. This is some seriously impressive work with major implications, but despite all the articles I’ve seen there has been little information on how to evaluate and mitigate your personal or organizational risk.
That’s where I come in.
I’m not going to assume you know a lot about file and media encryption, so we’ll start with en explanation of how, and why, the attack works. Then we’ll evaluate the risk and discuss mitigation strategies. I’ll close with some suggestions for vendors to close out this vulnerability. And yes, this works on a Mac with FileVault.
What is the cold boot attack and how does it work?
All encryption systems need access to a key to encrypt and decrypt data. It doesn’t matter what you’re encrypting- a hard drive, file, database, or whatever, you need a key. When encrypting and decrypting data, because of how computer systems are designed, the key always passes through memory at some point. For smaller content this is a transient process and the key is only in memory for a short time (assuming the software is designed properly), but when you need constant access to data the key is kept in memory. This is nearly ubiquitous for full-disk encryption or file encryption systems that leave files open for read/write operations. It’s not something we worried about, because when you turn a computer off the RAM (memory for the non geeks) loses power and anything stored is lost. Thus we would password protect our encrypted systems so that even if they wake up from sleep mode, an attacker would have to reboot the system unless they had the key, confident this process would erase the key from memory and keep the data secure.
What the Princeton researchers demonstrated is that modern RAM doesn’t degrade immediately after power is removed. The contents of memory can persist from seconds to minutes, and that time extends when cold is applied to the memory. An easy way to do this is to just use a can of dust off spray.
That’s the first part of the attack- keeping the contents in memory after the system is shut down.
For the second part of the attack they use a special tool, which they haven’t made public, to recover memory contents from RAM. In the demo this tool is on a bootable USB drive, so merely rebooting the computer from this USB stick, ignoring the host operating system of the computer, allows them to scan memory and recover the encryption key. Additional work allowed them to recover a full key even if a few bits were lost as the memory degraded.
To execute the attack, the attacker opens the computer, sprays the memory with an upside-down can of dust off to cool it, then reboots off the USB device with their software for key recovery on it, thus recovering the keys and gaining access to the data.
If you use a boot password or something similar they perform the same attack, but remove the memory and place it into a different system for key recovery. Thanks to the cold spray you have more than enough time to pull this off.
Evaluating the Risk
There are no public tools for this attack but it’s only a matter of time. Your immediate risk is low, but don’t be surprised if tools appear reasonably soon. This is a serious vulnerability, with a probability of attack that only increases over time.
In other words, don’t panic, but keep your eyes open. Once a public tool appears it’s time to be more concerned.
The researchers outline how most current protection techniques only partially, if at all, mitigate this flaw. Since memory can be removed, BIOS locks and other restrictions are ineffective.
You are only at risk when your computer is powered on or in sleep mode and you lose physical control of it. Powering off your system begins the memory degradation process and you are safe within a few minutes.
Reducing Your Risk
The most effective method is to power off your system completely (not sleep or hibernate mode) when it’s at risk of physical loss. This is inconvenient, but I’m going to start powering off when I’m in higher risk areas (like airport security) and can’t maintain physical control of the system.
Which brings recommendation number 2- don’t let someone steal your computer. I personally maintain physical control over my system nearly all the time when it’s out of my home (and I have a pretty good security system there). At hotels is the greatest risk, and I do tend to power off when I’m out of the room. You sales guys should start getting into the habit of not using sleep mode when you leave your computer locked in a rental car. At least until the encryption and laptop vendors come up with alternative protections.
For those of you with very sensitive information, combine file and folder encryption for sensitive files with your whole disk encryption. A few vendors offer this (feel free to brag in the comments guys). Just close those sensitive files or images before entering sleep mode, and make sure they are password protected and not linked to your normal login credentials.
Also consider an encryption system that supports storing the keys on a smart card (not in memory). I don’t believe there are many practical options today, but expect to see them crop up thanks to this paper.
Finally, ask your vendor their plans to manage this risk. Today it’s not a big deal, but we don’t know if it will be 2 weeks, 2 months, or two years before public tools appear (and it’s safe to assume some governments have this by now – or more accurately, it would be unsafe and foolish to assume any government does note have this capability by now).
Thus, your overall risk is currently low but growing. You can reduce that risk through good habits and some additional software.
What Vendors Can Do
I don’t know to what degree this technique works on commercial encryption products, but vendors should evaluate the risk to their products and keep customers updated. Saying it isn’t a problem or the risk is low isn’t the right answer- you’ll lose customers that way. If you are working on a solution, let them know since the risk really is low for now.
I suspect we’ll see a couple of different approaches. Over time, this is something that will migrate into hardware- even just a small bit of RAM soldered to the board, probably integrated with some future, mythical, TPM. On the software side I have to believe there are ways we can reduce the risk- for example, flushing the active key from memory during sleep (while turning off hibernate, which writes memory to disk and is always bad anyway) and transitioning to a password protected temp key to access the primary key.
Hardware tokens/smart cards are another great option, assuming we can control active access to the key and you remember to unplug it. There are a lot of really smart engineers out there who will probably come up with fixes, at least for third party encryption tools, before this attack becomes widespread.
This is an impressive and serious attack we all need to take extremely seriously. You are at risk if you lose physical control of an encrypted system that is either powered on or in sleep or hibernate mode.
Turning off your system when it’s at greatest risk of loss or theft is a very effective mitigation, but it will be difficult to train average users to stop using sleep mode due to the convenience.
Using file encryption for sensitive content in combination with whole disk may also reduce the risk when done properly.
Talk to your vendor, and make sure they are REALLY not susceptible or have a roadmap to eliminate this method of attack. If they offer the protection, understand and implement the necessary configuration profile, which may not be the default.
Vendors: talk to your customers and get working on the problem if you are vulnerable. Recognize that hardware solutions are always longer term and you should really see if there is a way to offer protection within the software.
Me? I’m not too worried, but I have extremely good habits around the physical control of my laptop, and will now shut down more under certain circumstances. Since I have a fast Mac, rebooting isn’t all that bad anyway…