TRESOR Runs AES Securely Outside RAM
www1.informatik.uni-erlangen.de
www1.informatik.uni-erlangen.de
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).
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?
you need to patch your kernel to use it. this isn't something that openssl alone can push.
I don't, however, think that the magic early-boot changes to prompt for a passphrase almost immediately after boot would have much chance. And I don't really see the point of that compared to the usual mechanism of prompting for a passphrase from the initramfs before mounting encrypted partitions. Either way means that you have key material very briefly in memory before ending up in CPU registers, and thus that you must very carefully wipe that key material from memory before proceeding.
Looking at their patch, it would need a major overhaul to become suitable for acceptance into the Linux kernel. They've also re-implemented sha256 themselves rather than using the kernel's existing implementation, and they've used that sha256 implementation for a very simplistic key derivation function (2000 iterations of sha256 directly on the passphrase itself).
Recordings are available at http://mirror.fem-net.de/CCC/28C3/
Being a FreeBSD fan, I also hope this can be made to work with the "geli" device crypto driver.
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 uses this attack to any useful end with regard to cracking real crypto installations.
That said, does anyone know of recent ARM optimizations for OpenSSL or other SSL implementations?
OpenSSL provides hooks for adding a custom allocator which uses mlock, and some of its interfaces allow for the app to allocate its own key space and pass pointers (hence theoretically allowing the app itself to use mlock or whatever platform-specific method of allocating "safe" memory is desired).
However, this attack vector is often overlooked and is very commonly exploitable - FileVault and the Login Window on OSX were vulnerable to this brand of attack last I checked. The easiest workaround is to use encrypted swap (and the linked project would be a perfect way to encrypt swap in a way that's not vulnerable to a cold boot attack).
[0]: http://citpsite.s3-website-us-east-1.amazonaws.com/oldsite-h...
As an additional plus, the tools which the authors of the linked paper have written for identifying key data in memory dumps are simpler to use than tracing the execution flow of even a simple application using a debugger. I'd probably use their approach even with full debug access, as obfuscating control flow around functions handling key data seems to be a more common practice than keeping said data obfuscated in memory.