Fedora - Cold Boot Attack

[Gregory Maxwell]

On Sun, Nov 7, 2010 at 1:57 PM, Stephen John Smoogen <smooge at gmail.com> wrote:
> Ok there are several different "cold boot attacks". The one  I think
> you are talking about is the removing memory from the system and
> reading its contents with a special board. The kernel does not
[snip]

Not even with a special board, ...

> In the end, if someone has physical access to your system, you are not
> going to be able to completely defend against a cold boot attack.
> Encrypting the drive and keeping it reasonably secure is about all you
> can do without having hardware that helps.

Here is the attack:  Your system is running with nice secure encrypted
drives, no console access (or a locked screen on a laptop). The
attacker inserts a bootable USB key and hits the power switch. System
reboots into the USB key, it retrieves the cryptographic keys for
reading your disk from memory, then copies whatever information it
likes.

This works even when a fairly high percentage of the key bits are
corrupted because the bits of the AES key schedule have simple linear
relationships with the key, so it functions as an excellent error
correcting code.

For some common situations like protecting your laptop with disk
encryption this attack completely invalidates the protection, at least
against a moderately savvy attacker.

The software for performing this attack is available from here:
http://citp.princeton.edu/memory/code/

This is not merely a theoretical weakness. It is easily executable by
anyone without the need for special hardware.

Without special hardware (like support for CPU-internal key
management, CPU support for encrypted ram) this attack is impossible
to close completely but small improvement could easily be made which
dramatically increased the difficulty of the attack.

* The kernel could avoid leaving confidentiality critical data laying
around for long spans of time, long term keying could be stored in
areas of memory more reliably overwritten at reboot

* Bioses could be modified to zero-ize memory at start

* Ciphers with linear key-schedules could be avoided (unfortunately
everything from the AES contest is bad at this, because the contest
pressure to work on low memory devices and small message sizes made
everyone use very cheap initialization; blowfish is an example of
something which I think is mostly free of that particular weakness)

* Userspace could freeze all access to encrypted volumes when the
screen is locked and toss the keys. (This is most reasonable when the
volume password and the user's login password are the same)


There were patches posted to the Linux kernel to reduce the exposure
from this kind of attack: http://lwn.net/Articles/334747/  but
unfortunately the author and the LKML didn't get along and the patches
were never merged.