protection against hardware attacks (RAM removal)
Hauke Laging
mailinglisten at hauke-laging.de
Thu Sep 1 15:57:41 CEST 2011
Hello,
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)?
Hauke
--
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