I think this is not as useful at it looks. Most of local attacks that allow you to read arbitrary memory locations also allow you to run arbitrary code which can simply read the debug registers, it's interesting to note that state of debug registers is not defined after reset, which probably means their state is retained across resets.<p>Also one could assume, that whole architectural state of CPU - including debug registers - can be read out using JTAG test port of CPU (I haven't find any official documentation about JTAG capabilities of Intel's CPUs, but there are commercially available JTAG attached ICDs for x86 CPUs).
I think this, or a similar implementation at any rate, was previously posted on HN. It's certainly a good idea, and I think that the more popular crypto libraries (I'm looking at you, OpenSSL) would do well to consider implementing something similar.<p>The key point being that (and this was my biggest concern), it is fully compatible with AES-NI, the Intel's hardware-accelerated AES instruction set. According to TFA, with AES-NI there is no performance penalty for keeping the AES keys stored in registers and out of the RAM. What's not to like?
This was presented at the 28C3. <a href="http://events.ccc.de/congress/2011/Fahrplan/events/4869.en.html" rel="nofollow">http://events.ccc.de/congress/2011/Fahrplan/events/4869.en.h...</a><p>Recordings are available at <a href="http://mirror.fem-net.de/CCC/28C3/" rel="nofollow">http://mirror.fem-net.de/CCC/28C3/</a>
This is a very cool development. I hope the OpenSSL project verifies this method and imports it so that more projects can benefit from this.<p>Being a FreeBSD fan, I also hope this can be made to work with the "geli" device crypto driver.<p>Out of curiosity, has there ever been an exhaustive study about the effectiveness against cold boot attacks against various crypto systems on various platforms? I hear much about cold boot, but is it used much in the wild for practical use, like in criminal investigations? I have never been able to find any reputable confirmation that anyone actually <i>uses</i> this attack to any useful end with regard to cracking real crypto installations.
While it is nice to see improvements like these, I sure would like to see more work done on ARM implementations, especially given the huge number of mobile devices based on ARM these days.<p>That said, does anyone know of recent ARM optimizations for OpenSSL or other SSL implementations?
This seems like a good idea, I'm curious what OpenSSL or other crypto libraries do to keep secrets from being paged out to disk by the virtual memory machine? That seems like a legitimate attack vector.