LWN: Comments on "Cold Reboot Attacks on Disk Encryption"

Cold Reboot Attacks on Disk Encryption

kevinbsmith — Sat, 08 Mar 2008 13:55:44 +0000

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.

Cold Reboot Attacks on Disk Encryption

njs — Mon, 03 Mar 2008 06:40:12 +0000

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

kevinbsmith — Sun, 02 Mar 2008 05:27:55 +0000

"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

giraffedata — Fri, 29 Feb 2008 22:19:34 +0000

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?

Cold Reboot Attacks on Disk Encryption

jimparis — Thu, 28 Feb 2008 07:25:28 +0000

The 99.9% solution that I'm happy with is: never leave my computer unattended while the hard
drive encryption keys are present in RAM.  That means I never lock the screen and walk away,
and I never suspend to ram and walk away.  I just suspend to disk and power off completely.

The only new thing this research pointed out to me is just how long it takes for unpowered
room-temperature RAM to lose its contents -- I suspected it was within a second but it's a bit
longer than that.  Anyway, this small window can be fixed by modifying the suspend-to-disk
process to also clear the RAM right before poweroff (I'm still in control of the laptop at
this point, so nobody can interrupt it).

The TCPA does not address this scenario at all

hmh — Tue, 26 Feb 2008 17:28:43 +0000

While the TPCA doesn't give away its storage encryption key easily, you still need to have the
unwrapped (aka unprotected) session key for your encrypted disk somewhere in main memory to
work with it.

The complete fix for this problem really goes through extra hardware.  Designing
extra-volatile memory is easy, but you need to get that memory inside a more protected
location (like inside the MCH, CPU, or data storage unit itself).  And an attacker with enough
resources would still be able to get to it.

What we can do easily, is to reduce the windows of opportunity where the keys are available
unprotected in RAM, which is good enough for a lot of scenarios.

Frankly, if it can be made safe enough that regular laptop and data thieves can't get to the
data, I would be personally happy enough.

Cold Reboot Attacks on Disk Encryption

njs — Tue, 26 Feb 2008 05:52:13 +0000

Naw, don't shut down.  Presumably the real solution is to every n minutes throw away crypto
keys and at the next attempt to access the encrypted data, require the passphrase be
re-entered.  (We assume that attackers can't or won't breach the case to suck things out in
less than n minutes.)  Then if you want to get fancy, you can also add accelerometers to the
list of things that trigger the crypto keys being flushed.

Nagging the user on a timer is somewhat annoying, of course, but should be practical if one
really has secret data (and if you segregate out the actually secret stuff from the everyday
stuff).  It might even be a feature to bug the user occasionally while they have secret data
open, to remind them of this fact -- sort of a modern equivalent to root's "#" prompt.

Cold Reboot Attacks on Disk Encryption

forthy — Mon, 25 Feb 2008 13:11:55 +0000

"Intrusion detection" is the key here. Add an acceleration sensor to your case, and make sure to set the thresholds so that any small case movement causes the system to erase its memory and shut down. Optimally screw the case to the wall so that you have to open it to move it, anyway, and no accidental kick with your foot will trigger the sensor. And remember to put trip wires around your door - as typical geek, you are supposed to be lonely (you know all your friends only by their IRC nicks, and all women you know have the jpeg surname ;-), so the likelyhood that someone else trips over your trip wires is extremely small ;-).

Cold Reboot Attacks on Disk Encryption

drag — Mon, 25 Feb 2008 07:04:27 +0000

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.

The sort of memory used in CPU cache is different then the sort that is used in main system
memory. So hopefull that cpu cache, besides being much faster, does not have the same
properties of regular Dram.

Or maybe have a built-in hardware tripwire that would 'zap' the ram in case of sudden power
loss. Nothing that would destroy the ram, but enough to flip all the bits back to zero or
something like that.

I expect that the only total solution would be change the design of the hardware like that.
Hopefully something that could be built-into the ram so that you would not have to modify the
design of the motherboard.

