HOPE 2008: Cold boot attack tools released

The team from Princeton has released their cold boot attack tools at The Last HOPE. Earlier this year they showed how to recover crypto keys from the memory of a machine that had been powered off. Now they’ve provided the tools necessary to acquire and play around with your own memory dumps. The bios_memimage tool is written in C and uses PXE to boot the machine and copy the memory. The package also has a disk boot dumper with instructions for how to run it on an iPod. There’s also efi_memimage which implements the BSD TCP/IP stack in EFI, but it can be problematic. aeskeyfind can recover 128 and 256bit AES keys from the memory dumps and rsakeyfind does the same for RSA. They’ve also provided aesfix to correct up to 15% of a key. In testing, they only ever saw 0.1% error in there memory dumps and 0.01% if they cooled the chips first.

We saw another interesting tool today: coreinfo is a library for the custom BIOS coreboot. Using it you can examine the memory directly without any damage.

The Q&A session at the end of [Jacob Appelbaum]’s talk included a discussion of possible countermeasures. We’re convinced that this won’t be solved until there’s a fundamental change to RAM design. One of the interesting suggestions we heard was building a “RAM condom”. It would be a riser card that the RAM plugs into. When the case intrusion system triggered it would blank the RAM. It’s an interesting idea; anyone want to build it?

11 thoughts on “HOPE 2008: Cold boot attack tools released

  1. well, the case intrusion detection can be circumvented, if you know the hardware design…

    but wouldn’t adding transparent encryption to the memory controller do the trick? the secret key to encrypt memory could be regenerated with every boot directly on the controller and (since it’s small) be stored locally in some other type of memory cell that (somehow) is not attackable?

  2. Lock the case shut. Stick a timer circuit between the power button and motherboard that prevents you from powering on the system for 10 seconds after shut down. Stick a case trigger switch that does the same – open up the pc, pc shuts down, by the time they figure out what it happening/bypass the circuit the memory is empty. Stick an enclosure around the ram to prevent them from cooling the chips while the pc is off (or else they can retain data for more than 10 seconds and get around the circuit). Lastly tilt switches and stuff will trigger a shutdown if the case it moved.

    This just leaves the reset button. You could replace it with a key switch or just disable it all together (the inconvenience of having to wait 10 seconds for a reboot – clearing the memory might be beneficial in some restart cases, for the convenience of security. Fair price).

    As an added measure epoxy the connectors between the switch, timer circuit and motherboard to prevent a quick easy bypass.

    How far do you want to go?

  3. Wow, I would say that just about covers it. And if you need more security for your data, you might want to look into something outside the PC (like building security).

  4. Have the system clear RAM on reset, and have a small chip on the stick itself that clears the RAM on loss of power. Could also do a bit of a bios thing that creates a boot ID that changes at bootup, and have a chip on the RAM passively overwrite what’s from the previous session.

    *Points to previous poster.* He’s got the idea with the small capacitor on the memory modules. The transparent encryption/decryption might work for HDDs, but RAM would be too hindered by it and most people would just disable it.

  5. I’d like to see this used to sign software on the Xbox 360 so we can finally have softmodding available for the thing. I also see this useful in getting around DRM.

  6. Or have the operating system blank the RAM as the last thing it does before shutting off. At that point disks are not mounted so the keys are not needed anymore. Then the only data left in RAM to hack would be the code for blanking it.

  7. has anyone here used this code after compiling it. I used the usb dump method and was able to capture the contents of ram, but the usbdump application keeps giving me an error saying bad checksum. Just wondering if anyone else is having the same problem. Thanks.

Leave a Reply

This site uses Akismet to reduce spam. Learn how your comment data is processed.