Cold Reboot Attacks on Disk Encryption [LWN.net]

Cold Reboot Attacks on Disk Encryption

Posted Feb 29, 2008 22:19 UTC (Fri) by giraffedata (subscriber, #1954)
In reply to: Cold Reboot Attacks on Disk Encryption by drag
Parent article: Cold Reboot Attacks on Disk Encryption

The only solution to this sort of attack is to have the keys always in encrypted form in-memory.`Then when the system needs to have the key it can be decrypted and accessed quickly in CPU cache.

Where do you keep the key for the key?

And how does a program put something in the CPU cache without it also being in memory?

(Log in to post comments)

Cold Reboot Attacks on Disk Encryption

Posted Mar 2, 2008 5:27 UTC (Sun) by kevinbsmith (guest, #4778) [Link]

"Where do you keep the key for the key?"

Keep in mind that "Security" is a spectrum, not a boolean. 

I have heard that it is pretty quick (and effective) to simply test every x-bit value that
exists in RAM, and see if it happens to be the key you are seeking. A billion tries don't take
too long. 

But if the in-RAM key were an encrypted version, and the key for the key were stored at some
other random location in RAM, then you just turned the search from n to n^2. Not a bad trick
if n is measured in gigas.

Another option would be to split the real key up into several pieces, and store them in
disparate locations. I haven't thought that one through enough to decide if it would be better
or worse than the key-for-a-key option. Nor how many pieces would be optimal. Seems promising
based on a few seconds of thought.

Is either of these approaches Perfect? Absolutely not. Are they enough of an improvement to be
worth doing? I would guess so, but would be interested to hear other opinions. If it turned
out to be effective against one specific, popular, real-world attack, and the cost is low,
sure.

Looking a bit deeper, an attacker could look at memory patterns (and/or source code) to reduce
the search space. But at least that would require the attacker to create a custom attack
rather than using an off-the-shelf cracking script. Again, it's about raising the bar, when
the costs of doing so are lower than the benefits.

Cold Reboot Attacks on Disk Encryption

Posted Mar 3, 2008 6:40 UTC (Mon) by njs (subscriber, #40338) [Link]

Searching all of memory for a given bitstring is indeed very quick -- a few seconds.  But,
err, if you already know what the bitstring for the key is, why are you searching for it?

What you'd really be searching for would be the data structure that's holding the key -- the
OS has some way to figure out which random-looking bitstring in those gigabytes of memory is
really the key, so you can too, by finding the right data structures and chasing the right
pointers.  AFAICT that means that the techniques you're suggesting won't work -- if the key is
split into multiple pieces, then don't look for the pieces, look for the data structure that
lists off where all of the pieces are so they can be found again by the OS.

Cold Reboot Attacks on Disk Encryption

Posted Mar 8, 2008 13:55 UTC (Sat) by kevinbsmith (guest, #4778) [Link]

You missed the point. If you know that a key exists somewhere in RAM, it is fast and simple to
read a key's worth of data starting at every byte in the system, and attempt a decode of every
one until you find one that works. Brute force with one giga of attempts. No knowledge of OS,
language, data structures, or app code is required, aside from knowing the encryption
algorithm and key size (which is usually easy to find). Dead simple. And quite effective.

Splitting the key, or having an encrypted key with its key elsewhere in RAM would foil that
attack. At that point, the cracker would have to know something about the specific app and
craft a custom attack, which makes the attack quite a lot more difficult/expensive.

It's like locking your car so the stereo thief breaks into the unlocked car instead. It won't
block a highly motivated/funded attacker, but will keep out some script kiddies. If the cost
of splitting the key is near zero, it might be a good benefit/cost tradeoff.