Re: cold boot attacks on cgd?

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

On Mon, 25 Feb 2008 23:32:06 -0300
César Catrián Carreño <ccatrian%eml.cc@localhost> wrote:

> On Tue, 26 Feb 2008 02:02:59 +0000
> "Steven M. Bellovin" <smb%cs.columbia.edu@localhost> wrote:
> > On Mon, 25 Feb 2008 18:49:18 -0300
> > César Catrián Carreño <ccatrian%eml.cc@localhost> wrote:
> > 
> > > Hi list.
> > > 
> > > According to this url, http://citp.princeton.edu/memory/ , a
> > > crypto key can be retrieved from RAM after the computer is
> > > shutdown.
> > > 
> > > Is CGD vulnerable (storing the key on RAM), to this kind of
> > > attack?
> > 
> > Yes.
> > 
> > There is apparently some BIOS magic that can be done to force
> > certain sections of RAM to be zeroed by the BIOS at boot time.  I
> > don't know anything more about how to set that flag.  Even if it is
> > set, there's no defense against someone chilling the RAM, removing
> > it from your machine, and putting it into their own.
> > 
> >             --Steve Bellovin, http://www.cs.columbia.edu/~smb
> 
> 
> Should the CGD's parameters file secure storage deal with this issue?
> 
I don't think it can.  I don't think there's any strong defense short of
putting decryption keys into a properly-designed tamper-resistant chip.

The paper had two main results.  First, the contents of memory are
largely unchanged after short power outages, i.e., doing a power off/on
cycle to reboot.  You can stretch that time by chilling the memory; at
liquid nitrogen temperatures, the contents persist for hours.  The
attack, then, is power-cycle and boot from your own device -- say, a
bootable flash disk or CD.  Alternatively, chill the RAM, remove it,
and install it in your own machine.

The second result is that even though a few bits of the key may be
damaged, it's possible to reconstruct them by looking at the key
schedule.  The key schedule is an expanded form of the key; as such, it
has considerable redundancy.  They came up with an algorithm that lets
them look at these redundant bits and reconstruct the original key,
with little computational effort.  Software implementations of block
ciphers almost always keep the key schedule around, because it's much
more efficient to do so.

Perhaps cgd could discard the key schedule after a few (not very many)
seconds of not using it.  It would, of course, keep the actual key in
memory.  As needed, it would recompute the key schedule.  It would take
some analysis and benchmarking to be sure, but my suspicion is that the
performance impact would be minimal for most typical disk usage
patterns.  We could also zero the key schedule on certain ACPI events,
such as suspend, power button, etc.  In fact, there's very little
downside to zeroing it at the slightest provocation, once we have the
code in place to recompute it on demand.

(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...)

Note that this software technique -- it's a more polite word than
"hack" -- is useless against a Freon attack.



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