Tresor Runs Encryption Securely Outside RAM
www1.informatik.uni-erlangen.de
www1.informatik.uni-erlangen.de
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.
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.
"Physically protecting your computer" is kind of a non-statement. Computers get stolen, full stop.
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".
If a three or four letter agency is coming after me, I have bigger problems.
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.
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.
The point of this research is that there aren't (that we know of) "cold register" attacks that extract prior contents of CPU registers.
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.