Home > Cryptography, Exploits, Programming, Security/Exploits > Cold Boot Attacks Revisited (again).

Cold Boot Attacks Revisited (again).

Following my recent post on FireWire Attacks, I thought I’d follow up on that other classic Full Disk Encryption exploit, The “Cold Boot Attack”.

Back in February 2008 a group of clever Princeton students published their infamous paper “Lest We Remember: Cold Boot Attacks on Encryption Keys“. Though the retention of data in RAM chips has been known since their invention, and certainly since at least 1978, The “Princeton Paper” reminded us that when you turn a computer off, it does not mean all the data from memory is instantly gone, and of course, if something important remained, like an encryption key, then your computer security might be vulnerable.

The important thing that Halderman et all did, was turn this theory into practice with some very cool demonstrations, actually proving the attack was valid in some notable systems such as Microsoft Bitlocker, TrueCrypt, and FileVault, by actually retrieving the encryption keys with a very high probability of success, without actually using any refrigeration in some cases.

Though a lot of this research is about cooling DRAM to extend the time it preserves information for, the attacks mentioned in the paper are quite valid without cooling at all – You can exploit the retention problem simply by rebooting your machine. Unless you have very specific (ie expensive) memory chips, almost everything will still be there after a reboot, though of course much will be overwritten by new information loaded up. Reboot to a much smaller OS (Chapter 4 of the paper), say one loaded off a USB stick, and you obviously can access much more of what was “there before”.

Cold Booting, or removing the DRAM after refrigerating it gives you much more flexibility, and the potential access to all the memory, but “cold” is not really necessary for the kind of attacks which frighten users with sensitive data.

Princeton maintains a really good site about this attack, with some useful resources such as:

How Practical Is this attack?

It’s very practical, very practical indeed. A hacker with a memory stick or iPod could walk up to your running machine (though locked of course!), reboot it and retrieve almost the entire contents of the memory in a couple of minutes. The memory could contain passwords to your VPN, web sites, documents you’d opened, the encryption keys for files, or for products such as Bitlocker or TrueCrypt.

Given that, the hacker could perhaps then decrypt any information on your machine.

What can you do to protect yourself against it

The simplest way of course is to use encryption to protect your data, and to make sure your machine is powered off before you leave it. After a few seconds of no power, the data in DRAM looses enough information to make key recovery impossible, and mostly after 3 seconds or so (though up to 35 on old machines) it’s purely random.

The caveat is though that you MUST use encryption products where the key is not stored with the data. Any product which allows you to access the data without entering a password, or supplying a token will not protect you from this attack, so, Bitlocker in TPM only mode is out for sure.

If you have pre-boot authentication, with full disk encryption (you have to enter a password before Windows boots for example), or you have to enter a password to open a file, then you are probably protected after the handful of seconds it takes for the DRAM to decay.

If you are worried about this attack, you must not use low-power “suspend” modes, as an attacker can simply power your machine back on and capture the ram. As above, you also must not use any “auto login” or “Wake on lan” mode with full disk encryption products – again, a hacker can just turn the machine on, wait for it to boot it self up, then dump the DRAM and capture the keys.

From there, they can decrypt your entire drive and read all the data.

Are McAfee Products Vulnerable?

I can’t talk about ALL McAfee products, but in particular you should consider the following. All products from all encryption vendors, where protected data has been accessed are vulnerable if the machine is sitting at a screen saver, or suspended (low power mode), and the keys are in memory – to resolve this:

  • McAfee Endpoint Encryption for File Folder has an option to unload the keys if the machine is locked (screen saver, suspend, hibernate etc), so it would protect encrypted files if you use this option. encrypted files are ALWAYS protected if the machine is hibernated (or shut down), as the keys are always unloaded.
  • McAfee Endpoint Encryption for PCs (full disk encryption) unloads the keys on shutdown and hibernate, though NOT in suspend mode (it needs the key to wake the machine up). If you are using pre-boot authentication, and your machine is hibernated (or shut down), you are protected from this attack.

My advice is to hibernate, not suspend, and use full disk encryption with pre-boot authentication to ensure you are compliant with PHI and PII Data Disclosure regulations, but you need to do a risk analysis based on the value of the data you are protecting, the cost of disclosure, and the risk of loss. Once you know that you can decide whether this attack, or data loss in general, is something you need to be concerned with.

  1. Manjula Kularathne
    September 20, 2009 at 06:26

    Very interesting read Simon.Thanks!
    Mcgrew RAM dumper alos can be used with a usb key to dump truecryp keys. Volatile memory artifact extraction utility framework also can be used for extract.

    If my EEFF keys allowed to be used `cached locally` then technically I could dump my keys?


    • Simon Hunt
      September 20, 2009 at 08:51

      Being “cacheable” or not does not change things – they need to be in memory at the time the dump is made, so if you’re using the “clear on screen saver”, then if your machine is locked the keys are flushed out, same as they would be if they were not cacheable.

      All the cache does is allows you to retrieve a copy of the key from the local (encrypted) keystore, rather than having to get it from the server.

  1. No trackbacks yet.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

%d bloggers like this: