Cold Boot Attack | Hacker News Reader

Cold Boot Attack

en.wikipedia.org

33 pointswesleyac9 comments

I always wondered if I should memset() things after im done with them, maybe I'm not being completely paranoid on this one.

Scary and amazing.

This would not fundamentally solve the issue, just reduce the attack surface, since the RAM needs only to be in state before memset() for attack to success. A better approach would be to encrypt at least the sensitive area even in RAM and never store plain-text value of a key.

On the side note Mac Books unexpectedly turned out to be partly resistant to this attack because of integrated nature of elements.

If you are talking about normal user space applications, any encryption key would be in RAM as well, so this would be useless.

As a more advanced example for measures against cold boot attacks, the research project TRESOR provides a patch for the Linux kernel that enables you to keep the encryption key for your hard disk in CPU registers all the time, without ever leaking them to RAM.

http://www1.informatik.uni-erlangen.de/tresor

Presumably at some point the kernel will have to do a context switch and subsequently store the contents of those registers in ram.

Perhaps the solution could be a small usb dongle containing an embedded arm soc with a kind of RAM that doesn't persist at all -- maybe even no RAM at all, just the cpu. The dongle would support just three commands: init, encrypt, decrypt. Init sets the key and algorithm, after which the device doesn't let you change them until the system is powered off. En/decrypt do block-level crypto.

No, the AES encryption key really never leaves the CPU, that is the whole point here.

TRESOR uses the four x86 debug registers to store a 128 or 256 bit key and then uses this key to calculate the AES round keys on-the-fly on each block of encryption using Intel AES-NI instructions. Also, they patched the kernel not to touch these registers at all. Therefore, after the initial loading of the encryption key, it never leaves the CPU again.

This approach also means you cannot use the ptrace(2) syscall anymore to attach to a program using a debugger such as gdb. However, if you don't want to debug a program, this proof-of-concept already works quite nice.

I noticed the PDF link to the paper on their site is broken, so please see the USENIX publication for details: https://www.usenix.org/legacy/event/sec11/tech/full_papers/M...

In a nutshell: the debug registers are not part of the set that ends up in the saved tss after a context switch, and accessing them is a privileged operation so after a cold boot (assuming the original source of the keys was wiped) there should be no trace of them in RAM.

If you do, make sure compiler won't optimize it away:

https://cryptocoding.net/index.php/Coding_rules#Clean_memory...

Very interesting link, thanks for that. I bookmarked for later

CIS/CS major here - any particular reason we don't yet store encryption keys in L3 CPU cache? From my (basic, and quite possibly flawed) understanding, this would invalidate the possibility of cold-boot attacks entirely. The average modern processor has 2-16MB of L3 so a few 2048/4096 keys for an application such as TrueCrypt couldn't possibly dent performance that much.

Reply on news.ycombinator.com