

Cold Boot Attack - wesleyac
https://en.wikipedia.org/wiki/Cold_boot_attack

======
phoenixs
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
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.

~~~
raimue
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](http://www1.informatik.uni-
erlangen.de/tresor)

~~~
anonymous
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.

~~~
raimue
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...](https://www.usenix.org/legacy/event/sec11/tech/full_papers/Muller.pdf)

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

