protection against hardware attacks (RAM removal)

Hauke Laging mailinglisten at
Thu Sep 1 15:57:41 CEST 2011


as probably most of you know it is possible to grab key material from a PC by 
powering off the system and immediate removal of the RAM and continuing its 
refresh in other hardware. The harder variant of the suspend to RAM problem... 
If the RAM is cooled down before powering off this works quite well.

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

If you remove the RAM information starts getting lost immediately. The longer 
it takes to start the refresh again and the higher the RAM temperature is the 
more information is lost. I you know where (approximately) in memory a key is 
stored and just a small part of it has been destroyed then it is not a problem 
to recover the key.

Software cannot influence the size of the share of the information which gets 
lost as this is hardware stuff. But software can influence how much 
information (measured in bits and bytes) you need. My proposal is to increase 
this amount of memory so that even a small share of lost information is 
equivalent to a brute force resistant amount of bits.

The keys could be expanded to several kilobytes of RAM (could be easily 
configured to the desired protection level) right after they have become 
available to GnuPG. I guess even something as trivial as XOR could be used to 
securely spread the key over more memory.

Every time a crypto operation needs a secret key, the key is recovered from 
the expanded area, used and overwritten afterwards. That would make it very 
improbable that the key is available in RAM as clear data. There may be ways 
to trigger the use of secret keys over e network (i.e. send an encrypted 
email) but that can be solved elsewhere. And even then an attacker would have 
to be very lucky (and would have just one chance). If there are no task 
switches in between then the raw key data would probably never reach RAM 
(would be written and overwritten in the CPUs write back cache).

Does anyone of you know whether there are features (or plans for such) 
addressing this problem with mainstream CPUs? Either in hardware or in 
software? Does Linux allow locking of pages in a L1 cache (in order to prevent 
the data from being written to RAM)?

PGP: D44C 6A5B 71B0 427C CED3 025C BD7D 6D27 ECCB 5814
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 555 bytes
Desc: This is a digitally signed message part.
URL: </pipermail/attachments/20110901/5ae889b0/attachment.pgp>

More information about the Gnupg-devel mailing list