

Tresor Runs Encryption Securely Outside RAM - there
http://www1.informatik.uni-erlangen.de/tresor/

======
JoachimSchipper
Cool hack.

Context: cryptographic keys are usually stored in memory, but that has lots of
issues: you can read the keys via a Firewire port (or any other peripheral
with Direct Memory Access), or you can time the CPU cache to figure out access
patterns, or you can just rip the memory out of the system and read it ("cold-
boot attack").

The proposed hack: store the AES key in the debugging registers of an x64
chip, and use the recently introduced AES-NI instructions. This obviously
renders the debugging registers unusable (which makes gdb slow), and can only
hold a single key, but may well _work_ \- I don't know of any attemps to
extract data from registers, but recent CPUs are very finely-built devices.

This doesn't necessarily solve every side-channel attack, and, again, can only
hold a single key; but it _is_ a cool hack.

Note: the above is based only on a quick reading of this paper; the DBLP paper
database has no hits for DBLP, which suggests that this scheme hasn't exactly
been carefully vetted - indeed, the paper will be presented at Usenix, held in
a week or two.

~~~
kylemaxwell
It's really interesting to see this, as I've had concerns for a while now
about keys getting read from memory (while helpful in incident response).
Though I wonder if sufficiently privileged processes might not be able to read
those registers?

~~~
tptacek
Userland processes can't directly read the debug registers.

~~~
JoachimSchipper
Absolutely. Then again, assuming that you can't get from root to kernel on a
Linux box seems somewhat optimistic. Still a cool hack, though.

------
dfox
Cool hack, but probably not useful.

While it's not widely documented, you can be almost certain, that any
architecturally visible state of almost any modern processor (for i386 that
means 80486 and up) can be easily read out by JTAG or some other debug
interface. So this actually makes attacker's job easier (no wide and fast
parallel interfaces, no need to inject code). Also note that state of debug
registers is undefined after reboot, which could in many implementations mean
that they retain their contents.

------
Havoc
"Tresor" is German for safe (as in the noun).

------
mmaro
If the attacker has enough physical access to pull out your memory, I doubt
they'll be very disappointed by AES-in-CPU-only protection. They're still
getting 8-32GB of other private data (passwords, everything in your page
cache, etc). The real solution is to physically protect your computer.

~~~
tptacek
I think the point is, AES is what you normally use to protect those 8-32GB of
data, and there are well-known attacks that subvert AES when your attacker
gets access to the hardware.

"Physically protecting your computer" is kind of a non-statement. Computers
get stolen, full stop.

~~~
mmaro
Computers get stolen, but they're usually already off, or turned off during
the theft. But let me get this straight: you're worried about an attacker
reading out everything on your hard drive, but not worried about them reading
out all the unencrypted stuff in RAM? I'm not against disk encryption, I just
don't see the point of this specific protection.

Edit: now that I think of it, if a company laptop with customer data had full
disk encryption and was stolen, do you still have to notify everyone? Does it
matter whether it was off or on/suspended? Maybe people will be relieved when
they find out that "8GB of data was probably not stolen" (with AES-in-CPU-
only) instead of "300GB of data was probably not stolen".

~~~
JoachimSchipper
"Sleeping" laptops get stolen too; this might slightly help. That said, this
is a cool hack, not the greatest protection ever.

Full-disk encryption (on a machine turned off at the time) is, I believe,
typically considered sufficient protection. Consult a lawyer in your local
jurisdiction, though.

~~~
gst
That's my main reason for using suspend-to-disk instead of suspend-to-ram.

With suspend-to-disk Linux allows me to save the RAM image to the encrypted
harddisk. With suspend-to-ram it would be pretty easy to work around the
encryption.

~~~
tptacek
Right, but suspend-to-disk doesn't really mitigate cold boot attacks, because
in order to suspend your data to disk, an AES key is loaded into DRAM. The
"cold" in "cold boot" refers to the tricks researchers use to extract data
from DRAM even after reboot.

The point of this research is that there aren't (that we know of) "cold
register" attacks that extract prior contents of CPU registers.

~~~
gst
Right, cold boot attacks would also apply to suspend-to-disk. But currently I
do not really worry about this scenario, as it seems that cold boot attacks
are only feasible if you get access to the hardware within several minutes
after it has been powered down.

~~~
tptacek
Sure. If you don't care about cold-boot attacks, you don't care about this
research. I think it's interesting, but it doesn't keep me up at night.

------
gst
Similar ideas have been around for quite some time:
<http://frozencache.blogspot.com/>

~~~
tptacek
That's an interesting link too.

The difference between those ideas is that "Frozen Cache" plays games with the
CPU cache to attempt to keep keys entirely in cache and out of DRAM, where
TRESOR runs AES entirely out of registers. The downside of the "Frozen Cache"
approach is that X86 doesn't give you enough control over the cache to provide
assurance that keys aren't touching RAM.

------
edoloughlin
I must be missing something here: how does the key get into the registers?

