Tresor Runs Encryption Securely Outside RAM(www1.informatik.uni-erlangen.de)
www1.informatik.uni-erlangen.de
Tresor Runs Encryption Securely Outside RAM
http://www1.informatik.uni-erlangen.de/tresor/
7 comments
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?
Userland processes can't directly read the debug registers.
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.
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.
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.
"Tresor" is German for safe (as in the noun).
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.
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.
"Physically protecting your computer" is kind of a non-statement. Computers get stolen, full stop.
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".
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".
"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.
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.
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.
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.
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.
The point of this research is that there aren't (that we know of) "cold register" attacks that extract prior contents of CPU registers.
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.
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.
Offtopic: Btw, does someone know why the "reply" links are missing on some posts (such as the parent post)? Is this a bug? At least it works when "manually" opening the respective URL for a reply.
There is a deliberate delay on replies in deeply-nested threads, as a damper on flame wars.
You can still reply via the 'link' button, though.
This likely has particular applications rather than in general purpose computing. I will certainly agree, however, that a number of practical and implementation issues will arise in specific use cases. At the moment, I see it as sort of a proof of concept rather than something that people will rush out and integrate into existing code.
Similar ideas have been around for quite some time: http://frozencache.blogspot.com/
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.
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.
I must be missing something here: how does the key get into the registers?
[deleted]
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.