Isn't this exactly why the TCPA chip was invented ?

ballombe — Sun, 24 Feb 2008 16:56:24 +0000

> From the story the TCPA will not give away it's keys.

Really ? I rather read it as saying that TCPA does not protect
against this attack.

Cold Reboot Attacks on Disk Encryption

macc — Sat, 23 Feb 2008 22:42:11 +0000

GPS? tilt sensor or one of these little gyro thingies used
for model helicopters? Then moving the box would shut the OS down?

G!
MACC

Isn't this exactly why the TCPA chip was invented ?

ernest — Sat, 23 Feb 2008 09:21:47 +0000



From the story the TCPA will not give away it's keys. I hate to say this, 
but I have less objections to that chip on my motherboard now.

Ernest.

Cold Reboot Attacks on Disk Encryption

jcm — Sat, 23 Feb 2008 00:52:29 +0000

The crux of the matter is that people are lazy. They don't want to reenter their password on 
resume, or after leaving the machine unattended, so passwords are retained in memory 
unnecessarily. As a partial aide, perhaps we should store passwords physically in the first
few 
pages of RAM after any machine vectors - that would make it more likely you would have to 
remove the chips to read the important bits.

Jon.

Cold Reboot Attacks on Disk Encryption

freehat — Fri, 22 Feb 2008 17:35:24 +0000

This is an OLD article - but this should give you some more reasons to feel insecure ;)

http://www.cs.auckland.ac.nz/~pgut001/pubs/secure_del.html

Cold Reboot Attacks on Disk Encryption

JoeBuck — Fri, 22 Feb 2008 16:04:09 +0000

The "min or two" could be eliminated by having the shutdown or hibernate sequence wipe the key.

Cold Reboot Attacks on Disk Encryption

xorbe — Fri, 22 Feb 2008 08:16:13 +0000

epoxy them in!  ;-)

Cold Reboot Attacks on Disk Encryption

knobunc — Fri, 22 Feb 2008 04:20:01 +0000

http://www.schneier.com/blog/archives/2008/02/hotplug_1.html has some of the relevant tech
they use for this.  I looked at the site and they have a few suggested methods for hooking in
to the target computer's power:

The Easy: If it is plugged into a power strip, you plug their UPS into the same strip then
pull the plug to mains power.  Take the computer, power strip and UPS off to your lab.  (Same
works if the outlet has 2 sockets, just unplug from the one that the computer is not using and
plug the ups into that then take the outlet with you)

The Harder: If there is no power strip, remove the outlet from the wall (while the computer is
still plugged in).  Attach some special jumper cables to the screws on the back and cut
(physically) the mains power.

The Hardest: Strip the power cord to the computer and attach the UPS wires directly to the
wires inside the cord.

-ben

Plug too hard? Jack the cable.

midg3t — Fri, 22 Feb 2008 03:02:44 +0000

Just remove the plastic sheath from the cable and poke your power source into the live & neutral wires. Unplug machine, profit.

Cold Reboot Attacks on Disk Encryption

endecotp — Thu, 21 Feb 2008 22:36:56 +0000

> what if they splice open the power cable and attach their 
> own source so that they can untether it from your outlet, 
> then take it back to their lab

I think you were joking, but that's actually exactly what they do:

http://www.engadget.com/2007/11/06/wiebetech-hotplug-lets...

Cold Reboot Attacks on Disk Encryption

elicriffield — Thu, 21 Feb 2008 20:10:07 +0000

If your seizing a computer that is on, why would you ever shut it off

Just use this device to move a running computer without it ever going to sleep or lose power,
even if its plugged directly into the wall.
http://www.youtube.com/watch?v=erq4TO_a3z8

Disk Encryption only works when the computer is off, and now we know it only works when the
computer has been off for a min or two. 

Hole disk Encryption is still very effective for transporting laptops around, the most common
cause of data lose. Anything you have thats important should be in an encrypted file thats not
decrypted when your not using it, then even if they get to your hard drive your important data
wont be compromised.

