Cold Boot Attack

https://en.wikipedia.org/wiki/Cold_boot_attack

by wesleyac • 13 years ago

33 9 13 years ago

en.wikipedia.org

phoenixs2• 13 years ago

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.

cLeEOGPw• 13 years ago

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.

raimue2• 13 years ago

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

dchest• 13 years ago

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

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

phoenixs2• 13 years ago

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

raven105x• 13 years ago

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.

Cold Boot Attack

Related Stories