3 ms·
Tresor Runs Encryption Securely Outside RAM
- JoachimSchipper 15y agoCool 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 15y agoIt'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 15y agoUserland processes can't directly read the debug registers.
- JoachimSchipper 15y agoAbsolutely. Then again, assuming that you can't get from root to kernel on a Linux box seems somewhat optimistic. Still a cool hack, though.
- deleted 15y ago[deleted]
- mmaro 15y agoIf 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 15y agoI 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 15y agoComputers 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".
- cheez 15y agoBecause chances are that they'll be stolen by a guy who dropped out of high school and hasn't had a regular job in years. If a three or four letter agency is coming after me, I have bigger problems.
- tptacek 15y agoYes: if you don't care about cold-boot attacks, you don't care about this research.
- Havoc 15y ago"Tresor" is German for safe (as in the noun).
- gst 15y agoSimilar ideas have been around for quite some time: http://frozencache.blogspot.com/ http://frozencache.blogspot.com/
- tptacek 15y agoThat'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 15y agoI must be missing something here: how does the key get into the registers?
- dfox 15y agoCool 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.