Back in my Commodore 64 days, a useful trick to gain access to the code of an interesting game or demo was to use a paperclip to force a cold reset. This restarted the machine, but left most of the memory intact, allowing you to nose around to your heart's content.
So with this in mind, I read with interest a recent paper by researchers at Princeton on the use of similar techniques to break into encrypted hard drives (http://citp.princeton.edu/memory/).
The basic idea is quite simple: force the target machine to cold boot, bypassing the normal secure shutdown processes that unmount the disk and scrub the keys from memory. You can then dump the memory and hunt through it for the encryption keys and bypass all that tedious cryptanalysis or waiting for the heat death of the universe while you use a brute-force attack.
But the Princeton team added a couple of interesting twists. First, they proved that memory retains its contents for some time after the power has been removed.
This retention time can be further extended by cooling the memory chips; using a can of air duster they managed ten minutes before it degraded beyond use, up to over an hour if the modules were cooled in liquid nitrogen.
This attack has been widely reported as the silver bullet to kill disk encryption, with The Register trumpeting it as "a gaping hole". A more reasoned analysis paints a less depressing picture. The most likely attack is the "cold boot" variant, where an attacker forces a target machine to reboot from their malicious code.
This requires access to the machine while it is powered on (or very recently powered off) to ensure that the encryption keys are still resident in memory.
In contrast, the most common cause of lost laptops is theft when the laptop is shut down, for example in a car boot. This means that, unless your car boot is really, really cold, the keys will have disappeared from memory after a few minutes.
The same sort of access, where the keys are still in memory or have only just started to fade, is required for the "really cold" variant, along with a thermos of liquid nitrogen or can of freezer spray. The difference is you can then take the memory away and do your forensics in the comfort of your own home, lab or office.
These limitations do not mean there's nothing to worry about, but good physical and procedural security (shutting down or "dekeying" the encryption before leaving the laptop unattended) will address the main threat.
There's also the need to ensure your machine only boots from what you want it to. The paper describes the use of a malicious "boot from network" attack, which would work on a lot of default machine configurations. These vulnerabilities don't just open you up to the "cold key" attack, so should already be on your worry list.
To fix the problem requires specialised cryptographic hardware to hold and process the keys, protected from tampering and with its own battery-backed secure erasure mechanism. While such things exist for military and high-security banking applications, they won't be featuring as standard equipment in PCs any time soon; such paranoia doesn't come cheap.
The Trusted Platform Module (TPM) used in newer laptops may be able to help, but it isn't entirely clear from the voluminous documentation (http://tinyurl.com/yqm59deg). Indeed in its simplest mode, BitLocker's use of the TPM actually assists the attack. Even trusted hardware is not a foolproof solution. Attention to simple details such as wiping the keyboard buffer after passphrase entry are often overlooked.
This research has kick-started a whole range of "look what I found in memory" attacks. Most of these issues are down to poor programming practice, so highlighting and, hopefully, fixing them is the way to move forward.
The difficulty of using general-purpose hardware for high-security encryption is well known, as the history of attacks against DVD and software copy protection have shown. This recent research demonstrates once again that, when the attacker has the equipment in their hands, the task is even harder.
Nick Barron is a security consultant. He can be contacted at firstname.lastname@example.org.
By Nick Barron on May 9, 2008 3:20PM