Pondering Implications On Standards & Products Due To Cold Boot Attacks On Encryption Keys
You’ve no doubt seen the latest handywork of Ed Felten and his team from the Princeton Center for Information Technology Policy regarding cold boot attacks on encryption keys:
Abstract: 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.
Check out the video below (if you have scripting disabled, here’s the link.) Fascinating and scary stuff.
Would a TPM implementation mitigate this if they keys weren’t stored (even temporarily) in RAM?
Given the surge lately toward full disk encryption products, I wonder how the market will react to this. I am interested in both the broad industry impact and response from vendors. I won’t be surprised if we see new products crop up in a matter of days advertising magical defenses against such attacks as well as vendors scrambling to do damage control.
This might be a bit of a reach, but equally as interesting to me are the potential implications upon DoD/Military crypto standards such as FIPS140.2 ( I believe the draft of 140.3 is circulating…) In the case of certain products at specific security levels, it’s obvious based on the video that one wouldn’t necessarily need physical access to a crypto module (or RAM) in order to potentially attack it.
It’s always amazing to me when really smart people think of really creative, innovative and (in some cases) obvious ways of examining what we all take for granted.
There is a simple mitigation strategy:
1. Turn off the hibernation and/or sleep modes.
2. Tell users to not let the laptop out of their physical control for 10 min after shutting off.
3. Tell users that if a location is unsafe and you must leave it there (i.e. their car, please turn off the machine before leaving)
When I put my laptop into Standby or Hibernate, I can't resume it! I am not sure what the reason is, but tech support says if you disconnect from the network while in sleep mode, it won't resume. Stupid!!!
Stephen:
Let's assume the worst case: Remote salesmen – out on the road.
Options 1, 2 and 3 will all fail.
Making this a user's responsibility to mitigate another spectacular technology failure is not the answer…
This problem has 2 facets:
1) component (memory/cpu) removal: there are certainly plenty of examples of "tamper-proof" and otherwise thermally-sensitive hardware…it seems likely to me that this will get resolved via such products in the future.
2) "in-system" capacitance vs boot time.: Both of these variables can be controlled:
a) Boot-time: It would be ***TRIVIAL*** for every vendor out there ***RIGHT NOW*** to provide a BIOS flash utility that lets you change the boot time, to introduce a sys-admin-assigned delay – say 5 minutes. This could be an PROM-password-protected feature. To account for someone liquid-cooling your system in place (sure, unlikely), they could simply read the CPU temperature and/or motherboard temperature and auto-adjust the delay based upon temperature.
b) Capacitance: The system could simply re-flash the entire contents of memory with all 1's, then all 0's, 10 or 20 times. If that's not good enough, there certainly could be support in BIOS for pseudo-random number generation, overwriting memory. And, when coupled with Boot-PROM intelligence, it could easily be setup to calculate which will take longer – wiping all memory or simply letting the memory capacitance dwindle according to its normal negative exponential equation ;-)…In the case of someone flash-freezing the system, it would be faster to overwrite memory. In the case of room-temperature booting, it would be faster to let it naturally expire.
An additional thought is that there are "registers" within every CPU, and within most programming languages, there is a notion of a "register variable". The problem with register variables is that the "register" prefix before the variable declaration is seen by the compiler as an "I want", not a "You MUST!"…which means these can/will be pulled off the CPU registers and placed in RAM between every context-page of the CPU. If CPU's were changed to move all register variables to the 512K-2MB CPU cache, rather than main RAM, and allow compilers to COMMAND register variables to exist as defined, then this problem would be equally easy to solve.
Last but not least, maybe this will prompt greater adoption of "Personal" Hardware Security Modules, which will offload ALL cryptographic functions…making your system FASTER, too!