How can the impact of cold boot attacks be minimized?

Question

Short of powering down and maintaining physical security for sufficient time, what are effective strategies for keeping keys from being disclosed by cold-boot attacks, and can anything be done without hardware designed to prevent such attacks?

http://citp.princeton.edu/memory/

Answer 1

One approach is to use highly non-redundant key schedules. For instances, if you can recover any large piece of AES's expanded key schedule in memory you can run the expansion in reverse and recover the original input (which then allows you to generate all of the round keys, even if you were only able to recover the values from a single round, or even portions of different rounds). To some extent, this is intrinsic to AES's design, so it's hard to avoid, but for contrast consider Blowfish's sbox expansion design - it seems quite difficult to recover the master key or the entire sbox if you manage to recover, say, half of the sbox values.

Another approach, one that works with AES, is to simply ensure the key never hits RAM by keeping the entire state in SSE registers or debug registers. This approach is only usable by an OS kernel, but often the kernel is going to be doing the crypto that is most prone to a cold boot attacks, like disk encryption, so this could be a promising approach.

Answer 2

I just found this article, http://www.blackhat.com/presentations/bh-usa-08/McGregor/BH_US_08_McGregor_Cold_Boot_Attacks.pdf while looking for something else, and it outlines several software-only solutions that seem viable (a couple of which have been touched on here already), although not foolproof.

• store keys in memory regions that must be overwritten no matter what operating system is booted. (forces the attacker to use specialized hardware, not just a special OS)
• store keys in MMX/SSE registers
• spread keys across the address space to minimize the benefit of error correction to the attacker.
• overwrite keys before reboot/shutdown
• monitor chassis intrusion and temperature sensors for precursors to an attack (case opening or sudden drop in memory temperature) and begin overwriting keys on the spot if either event is detected. (Assumes that an attacker sophisticated enough to take the RAM out of the system for forensic analysis will also try to cool it in advance of system shutdown to maximize the effectiveness.)

Answer 3

Well if your system is successfully attacked by cold boot, it's not that your crypto system failed, but physical layer of IT security.

After cutting the power, data in RAM will fade away. If you lose one bit in decription key, key is not valid (well, with only one bit lost you can guess it, but I guess you got the point). All in all, shutting down and powering computer will corrupt any lefovers of key.

So, to preform cold-boot you need to freeze RAM modul. To do so, you need "freezer" and access to modules. Well, if intruder walks into room when someone is shutting down computer (and he, by some miracle, is not noticed), opens case and starts spraying freezer on RAM modules (while computer is still shutting down)...

Well, let's just say you have much bigger problems then failed crypto system.

EDIT: Suma summare, in real world this is pointless to discuss (due to ROI). The best strategy would be actualy from social angle - user must be next to computer until it shutdowns completely.

Answer 4

I think Jack Lloyd's advice is worth taking a look at.

Another frequently used trick is to XOR the keys on memory by themselves periodically... With short periods, of course. An example of this is PGP. It used to flip bits in the memory once a second, since quite early versions. This shortens the life-span of key ghost images.

Of course, there's an extra bit used to store the current state of the keys, and the whole XOR process has to go within a single atomic transaction, with a locking mechanism as with the key read operations.

Answer 5

I can't think of many situations in which the memory but not the hard disk contains sensitive information and is accessible in the minutes after shutdown, but not while the computer is on... but if you, say, have government secrets on a laptop with the encryption key stored only in your memory and the computer's memory, and you leave that laptop on a train after turning it off, you could use secure-delete / smem to erase data in memory (the computer's memory, not yours) before shutting down. I would advise making this process automatic! (And also advise to erase the swap file, which will hang around a lot longer than data in RAM).

Answer 6

not sure if this is the "best answer" or if this is practical in your situation, but for the extremely paranoid, you can use both hardware-based disk encryption (wherein the cryptographic material never leaves drive enclosure) + s/w-based. The former mitigates cold boot (or any other memory-based attack, such as via firewire port) while the latter gets around the annoying issue w/ h/w-based FDE wherein a warm reboot does not (ever?) require re-authentication.

So, for eg, a Seagate Momentus FDE drive + BitLocker w/ TPM.

This is probably a bit extreme for most people, since most laptop thieves don't do the cold boot attack on their stolen (but screen locked) laptops--lest they damage the hardware & reduce the re-sale value of their warez.

alternately, you could implement s/w-based FDE (BitLocker+TPM+PIN, for eg) along w/ a secondary layer of encryption (EFS, or a non-system TrueCrypt volume, or whatever). While a screen-locked laptop might contain all cryptographic information in memory (if encrypted volume was mounted at the time of theft and robber did cold boot attack in time), it strikes me as unlikely that the laptop thief would have sufficient knowledge + resources to carry out the attack on both security "layers," or probably even the first layer.

The people who know how to do the cold boot attack are probably working somewhere & have too much to lose to enter a life of crime, so avoid constructing an "ideal" security model for data-at-rest while ignoring other threats (exploits when machine is in use, such as buffer overflow exploits).