Re: cold boot attacks on cgd?

["Steven M. Bellovin" <smb%cs.columbia.edu@localhost>]

On Mon, 25 Feb 2008 22:34:55 -0500 (EST)
der Mouse <mouse%Rodents.Montreal.QC.CA@localhost> wrote:

> > (There's an amusing corollary to this.  If the attacker has to go
> > after the key, which may have some bits reset, there's suddenly an
> > advantage to AES-128 -- more bits to try...)
> 
> If you really want to exploit that, secret-split the key, so it's
> spread over several thousand bits, then reconstruct it on the fly when
> it's needed.  For these purposes, even an (n,n) splitting technique is
> good enough, such as XOR with a lot of equal-sized random blocks.
> 
> Ideally, you want to spread the key over so many bits that the error
> rate introduces at least as much uncertainty as there is entropy in
> the key.  I don't know what the error rate is like; if it's 1%
> (picked out of the air), a 64-bit key needs only on the order of 6400
> bits - 800 bytes - to achieve this; I'd be hesitant to recommend any
> specific amount without doing tests to see how far down I could pull
> the error rate.  (You might be able to reuse the RAM that holds the
> key schedule....)  Of course, the lower the error rate, the more
> spreading you need to do.  And if, as I suspect, errors are
> preferentially in one direction (eg, 1s becoming 0s), it gets more
> complicated.

There's a specific technique for doing that mentioned in the paper.
> 
> And hey, this may be the first case I've heard of where ECC RAM is a
> distinct *dis*advantage!
> 
It's mixed, according to the paper.  While they mention the effect
that you point out, they note that at boot time, ECC memory is always
cleared, so that it starts in a known-good state. 



                --Steve Bellovin, http://www.cs.columbia.edu/~smb