protection against hardware attacks (RAM removal)

Robert J. Hansen rjh at
Thu Sep 1 17:48:18 CEST 2011

> I just had an idea (I hope it's new...) how this risk could be reduced
> least for applications which need their keys from time to time only, may
> be not suitable for disk encryption.

ObNotice: I'm not speaking for my employers, past or present.  (Some of my
prior jobs involved memory forensics, hence the note.)

This idea has come up before and gets reimplemented every few years.  It
tends not to work.  It is *theoretically* possible to do this, but in
practice it's pointless.  Imagine that for each and every bit you expand it
out into a random 100-bit bitstring.  If the bitstring has an even number
of 1s then the encoded bit is 1: if it has an odd number of 1s the encoded
bit is 0.  Once you've created your bitstrings you then tweak a random bit
in each bitstring, if needed.  Presto: you've expanded the memory required
by a factor of 100, and losing any one bit of the 100 will throw off the
entire result.

In practice, this doesn't gain us anything.  If the attacker has physical
access to the hardware it's a game-over condition.  Further, attackers can
defeat this pretty easily: closing the laptop lid, for instance, will force
a hibernation and the OS will dump all memory to disk.  Even if hibernation
is disabled, a can of compressed air can be used to cool the chips prior to
removal: do this and memory won't begin to degrade for a couple of minutes
-- plenty of time to move the chips to a powered breadboard.  Etc., etc. 
There are a whole lot of ways around this.

If you're worried about an attacker lifting the RAM out of your system,
your proper defense is to keep the attacker from lifting the RAM out of
your system -- not trying to make the degradation curve work in your favor.

More information about the Gnupg-devel mailing list