www.schneier.com/blog/archives/2008/02/cold_boot_attac.html
piece of research: We show that disk encryption, the standard approach to protecting sensitive data on laptops, can be defeated by relatively simple methods. We demonstrate our methods by using them to defeat three popular disk encryption products: BitLocker, which comes with Windows Vista;
The root of the problem lies in an unexpected property of today's DRAM memories. DRAMs are the main memory chips used to store data while the system is running. Virtually everybody, including experts, will tell you that DRAM contents are lost when you turn off the power. Our research shows that data in DRAM actually fades out gradually over a period of seconds to minutes, enabling an attacker to read the full contents of memory by cutting power and then rebooting into a malicious operating system. Interestingly, if you cool the DRAM chips, for example by spraying inverted cans of "canned air" dusting spray on them, the chips will retain their contents for much longer. 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. 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. This is deadly for disk encryption products because they rely on keeping master decryption keys in DRAM. This was thought to be safe because the operating system would keep any malicious programs from accessing the keys in memory, and there was no way to get rid of the operating system without cutting power to the machine, which "everybody knew" would cause the keys to be erased. Our results show that an attacker can cut power to the computer, then power it back up and boot a malicious operating system (from, say, a thumb drive) that copies the contents of memory. Having done that, the attacker can search through the captured memory contents, find any crypto keys that might be there, and use them to start decrypting hard disk contents. We show very effective methods for finding and extracting keys from memory, even if the contents of memory have faded somewhat (ie, even if some bits of memory were flipped during the power-off interval). If the attacker is worried that memory will fade too quickly, he can chill the DRAM chips before cutting power. Fundamentally, disk encryption programs now have nowhere safe to store their keys. Today's Trusted Computing hardware does not seem to help; for example, we can defeat BitLocker despite its use of a Trusted Platform Module.
There is a general security problem illustrated here: it is very difficult to secure data when the attacker has physical control of the machine the data is stored on.
February 21, 2008 01:52 PM I thought that this was the reason for having the "memory count" at boot-up -- it "wiped" DRAM before startup. I seem to recall later Macintosh computers appearing with this "new old" behavior (about the same time they started using a "standard" keyboard layout); It would seem that having the BIOS do a DRAM "initialize" as part of the POST process would minimize if not render this method moot.
February 21, 2008 01:59 PM Quite a few people will be happy about this: the police, anti-virus researchers, DRM breakers. I especially like the bit where they moved the RAM to another machine before reading it. Maybe if I welded my case shut, set the BIOS to boot only from the HD and password protected the BIOS?
February 21, 2008 02:01 PM Bootman has a nice idea, but it's probably not going to work in general, as 512 bytes probably isn't enough space. Laptops have batteries, so you can probably convert the problem into a very tight race: if either the battery or the mains are disconnected, zap the keys. The downside is that you need to prevent crypto-access to the disk until both mains and battery are online.
February 21, 2008 02:07 PM The DRAM hold is actually quit old news ands has a fairly simple solution. You build your key dynamicaly into a CPU register imediatly prior to use. The key its self is either never stored in RAM or (due to OS issues) securly over writen imediatly it has been loaded etc. The difficult bit is how do you split the key up or encode it so the parts you build it from cannot be found and used to build the key? It can be done and is done in some secure coms units its neither difficult or obvious.
February 21, 2008 02:07 PM Terry Browning: If you read the paper, the memory check/count is a write/read test, so it does actually clear/reset the bits, and systems with ECC have manditory reset on the bits. Part of the problem is that if you can take the machine apart enough while its live, you can freeze the memory with a duster canister, and the memory is good for over 10 minutes at -50C, which is sufficient to put it into a different host which doesn't do the memory clearing on startup.
February 21, 2008 02:09 PM The DRAM hold is actually quit old news ands has a fairly simple solution. You build your key dynamicaly into a CPU register imediatly prior to use. The key its self is either never stored in RAM or (due to OS issues) securly over writen imediatly it has been loaded etc. The difficult bit is how do you split the key up or encode it so the parts you build it from cannot be found and used to build the key? It can be done and is done in some secure coms units its neither difficult or obvious.
February 21, 2008 02:10 PM Clive, the problem is you need some serious low level OS and CPU VooDoo to get a piece of memory, even just 256b, that doesn't leave the confines of the cache.
February 21, 2008 02:21 PM @Anonymous -50 is no big deal. The thin metal or plastic clips you will touching have almost no heat capacity so your fingers will heat them to body temperature almost immediately. Where we live our fingers are exposed to air of similar temperature every winter and air has about the same heat capacity as these tiny clips.
February 21, 2008 02:50 PM This effect was discovered in late 1978 at Apple. The Autostart ROM for the Apple checked for a RAM jump-vector at every reset. In order to detect a cold boot, it was necessary to use a checksum byte.
February 21, 2008 03:03 PM Seems to me the natural defense against a power-interrupt attack is to rely on induction to wipe the memory. That is, somehow arrange for a coil carrying a DC voltage around the DRAM, with the voltage chosen so that a sudden power interruption will induce enough current in the chips to put some random charge on each little storage capacitor --- but hopefully not enough to damage the chip, or mess up the hard drive. Of course, now you have to protect the coil, and its circuit...
Why can't the OS just wipe the sensitive bits when: a) the OS is shutdown, or b) the power supply detects powerfail? The CPU and RAM should still have a few milliseconds between the powerfail signal and the PSU's smoothers actually running out of juice.
February 21, 2008 03:36 PM @Clive : "Just think of a snake swallowing its tail in the dark then work out how it could do it forever 8)" Judging from the triple posting I suspect you've been drinking benzene rather than dreaming about it!
February 21, 2008 03:39 PM (Sorry, apparently this blog eats html in comments) "The difficult bit is how do you split the key up or encode it so the parts you build it from cannot be found and used to build the key?" People have reverse-engineered far more complex obfuscation techniques than that just to crack their favourite game.
February 21, 2008 03:40 PM Andrew2 OS shutdown is no problem - there's lots of time then; The latter problem has a couple of reasons - nobody thought of doing it - which few hundred KB to wipe with your last precious power? You'd have to provide, in hardware, for every possible disk encryption system. Alternately I guess, hardware vendors could provide a standard memory range that will always be wiped regardless of whether shutdown is graceful. OS's would have to provide a method to guarantee that certain data will be kept in such self-destructing RAM, and never leave it.
That's where the bios bootloader will put the fir...
|
http://csua.com/feed/