Countermeasures to Cold Booting Attacks

There’s been a bit of a back and forth discussion on one of our mailing lists regarding Ed Felten’s recent cold-booting attacks on software FDE (BitLocker, FileVault, dm-crypt etc.). I thought it might be worthwhile to collect some of the potential software-only modifications that would protect against his attacks.

First though, a [paraphrased] summary of the discussion thus far:

Dan F: Why not extend the ISA of the CPU to offload crypto operations to an ASIC or a special part of the CPU? To avoid slowing down the CPU you’d need to widen the issue and decode/dispatch or add another word if it’s VLIW. Op fusion might come to your rescue in a future ISA, too.

Mike P: Good thing MacBooks get nice and hot . Why not add a register for the encryption key that gets wiped with the last bit of power in the CPU?

Me: Can’t we just encrypt all of RAM too? Lots of consumer computers have TPMs with crypto-coprocessors already. Wait a minute, we’d need to shove one on the same bus as the RAM and CPU and where would we store those keys? D’oh! Oh and Dan F, IBM beat you to it.

Dan F: I wonder what affect this has on power consumption and overall throughput?

Computer forensics people have been getting physical memory dumps for years and what about malicious root-owned processes? The threat has always been there. Hasn’t anyone been aware of the threats and developed any countermeasures?

I picked up the Secure Programming Cookbook to look for answers. Here are excerpts from recipes I found that might be applicable to this debate. Since Ed’s code reads through memory and tries to pick out things that looks like keys, maybe you can obfuscate them to look like something else?

DISCLAIMER: I’ve never dumped the contents of memory and inspected it, I’ve never written crypto that handled keys securely, I didn’t test any of these countermeasures, and so on. This is all baseless conjecture.

Recipe 4.13 – Managing Key Material Securely
Securely erase keys are soon as you have finished using them. Use the spc_memzero function from Recipe 13.2 or SecureZeroMemory() if you’re using a new version of Windows.

Recipe 12.4 – Performing Bit and Byte Obfuscation
Use the Obcode library by Pawel Krawcykz. The size of variables are inflated eightfold and the library provides many standard byte and integer operations.

Recipe 12.6 – Merging Scalar Variables
Problem: Scalar variables with constant or initialized values disclose information about ranges of values.
Solution: Merge multiple scalar values into a single, larger scalar value to make simple, unrelated values appear to be a large value or bitfield.

Recipe 12.7 – Splitting Variables
Problem: Large scalar variables that cannot be merged, or that have large values that cannot easily be manipulated with a constant transform, need to be obfuscated.
Solution: You’ll have to buy the book, I can’t explain it .

Recipe 12.10 – Restructuring Arrays

• Split a one-dimensional array into multiple one-dimensional arrays
• Fold a one-dimensional array into a multi-dimensional array
• Flatten a multi-dimensional array into a single one-dimensional array
• Merge two one-dimensional arrays into a single one-dimensional array

Recipe 12.11 – Hiding Strings
See the book

I also read through all of the comments on Freedom to Tinker to look for potential solutions and bring them to light. Here are some of the more interesting comments I found:

Will Michaels said, “Full Disk Encrypting (FDE) hard drives perform the encryption in hardware directly on the hard drive, using a key that never leaves the drive. Such FDE drives are protected against this attack on off-drive encryption.”

Laszlo Hars said, “…However, it has been recommended for ages that encryption keys are never stored in RAM. They have to stay in a locked part of the processor cache. It was not because of the chilled-RAM effects, but because of virtual memory (swap file), or hibernation. The OS might write any info from RAM to disk, where an attacker can find it later. It is surprising that BitLocker does not follow this practice. TrueCrypt is known to be weak both in the choice of algorithms and their implementation (an example is their recent choice to implement the IEEE P1619 encryption standard meant for completely different type of applications)….”

Brad Templeton said, “Sorry, Ed, I’ve been hearing about this technique since the 90s. It’s not new. Rumor is that spooks have been using it for some time. Here’s an old message board thread a quick Google search found.

Laszlo Hars said, “The real issue revealed by the paper is not weaknesses in disk encryption software, but a cheap way to go around DRM, and code privacy. You run the protected code, like a DVD player or a game in one PC, freeze and move the RAM to another machine (can be the same one rebooted to DOS), where you can analyze the memory at your leisure. You can disassemble protected code, find media keys, etc. It is simpler and cheaper than using high speed, logic analyzers on memory lines.”

Justin Wells said, “…Even were the disk encryption key problem resolved somehow the attacker could still use this technique to recover data the user had thought was secure. Recovering the key simply allows the attacker to recover ALL the data, rather than only the data in RAM….”

and, “The “key stored in CPU” used to encrypt RAM, or used to encrypt the disk key stored in RAM, need be nothing more than some randomized values in a few registers that are then preserved. All access to the encrypted data would then make use of the randomized values. The randomized memory encryption key stored in the CPU can be recreated on every boot of the system–there is no need to preserve it over time. Its purpose is simply to make memory unreadable.”

Christopher said, “You’re right, some common platforms use a hardware assist to look in the page tables. IA-64 can turn off hardware assistance, so that a TLB miss raises an exception rather than turning to the page table-handling hardware, but the vanilla IA-32 needs its page tables loaded in memory, and as you point out, the TLB isn’t designed for recovering values stored in it.

Of course, if we’re talking about IA-64 or x86_64, we’ve got a lot of registers available to us, we might be able to hold four of them aside with a modified compiler, but that also assumes you can ensure these registers won’t get pushed to the stack on an interrupt request, or cleared by a context change.

OK, registers, TLB, cache. Is there anywhere else a person can find 256 bits of volatile storage on the die of a modern CPU? Hardware performance counters? You can read those, but I don’t know if you can write them, or turn off their updating.

Anonymous pointed out, “I saw something similar to this presented at Black Hat DC last year. Except they were semantically rebuilding the memory image to extract the TrueCrypt keys. link“

Todd said, “…Also no one has mentioned graphics card memory! OUCH! While there may not be tons of useful data there, it is conceivable that a illegitimate user could cull the image(s) of recent used documents….”

Andreas said, “Some processor architectures, like the SPARC architecture for example, provide general registers that are not saved onto the stack (e.g. %g1 to %g7 in case of SPARC) and support multiple register sets, including one exclusively for the operating system. On these architectures it would be feasible to keep the key permantly in registers which would never be copied into memory.”

Richard L. Enison claimed to have a patent on storing encryption keys in hardware. sigh.

You’re welcome for reading that entire thread for you, and yes, this is how I spend my weekends.

EDIT: I saw that Nate Lawson of Root Labs entered the discussion today with a post on his blog. He seems to agree with Dan F that adding crypto the processor is the best long term solution but he also suggests things FDE developers can do in the meantime.