5 ms·

TRESOR Runs AES Securely Outside RAM

35 points by blasdel 15y ago

ComputerGuru 15y ago
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. 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?
- munin 15y ago
  > What's not to like? you need to patch your kernel to use it. this isn't something that openssl alone can push.
  - loeg 15y ago
    So TRESOR needs to submit an acceptable patch to the nice kernel.org folks, and then it can ship as a distro default.
    - lukeschlather 15y ago
      It sounds fairly cpu-specific. I'm not sure it would lend itself very well to being packaged up for general distribution.
      - JoshTriplett 15y ago
        Linux takes CPU-specific patches all the time, and has numerous modules to take advantage of CPU features. As long as the patch gives it a clean interface and meets the Linux kernel's standards, I don't see any major roadblock. 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).
listening 15y ago
Registers. Love 'em. Where's the BSD version?
macrael 15y ago
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.
- bri3d 15y ago
  On most platforms, mlock(2) and mlockall "lock" data in memory, theoretically preventing it from being paged to disk. 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).
- tptacek 15y ago
  It is, but keep in mind that on general-purpose computers running AES, if you can extract secrets from virtual memory, you are already in a position to wiretap the AES process directly.
  - bri3d 15y ago
    A cold-boot attack as detailed in [0] makes it vastly easier to extract secrets from physical memory than to wiretap the AES process, especially if you're not in possession of a privileged user account or a route into kernel space. [0]: http://citpsite.s3-website-us-east-1.amazonaws.com/oldsite-htdocs/pub/coldboot.pdf http://citpsite.s3-website-us-east-1.amazonaws.com/oldsite-h...
    - tptacek 15y ago
      I don't know how to respond to the argument that it's "vastly easier" to chill a bank of RAM with inverted compressed air cans or liquid nitrogen and then extract its entire contents than it is to just use a debugger to watch a program run. I guess "No, I don't agree." suffices.
SageRaven 15y ago
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. 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.
newman314 15y ago
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. That said, does anyone know of recent ARM optimizations for OpenSSL or other SSL implementations?
jnau 15y ago
Anyone know if this can be applied on Mac OS X Lion?
- LeonidasXIV 15y ago
  Trevisor yes, because it runs below the OS and the recent MBAs provide AES-NI, if I remember correctly. Without the hypervisor you're out of luck, as it needs to to patch the kernel and Apple is extremely unlikely to do that.
aw3c2 15y ago
This was presented at the 28C3. http://events.ccc.de/congress/2011/Fahrplan/events/4869.en.html http://events.ccc.de/congress/2011/Fahrplan/events/4869.en.h... Recordings are available at http://mirror.fem-net.de/CCC/28C3/ http://mirror.fem-net.de/CCC/28C3/
dfox 15y ago
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. 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).

35 points by blasdel 15y ago

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. 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?

munin 15y ago
> What's not to like? you need to patch your kernel to use it. this isn't something that openssl alone can push.
- loeg 15y ago
  So TRESOR needs to submit an acceptable patch to the nice kernel.org folks, and then it can ship as a distro default.
  - lukeschlather 15y ago
    It sounds fairly cpu-specific. I'm not sure it would lend itself very well to being packaged up for general distribution.
    - JoshTriplett 15y ago
      Linux takes CPU-specific patches all the time, and has numerous modules to take advantage of CPU features. As long as the patch gives it a clean interface and meets the Linux kernel's standards, I don't see any major roadblock. 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).

listening 15y ago

Registers. Love 'em. Where's the BSD version?

macrael 15y ago

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.

bri3d 15y ago
On most platforms, mlock(2) and mlockall "lock" data in memory, theoretically preventing it from being paged to disk. 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).
tptacek 15y ago
It is, but keep in mind that on general-purpose computers running AES, if you can extract secrets from virtual memory, you are already in a position to wiretap the AES process directly.
- bri3d 15y ago
  A cold-boot attack as detailed in [0] makes it vastly easier to extract secrets from physical memory than to wiretap the AES process, especially if you're not in possession of a privileged user account or a route into kernel space. [0]: http://citpsite.s3-website-us-east-1.amazonaws.com/oldsite-htdocs/pub/coldboot.pdf http://citpsite.s3-website-us-east-1.amazonaws.com/oldsite-h...
  - tptacek 15y ago
    I don't know how to respond to the argument that it's "vastly easier" to chill a bank of RAM with inverted compressed air cans or liquid nitrogen and then extract its entire contents than it is to just use a debugger to watch a program run. I guess "No, I don't agree." suffices.

SageRaven 15y ago

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. 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.

newman314 15y ago

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. That said, does anyone know of recent ARM optimizations for OpenSSL or other SSL implementations?

jnau 15y ago

Anyone know if this can be applied on Mac OS X Lion?

LeonidasXIV 15y ago
Trevisor yes, because it runs below the OS and the recent MBAs provide AES-NI, if I remember correctly. Without the hypervisor you're out of luck, as it needs to to patch the kernel and Apple is extremely unlikely to do that.

aw3c2 15y ago

This was presented at the 28C3. http://events.ccc.de/congress/2011/Fahrplan/events/4869.en.html http://events.ccc.de/congress/2011/Fahrplan/events/4869.en.h... Recordings are available at http://mirror.fem-net.de/CCC/28C3/ http://mirror.fem-net.de/CCC/28C3/

dfox 15y ago

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. 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).