IOTTMCO

Intuitively Obvious to the Most Casual Observer

Cold-boot attacks are overrated

Since the publication of Lest We Remember in 2008, “cold-boot attacks” where the attacker can read the RAM of a recently shut-down computer have been considered the bane of full-disk encryption (along with any other security measure that stores sensitive information in RAM only). The wikipedia page claims that the memory contents of RAM “remain readable in the seconds to minutes after power has been removed”. Supposedly, this means that after shutting down your computer, it is not immediately safe to leave it unguarded; an attacker could take it, boot it a minute later, and recover encrypted data from RAM.

This statement sounds plausible enough, and has the nice property of being testable. As it turns out, it has the not-so-nice property of being mostly false.

I wrote a quick pair of programs, taint-hunt to place a unique byte string (a “marker”) in memory, and to search for it or any other byte string within a certain hamming distance (to allow for a limited amount of memory corruption). Rather than go to the effort of writing a minimal bootable program to scan memory, I elected to just live with the fact that linux will overwrite a small fraction of RAM on boot, and place as many copies of the marker in memory as necessary to ensure that that isn’t an issue. For access to physical memory, I used my rmem hack mentioned in a previous post - this is equivalent to the old /dev/mem device, or the newer one with CONFIG_STRICT_DEVMEM set appropriately.

To ensure the system is working as desired, I filled memory with taint markers, rebooted (without a cold boot), and scanned memory with hunter from a different partition specially created not to start unnecessary daemons. Unsurprisingly, all taint markers placed in memory were quickly found by the hunter, with no corruption.

Now to test the actual cold-boot attack. Fill memory with around 1000 taint markers, just to be sure there are enough.

while true; do
taint -sleep > /dev/null &
done

Now shut down. Ostensibly, the markers could be recognizable in RAM after whole minutes, but I’m impatient, so I just waited 10 seconds for the first test. Boot up, into the minimal linux installation. Load the kernel module: insmod ./rmem.ko. Run hunter.

Nothing.

That’s ok, though. There should be at least some data corruption. The default marker size is 128 bytes, so let’s set the hamming distance to 128, meaning that one bit out of every byte is allowed to be flipped. (Statistically, that’s equivalent to a 25% corruption rate, since a corrupted bit has a 50% chance of remaining the same).

./hunter -dist 128

Nothing.

In fact, nothing will be found until you set the hamming distance to around 500, at which point you’re just looking at coincidences that are statistically bound to happen. Two random 1024-bit strings will, on average, have 512 bits in common.

Looks like in 10 seconds, memory was completely corrupted. Let’s try a shorter interval: 2 seconds. Same results. Nothing is left of our “encryption key”.

My computer for testing this is a Pangolin Performance (from System76) with DDR3 RAM made by Samsung, with a clock speed of 1600 MHz. According to the paper, the amount of time for which data may linger varies greatly from computer to computer - however, only one that they tested would have significant amounts of data after 10 seconds.

The scenario in which an attacker steals a computer only seconds after shutdown to take data off of it is simply implausible. The oft-referenced video the researchers posted used the computer that displayed the longest decay times, and without a note that it was highly atypical. For a small number of (mostly older) computers, it may be a possible attack, and it’s worth testing to see if that’s the case - but most circumvention measures are entirely unnecessary.

The other cold-boot attack scenario - in which the computer is deliberately shut-down after cooling the RAM, so as to boot into another operating system where the contents can be more easily analysed - is rather more plausible. It’s important to realise, however, that that same end can potentially be achieved in other ways (by keeping the RAM powered during the power cycle say), and physical access to a powered-on computer will always yield access to the contents of RAM, regardless of any software circumvention measures taken.