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

[gst]

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.

[cheez]

Because 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]

Yes: if you don't care about cold-boot attacks, you don't care about this research.

[kylemaxwell]

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.