You should be more worried about the TSA forcing you to give you there password:
http://www.schneier.com/blog/archives/2008/02/us_customs_...

Eli Criffield

Cold Reboot Attacks on Disk Encryption

cventers — Thu, 21 Feb 2008 19:28:40 +0000

As long as we're playing that game, what if they splice open the power 
cable and attach their own source so that they can untether it from your 
outlet, then take it back to their lab where they can use ultrasound to 
find the case sensors, then cut around them?

:p

Seriously though, there is often a cost factor in making security 
decisions, and I would like to think that so-called "secure DIMMs" that 
are designed to quickly empty themselves upon power loss become prevalent. 
Extraction could still be possible by carefully applying the right power 
to the right pins while removing the chips, but at least it wouldn't be as 
easy as the attack described in this paper appears to be.

Cold Reboot Attacks on Disk Encryption

ncm — Thu, 21 Feb 2008 19:21:58 +0000

Or, alternatively, in some other device: perhaps the graphics chip.  On any given system
there's some bit of complicated hardware that is not used.  On many systems the 3D features
are never used (e.g. Nvidia chip w/ nv driver).   Others have firewire, or an MMC slot.  For
security, it could be an advantage that the key is stored at different addresses on different
machines, particularly if random values are stored in the others, and the actual location used
on any given boot is chosen from among them at random.

Cold Reboot Attacks on Disk Encryption

alecs1 — Thu, 21 Feb 2008 18:52:06 +0000

