Countermeasures for cold boot attacks on encryption keys?

blackhole54 · 08-10-2008, 05:05 AM

@ Amdx2_x64

While I was being a little flippant in the second paragraph of post #10, I was fully serious on the first sentence of that post. I am speaking specifically about protecting keys you use to decrypt partions/hard drives. My impression is that your only serious defence against a cold boot attack is to make sure that when the computer is shut off (and possibly suspended/hibernated) that the relevant keys in memory are overwritten first. And then make sure that while those keys are in memory that you are physically protecting the computer.

Amdx2_x64 · 08-10-2008, 06:28 AM

Quote:

Amdx2_x64, I've merged your thread into this one, as it's essentially the same question/discussion.

Thank you. I somehow missed this thread.

Amdx2_x64 · 08-10-2008, 06:48 AM

Quote:

Originally Posted by blackhole54

@ Amdx2_x64

While I was being a little flippant in the second paragraph of post #10, I was fully serious on the first sentence of that post. I am speaking specifically about protecting keys you use to decrypt partions/hard drives. My impression is that your only serious defence against a cold boot attack is to make sure that when the computer is shut off (and possibly suspended/hibernated) that the relevant keys in memory are overwritten first. And then make sure that while those keys are in memory that you are physically protecting the computer.

So the most simplest and best way is to just turn of the computer and then turn it on after one works with any encryption key.

Personally I never see this as a problem for me. The more I read the more it seems that someone is more likely to get hit by lightening then a cold boot attack. But it still is interesting that this can be done and that some, especially those with laptops, need to just take an extra, simple step for added security.

Now if you will excuse me, I am going to get a cup of coffee, stirred not shaken

win32sux · 08-10-2008, 04:33 PM

Quote:

Originally Posted by Amdx2_x64

So the most simplest and best way is to just turn of the computer and then turn it on after one works with any encryption key.

I seriously doubt that. I mean, the reliability of said approach doesn't compare to actually overwriting the memory space with the keys in it before powering down (or whenever one is done using the keys, in case one doesn't want to power down). By relying on a power-down/power-up you are essentially leaving it to chance whether or not the keys get overwritten AFAICT (plus it's incredibly inconvenient).

That said, don't forget that (as has already been mentioned), the bad guy can just cut the power, preventing the overwrite from happening, and then launch a cold boot attack. Overwriting at shutdown provides a little bit of comfort for desktop/laptop users who are fairly certain their boxes won't get physically owned while turned on (such as if your residence was raided), but it's not applicable to servers unless you've got some sort of interface between your physical site alarm system or something like that (which will alert the server that the physical perimeter has been breached and it should unmount encrypted stuff and overwrite the keys).

Perhaps new RAM modules will use storage technology which guarantees there is no residue when power is cut?

Actually I'd bet there's stuff like this already. Anyone?

blackhole54 · 08-11-2008, 01:25 AM

Quote:

Originally Posted by win32sux

Perhaps new RAM modules will use storage technology which guarantees there is no residue when power is cut?

I dunno. It would be nice but I fear it might just be wishful thinking. There seems to be so many subtleties with memory/storage media, and the attackers seem to be so ingenous. Actually, capacitors, which is what dynamic RAM is, retaining their charges is not that subtle. But I remember being shocked when learning some time ago that keeping a (any) particular value in static RAM for a prolonged period caused the RAM to tend to contain that value at that location when it powered up.

Also, when I was thinking about this attack I was thinking about dekstops/laptops. (Particularly laptops.) Is it even common to use disk encryption on servers? I thought servers containing sensitive info were usually physically locked down pretty well. I remember reading about a server at some university (Harvard?) that was in what was darn near the equivalant of a bank vault.

slimm609 · 08-11-2008, 11:47 AM

Code:

#!/usr/bin/perl -w

use warnings;
use strict;


my $string = "";
`dd if=/dev/urandom of=/tmp/$$ bs=512 count=1000 > /dev/null 2>&1`;
`renice -20 -p $$`;


open(FH,"< /tmp/$$") or die "cannot open input file: $!\n";
while (<FH>) {
        chomp;
        $string = $string . "$_"
}
close FH;
`rm -rf /tmp/$$`;




while ( 1 ) {
        $string = $string . $string;
}

something similar to this would be useful on a shutdown after the drive has been unmounted.

run this 2-3 times to clear the ram

on 12Gb of ram it takes about 3 seconds to run and then it get "out of memory" error which is what we want.

chort · 10-01-2008, 12:03 PM

BIOS passwords do not mitigate this, because guess what? The RAM shadows the password after it's entered correctly, so while the system is waiting at the "enter your password" prompt, the correct password is already in RAM.

I just saw Jacob present this at Toorcon over the weekend and the consensus seemed to be that the only way to defend against it is to have proximity sensors around the machine to detect unauthorized presence and zero-out memory. If an attacker is able to remove power you're pretty much hosed, because they can immediately chill the RAM chips and then transport them off-site to place in their own memory reader and dump the contents.

By the way, turning off a machine may work for a laptop, but what do you do with servers that are supposed to be up 24x7?

slimm609 · 10-02-2008, 01:26 PM

For 24x7 servers it comes down to physical access. You don't have a 24x7 production server sitting out in a unprotected area. Myself in perticular (considering I work in a classified area where no cellphone, pagers, pda, camera's, etc are allowed) would worry more about the person in my facility then them getting access to the ram.

win32sux · 01-18-2009, 08:21 PM

Seems like someone has decided to take a shot at this. My guess is it won't end up being a solution, but will at least make the attack much more difficult. I do wish this guy the best of luck with his project.