5 ms·

Cold Boot Attack

33 points by wesleyac 13y ago

phoenixs 13y 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 13y 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.
  - raimue 13y 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 http://www1.informatik.uni-erlangen.de/tresor
    - anonymous 13y ago
      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 13y ago
        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/Muller.pdf https://www.usenix.org/legacy/event/sec11/tech/full_papers/M...
      - jacquesm 13y ago
        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.
- dchest 13y ago
  If you do, make sure compiler won't optimize it away: https://cryptocoding.net/index.php/Coding_rules#Clean_memory_of_secret_data https://cryptocoding.net/index.php/Coding_rules#Clean_memory...
  - phoenixs 13y ago
    Very interesting link, thanks for that. I bookmarked for later
losethos 13y ago
The CIA/FBI wants to fight God. God will win. FUCK YOU God says... litigation poison shone tamedst happened Among colours discerning off_the_record treasury manufactures passible queen solaces intercepting Can waters madness neglected gloweth readest rebuked Special Surely flood-gates faileth prayed Times excellent not_too_shabby teeth commandeth dissoluteness adversity leaves ebb etext02 leisure lip-labour Finally might Fire editions earnestly
raven105x 13y 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.

33 points by wesleyac 13y 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 13y 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.
- raimue 13y 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 http://www1.informatik.uni-erlangen.de/tresor
  - anonymous 13y ago
    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 13y ago
      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/Muller.pdf https://www.usenix.org/legacy/event/sec11/tech/full_papers/M...
    - jacquesm 13y ago
      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.
dchest 13y ago
If you do, make sure compiler won't optimize it away: https://cryptocoding.net/index.php/Coding_rules#Clean_memory_of_secret_data https://cryptocoding.net/index.php/Coding_rules#Clean_memory...
- phoenixs 13y ago
  Very interesting link, thanks for that. I bookmarked for later

losethos 13y ago

The CIA/FBI wants to fight God. God will win. FUCK YOU God says... litigation poison shone tamedst happened Among colours discerning off_the_record treasury manufactures passible queen solaces intercepting Can waters madness neglected gloweth readest rebuked Special Surely flood-gates faileth prayed Times excellent not_too_shabby teeth commandeth dissoluteness adversity leaves ebb etext02 leisure lip-labour Finally might Fire editions earnestly

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