Two comments about available techonogy(I don't know how usefull):
1.At least in Romania and Germany they have Schuko (http://en.wikipedia.org/wiki/Schuko) as a
standard, the pins are 19 mm and the hole in the socket almost as deep as the lenght of the
pins. Someone would have to chop the plug seriously in order to get to the pins, I tryed right
now, and there is no space to do anything without choping the plug/socket. (these schuko will
get replaced, you need such force to pull them out that many times you also pull the socket
from the wall).
2.Does this represent such an inovation that it will get a patent? I remember powering a
socket like that myself, out of curiosity, this is a trivial idea.

Cold Reboot Attacks on Disk Encryption

freemars — Thu, 21 Feb 2008 18:44:46 +0000

A possible work around -- an expensive one -- could be to store part of the key in a CPU
register (perhaps one of those 128-bit SSE registers).  Not only would this require kernel
completely rewritten to leave that register alone, it would probably slow the operating system
by something like 1/(#_of_registers_in_this_CPU).  Having to guess the final 128 bits of the
key would at least annoy brute-force attackers.

Cold Reboot Attacks on Disk Encryption

zlynx — Thu, 21 Feb 2008 18:43:08 +0000

Use a case-open sensor or five to trigger thermite "heat sinks" (heh) mounted on your hard
disks and RAM.

Physical destruction is the only way to be sure.

Cold Reboot Attacks on Disk Encryption

tcoppi — Thu, 21 Feb 2008 17:59:34 +0000

I think using superglue/epoxy on the chips combined with power-on memory checking and
disabling of external boot devices(such as network or usb booting) should be able to mitigate
this attack well enough, at least for all but the most paranoid of us.

Cold Reboot Attacks on Disk Encryption

alecs1 — Thu, 21 Feb 2008 17:58:56 +0000

Interesting question.
Some folks told me once that power failed gradualy (a few until seconds until incandescent
bulbs went out completely) and they saw the Windows shutdown screen, so probably the OS tried
to go down in an emercency.
I never knew if to believe them or not.

Cold Reboot Attacks on Disk Encryption

JoeBuck — Thu, 21 Feb 2008 17:55:29 +0000

It's not clear that this attack provides much additional capability to either industrial spies or cops.

This attack relies on getting a computer that is still running, so that you can either chill the RAM or immediately transfer the data out. But there are other attacks available in that case. If it's a laptop, you can just take the machine, leaving the power running. Even if not, there is technology available to keep the machine running (saw that on Schneier's blog. If someone has physical access to your machine when it's powered on and the encrypted disk is mounted, they have your data.

As a practical matter, the key can be erased from RAM by an appropriate overwriting sequence (like those used for memory tests) that should suffice to prevent recovery. This could happen on shutdown, and the user could also be given a "panic button".

Cold Reboot Attacks on Disk Encryption

cventers — Thu, 21 Feb 2008 17:55:19 +0000

Perhaps, but I suspect that even that would not be enough. Imagine an FBI 
raid... they bring along their PC, plug it in and get it ready, open your 
case, blast off your RAM with the duster, and then perhaps pull the DIMMS 
out of your running system and slap them into theirs. No power loss event, 
and no interrupt telling the kernel "Quick! Someone is unplugging 
the DIMM, write zeros to it before they can finish!"

I'm glad this research was done, but reading something like this is 
unsettling for encryption in general.

I think what we need is some kind of 'secure DIMM' that uses capacitance 
and sets all its bits to 0 or 1 the moment it loses power. Or perhaps it 
could somehow drain all rows and columns to a big load?

(Disclaimer: I'm not an EE)

Cold Reboot Attacks on Disk Encryption

JamesErik — Thu, 21 Feb 2008 17:35:53 +0000

Surely there's enough capacitance in modern motherboards to provide a few milliseconds of CPU
time when power is lost such that the kernel could detect the start of a power loss event and
can tell the crypto-disk driver to erase its encryption keys?  Or not?

Cold Reboot Attacks on Disk Encryption

Los__D — Thu, 21 Feb 2008 16:46:14 +0000

And the attacker just pulling the plug, when the s/he obviously has access to the machine is
avoid how?

Cold Reboot Attacks on Disk Encryption

flewellyn — Thu, 21 Feb 2008 16:41:01 +0000

Yes, I know; I asked that question there.  :-)

Cold Reboot Attacks on Disk Encryption

rvfh — Thu, 21 Feb 2008 16:38:18 +0000

I think what you really want to do is wipe at shut down, and I am sure this is dead easy to
program into the Linux kernel !
Don't know how fast that is, but start-up memory test being a few seconds, I'd guess the same
time or less to wipe a few GB of memory.

Cold Reboot Attacks on Disk Encryption

patrick_g — Thu, 21 Feb 2008 16:32:20 +0000

>>The only idea that comes to mind is programming the system firmware to "wipe" all system RAM on startup, overwriting the contents of RAM with zeroes prior to loading any operating system. I'm not sure if that would help, though.

If you click on the article link there is an answer to your idea : "An adversary can remove the chips from the target computer and transplant them into another computer that doesnt overwrite RAM on startup".

Cold Reboot Attacks on Disk Encryption

beoba — Thu, 21 Feb 2008 16:14:26 +0000

"At these temperatures (around -50 °C) you can remove the chips from the computer and let them
sit on the table for ten minutes or more, without appreciable loss of data."

So you can probably just pull the RAM modules and stick em into a machine that reads their
contents.

Cold Reboot Attacks on Disk Encryption

johnkarp — Thu, 21 Feb 2008 16:11:38 +0000

Many system firmwares have the option to do a full memory test, which 
presumably overwrites RAM at some point. You'd have to set a BIOS password 
to keep them from skipping it. Though newer boards seem to have that 
option less often in the interest of faster boots.

Cold Reboot Attacks on Disk Encryption

flewellyn — Thu, 21 Feb 2008 16:02:58 +0000

Well, that's...unsettling. What to do about this problem?

The only idea that comes to mind is programming the system firmware to "wipe" all system RAM on startup, overwriting the contents of RAM with zeroes prior to loading any operating system. I'm not sure if that would help, though.

Cold Reboot Attacks, indeed

abatters — Thu, 21 Feb 2008 15:51:48 +0000

> Cool the chips in liquid nitrogen (-196 °C) and they hold their state for hours at least,
without any power. Just put the chips back into a machine and you can read out their contents.

Now *that* is a cold reboot attack.