Take the 2-minute tour ×
Super User is a question and answer site for computer enthusiasts and power users. It's 100% free, no registration required.

My system is encrypted using Full Disk Encryption, i.e. everything except /boot is encrypted using dmcrypt/luks. I am concerned about Cold Boot Attacks, where researchers demonstrated, that content could be extracted for about 5 minutes.

Can you please provide instructions on:

  • how to trigger kexec into a new kernel at the very last steps of the shutdown/reboot process (to ensure clean dismount, to prevent file system corruption, to ensure the old kernel gets overwritten)
  • how to create that kernel, which wipes all the ram

i.e. Can you explain please, how to do the same on Ubuntu?

How to detect the shutdown? How to start the RAM Wipe? The RAM should be wiped upon the user clicks "shutdown" or if he starts a "panic script".

Thanks for your efforts!

Prior work:

If you want to see the feature become reality, vote on Ubuntu Brainstorm!

http://brainstorm.ubuntu.com/idea/30076/

share|improve this question

migrated from security.stackexchange.com Aug 21 '12 at 9:45

This question came from our site for Information security professionals.

6  
How do you intend to detect the "shutdown"? The power is simply gone, not much you can do about that in software. And since the attacker has physical access, relying on an USV is problematic. To quote the wikipedia article you linkes: "To execute the attack, the machine is cold-booted. Cold-booting refers to when power is cycled “off” and then “on” without letting a computer shut down cleanly, or, if available, pressing the “reset” button. " –  CodesInChaos Aug 21 '12 at 9:51
1  
Detect shutdown? User clicks "shutdown" or clicks a panic button. I'll add the clarification to the question. –  James Mitch Aug 21 '12 at 11:05
4  
Tell us if you have a RAM DDR2 or DDR3. DDR3 are immune to Cold Boot Attack. They only keep voltage for couple of seconds after forced power off. If you here knocking then pull the plug. If you have older RAM - i would enable TWO things in BIOS - 1. AutoStart after Power loss to last known state. 2. Ram size Check at each boot. This will allow you to Pull the plug, plug it back and go to door while your BIOS will clear the RAM for you and load System after that. This is quicker then you will ever need. –  mnmnc Aug 21 '12 at 13:56
4  
It's 2012. There is no Cold Boot Attack anymore unless you are using 10 year old laptop. If i would want to get to your encrypted data i would exploit the system security hole or send you a trojan horse to get your data for me. The same would be done by State agencies. Breaching the door and attempting CBA is too risky in light of currently available encryption algorithms. It would be enough to have a not common screws in your box and anyone attempting CBA would leave empty handed after you pulling the plug. –  mnmnc Aug 21 '12 at 14:19
4  
You know, this degree of paranoia will only make the black helicopter guys that much more interested in you. –  Daniel R Hicks Aug 21 '12 at 17:43

7 Answers 7

If you are not using old RAM like DDR2, 512 MB or 1024 MB then you should not be worried about CBA.

Take a look at original Research here (PDF).

If you will read it carefully, you will find that only DDR2 and older are prone to this attack. DDR3 lose voltage too fast to allow computer case dismount and freeze procedure. So simply pull the plug before answering the door.

If in fact you want to secure yourself because you have DDR2 RAM then enable in BIOS:

  1. Autostart after Power loss
  2. RAM check at boot time

and do the same as with DDR3 but after pulling the plug, plug it back in. Your computer will start itself and wipe the ram by checking it. If it will not wipe efficiently enough, the boot process will load the system to the RAM again. It will be far too quick to allow for CBA.

From the link you provided in comments:

Therefore, in conclusion, the cold boot attack should not be viewed as the primary method for acquiring a suspect computer system’s memory. Instead, other techniques including both software and hardware-based acquisition (i.e. FireWire) should be attempted prior to carrying out a cold boot attack against said system. However, should a situation occur where the aforementioned techniques are either not available (i.e. lack of FireWire connection or system login console or remote memory acquisition is not possible) or are ineffectual, then the cold boot attack may be administered assuming that the investigator understands both how and where problem may arise and go awry.
As this study has shown, the cold boot attack cannot be established as being particularly forensically sound or reliable since in most of the experiments conducted herein memory-resident encryption keys could not be consistently found or extracted although they should have been. The same can also be said for the various strings and keyword searches which should have turned up far more strings and keywords than were found for most of the experiments. Moreover, as has been demonstrated, merely the act of flash-freezing computer memory does not guarantee the successful acquisition of said memory. Other factors and variables already examined have fully examined these issues and their underlying causes. Thus, it is the opinion of the authors of this study that the cold boot attack can be useful in some cases to acquire a suspect system’s memory but that this method should not be considered a panacea and instead should be used as a last resort when all other avenues have been exhausted.
Finally, even a successful acquisition which has suffered little to no degradation will likely not stand up in a court of law as sound evidence, at least until jurisprudence has occurred and the integrity of the acquired memory can be demonstrated to be intact using a sound and understandable methodology. The search continues to establish a more proper and reliable way of acquiring the memory of a suspect’s computer...

Also if you check the experiment results, you will realize that they successfully extracted the AES keys only in the system 2 and 6 and those were Warm Boot Attacks when you look at the specs of system 2 - 1024 MB RAM 533 MHz - this is old stuff. The other system - system 6 with 256 RAM / 128 RAM - I guess this one is self explanatory.

This is exactly why their conclusion was:

The search continues to establish a more proper and reliable way of acquiring the memory of a suspect’s computer...

Actually i believe that if you have very very very important data you should not only use Full Drive Encryption but also keep it in a separate encrypted file. Encrypted with cascade algorithms and a different password then the one used during disk encryption. You want a secure way of shutting down the PC? Here it is:

  1. Keep secure data in True Crypt cascade algorithm encrypeted file
  2. Use Serpent
  3. Create a script to handle shutdown:

For Windows:

truecrypt.exe /wipecache
shutdown -s -f -t 1

For Linux:

truecrypt /wipecache
shutdown -h now

Wipecachce ensures that no vulnerable data remains in RAM after shutdown. If someone will perform Cold Boot Attack they will have access to your System at best. They will not have data stored in a separately encrypted file.

share|improve this answer
1  
I don't go with this conclusion. This question was not about avoiding law enforcement. In fact it kills the discussion if the question is about evading law enforcement. Let's not talk about law enforcement. Lets talk about industrial espionage.Someone who has 4 or 16 GB RAM or more and was working one some expensive, important documents, sketches, source code, etc. He will be happy if the encryption keys can not be extracted but can still loose a lot money if his documents are stolen from RAM. –  James Mitch Aug 21 '12 at 17:50
1  
While I hate to clarify the use case... Information is not about being accepted in court as a proof or not. Also other people have legitimate reasons to wipe their RAM. Law enforcement wants to hide witness-protection program. Secret service wants to hide their intelligence. Industry wants to hide their business secrets. If the encryption key is safe, fine. The rest of the data still wants to be safe, even bits of it. My original question remains open. –  James Mitch Aug 21 '12 at 17:54
1  
I could construct more use cases where people travel etc... Many people encrypt their drives and if they were aware that parts of their RAM could be reconstructed they'd prefer to take action to prevent that.If you search a bit old discussions on Google, you'll find out that most people are not aware that RAM contain(ed) data after power got cut. If disk encryption could be substituted with physical security people wouldn't bother with disk encryption. Both concepts encryption and physical encryption have their right to exist. Security is always only working on bits. This one is a missing bit. –  James Mitch Aug 21 '12 at 18:32
1  
Well, yes i agree. The level of knowledge among the people is poor. But you won't be able to incorporate the solution that will make them safer. security requires dyscypline. Average Joe will not use Full Disk Encryption because he is afraid someone will stole his credit card number. If you have a fragile data that you want to be absolutely safe - use Truecrypt to create an encrypted file - do not encypt the drive as a whole. Truecrypt has a swich 'wipe' which removes permanently keys from RAM memory by overwriting it. You can place it in a shortuct. Do not hunt flies with cannon. –  mnmnc Aug 21 '12 at 19:15
1  
1. You must encrypt whole system, otherwise registry, temporary files and swap can contain sensitive data. 2. "master keys used for system encryption cannot be reliably (and are not) erased from RAM when a computer hibernates, is shut down or restarted" source: truecrypt.org/docs/?s=unencrypted-data-in-ram 3. TrueCrypt full disk encryption is only available for Windows. This was a Linux question. 4. This would only wipe the encryption key. The documents you worked on before may still be retrieved from RAM. –  James Mitch Aug 23 '12 at 11:49

I would imagine memtest86 would be pretty good at wiping RAM. I've always wanted to try the below but haven't. If I do try it I will update it.

Read the kexec man page. And don't try to kexec the .iso, but you need to unpack the iso and snag the bootable binary. On the memtest86 site above you can just download the binary.

You have to use a kexec command to load what you're booting into first.

So I think what you can do is:

kexec -l {path-to-memtest86-bootable-binary} --append=console=ttyS0,115200n8

and when you are ready to pull the trigger:

kexec -e

I'm thinking (but could be wrong) that the --append=console=ttyS0,115200n8 gets memtest86 to work over the serial port. So if you have one you can verify it is working even if it does not show up on video output, which is a possibility since memtest86 doesn't perform video initialization. Killing any running instances of X is probably a good idea.

The Debian kexec-tools package (also available on Ubuntu) hooks this into the shutdown scripts, so if you edit /etc/default/kexec you can tell the shutdown process to invoke kexec as the final thing instead of rebooting. That is, if you are interested in a clean shutdown.

In an emergency, a sync; kexec -e would work.

However, it's possible some chipsets, once they are initialized, cause lockups to happen if certain areas of memory are addressed. I don't know how this would work in practice.

A good compromise if kexec does not work is to install memtest86 to your bootloader, put it as the default boot item, and have a 1 second delay until automatic choosing (or no delay and rely on a keypress to bring up the memu). This could get you into memtest86 from a "fresh-boot" condition fairly quickly, but not instantly.

Note that this does not account for video RAM. A solution for that is to setup your video RAM as a block device, and output /dev/random to the block device for a few iterations.

share|improve this answer
2  
Looked into it and google and so on. According to tails.boum.org/bugs/sdmem_does_not_clear_all_memory/… there is one remaining issue with memtest: "There is still a small amount of memory not wiped." Thanks anyway, the kexec stuff looks useful and easy. –  James Mitch Aug 21 '12 at 19:00

Sorry, but you are being paranoid. First, as other users indicated, apparently the Cold Boot Attack only works on older hardware.

If you still think that it is a threat, wiping is not the solution.

The Cold Boot Attack involves:

  • cold booting the machine
  • booting a lightweight OS to scavenge the encryption keys from memory

If someone manages to perform the cold-boot then obviously your wiper won't have the opportunity to run. So it makes no sense to install one.

This is the main case of the attack. Let's now assume that the attacker doesn't want to cold-boot herself the running server (e.g. because that would trigger a monitoring alert), instead she waits to perform the attack within 5' of a clean shutdown. In this case:

  • A generic RAM wiper won't do you any good either. Since the attacker is assumed to be physically present in order to power-on the machine and scavenge the keys, she can also cold boot the machine just before the wiper starts running. (Monitoring alerts at this point are expected.)
  • A specialized program that first wipes the exact location of the FS encryption keys before wiping the rest of the RAM (e.g. truecrypt /wipecache mentioned by mnmnc) could make attacker's job more difficult. Still:
    • The attacker would still be able to scavenge some of the RAM contents by not letting the wiper run through the whole RAM. But at least the bulk of the data on the FS would be safe.
    • The solution would not be 100% foolproof - it only makes it harder for the attacker to time the cold-boot.

So, if you are really worried about this attack, I'd suggest that you learn kung-fu and stand guard for 5' next to the machine each time you shut it down. Or maybe use a boot password in your BIOS? Both the suggested measures do not need to be 100% effective: attackers may still beat you and read the BIOS password from your MB using technical means. You just need to delay them for 5' so that the attack time-window expires.

Finally, if you are worried about someone performing the whole feat remotely, you are already pwned hard.

share|improve this answer
2  
That it works only on older hardware is unproven. I posted this in a security forum! Paranoid or not. If you have nothing constructive to add, don't reply. Let the paranoid people discuss their paranoid stuff. There are a lot people discussing this, I am going to add a few more links to the original question. –  James Mitch Aug 21 '12 at 19:31
    
What you mean nothing constructive? I detailed you how memory wiping is an inefficient countermeasure for this attack. People discussing your proposal to wipe the memory does not make it a valid countermeasure to the attack. To be frank it is technically intriguing to add this wiper, but just for the sake of it. Not because it will prevent the cold boot attack. –  m000 Aug 21 '12 at 19:37
    
"The Cold Boot Attack involves: cold booting the machine" > Wrong. Ram gets removed and cooled with dry ice.; "booting a lightweight OS to scavenge the encryption keys from memory" > Wrong. After RAM got cooled it can be examined in another machine. Just look into the original question, there is a link to the demonstration with the dry ice. –  James Mitch Aug 22 '12 at 0:54
    
About the DDR2 vs DDR 3 thing: you won't find a research paper claiming that the situation improved because of DDR 3. That's just an unproven claim. Mail the research paper authors, they won't tell DD3 is more secure. –  James Mitch Aug 22 '12 at 1:02
    
Let's imagine for fun we already have a panic script, which can wipe the full RAM. The user could sit somewhere in public, a bar or even at home with his notebook. The moment the notebook gets robbed he pulls a trigger. A trigger could be a remote button, react on shaking or a USB pendrive could be plugged into the notebook connected by string to his arm. One way or another, when the notebook is robbed, RAM gets wiped and notebook powers off. Cold boot attack with dry ice is completely defeated. –  James Mitch Aug 22 '12 at 1:08

Peter A. H. Peterson at UCLA wrote a proof of concept technology and developed the theory for securely running your system with encrypted RAM, and the solution is expressly designed to prevent cold boot attacks. The name of his paper is Cryptkeeper. I don't know if he makes the software available for download or if it is possible to license it from UCLA. However, it is apparently possible, at least in principle, to design a cryptosystem for RAM that is secure even if the entire contents of RAM is disclosed.

The measured performance impact of this solution is between a 9% overhead and a slowdown by a factor of 9, depending on how "pathological" the scenario is. The 9% figure is cited as applying to browsing the web with Firefox, but they didn't state what use case would slow down the performance by a factor of 9.

Peterson's solution does not "wipe" the RAM as you suggest. Rather, it uses a "secure key-hiding mechanism" to prevent the decryption key from being disclosed just by virtue of obtaining the contents of RAM. I am not sure of the details of the implementation, but I assume it is explained in the paper.

The paper was published in 2010.

It is available for purchase on IEEE's ieeexplore website. It is also available for direct download as a PDF without charge from someone's website; it is up there on the google search results for "cryptkeeper RAM"... but I'm not sure how long that result will stay up there.

I was tempted to make this a comment rather than an answer, because this solution does not "wipe" RAM as you asked. However, I believe that if Peterson's research is technically correct, this will have the same practical effect -- or possibly even a "better" effect -- than wiping the RAM. The reason is that a skilled physical attacker could probably interrupt your system program's attempt to wipe the RAM if they were expecting such an operation to occur -- for example, pulling the battery out of the unit or holding down the power button before the operation can complete. Peterson's solution is more secure because it is not based upon a necessary time window under which the computer is permitted to continue executing instructions in order to complete the wipe. Instead, memory is constantly protected, even if the CPU itself is instantaneously killed by some incredible feat of technology before you even have a chance to react to the attacker.

And by "incredible feat of technology" I mean something like Stuxnet.

share|improve this answer
    
Great find. Definitely +1 from me. But unavailable for confirmation - you need to pay to read the document. Personally i wouldn't trust it - while it is not commonly used it will most likely have implementation bugs all over it. I would feel like building a steel-concrete wall in front of my house while not having even a fence at the back side of it. –  mnmnc Aug 23 '12 at 14:37
    
On the other hand, the fact that it's not commonly used makes it less likely to be known to attackers. It's constantly a cat and mouse game between attackers and defenders. The best possible solution is to have a truly robust security system that ALSO benefits from obscurity / unknown-ness. If you can't have that, the second best solution is to have a well-known, publicly-tested solution that is also robust, like TLS. This one isn't widely employed like TLS, so we don't know yet if it is robust. Hm. Schroedinger's Cat or Heisenberg Uncertainty type problem. –  ÃŁŁǫǛȉЖΦΤїҪ Aug 23 '12 at 15:11
1  
Also, for your information, the top google result for "Cryptkeeper RAM" is a direct download PDF of this graduate researcher's paper, available directly from his own website. His nickname is apparently Pedro and it's hosted on his tastytronic.net domain. See here and here. So that tells me he put the paper on his own website of his own free will, and it's thus public domain? Or at least publicly accessible with a "shhhh don't tell IEEE" ;-) –  ÃŁŁǫǛȉЖΦΤїҪ Aug 23 '12 at 15:14
    
Marvelous. Thank you very much for the link. It will be an interesting lecture. –  mnmnc Aug 23 '12 at 15:53
    
Yes, interesting and perhaps more secure than wipe RAM. Unfortunately even more unrealistic to get. Therefore I'd be happy also getting an answer to the original question. Not perfect, but good stopgap. Thanks for sharing. –  James Mitch Aug 23 '12 at 20:52

If you want to see the feature become reality, vote on Ubuntu Brainstorm!

http://brainstorm.ubuntu.com/idea/30076/

share|improve this answer

The problem is if your computer is running and the screen is locked. At this point, the AES key is stored in RAM, and the user is away from the computer. An intruder could open the computer case and remove the RAM modules, while keeping them powered, and placing them in a separate device that reads their content. There is no need to shut down the system or freeze the modules before extraction. RAM is not trustable to hold the AES key, but the processor's cache is, like the solution named TRESOR. Unfortunately that requires an old Linux kernel, and advanced knowledge of patching and compiling the kernel.

share|improve this answer
    
any claim to support ram holds the aes key? –  BlueBerry - vignesh4303 Oct 3 '13 at 11:27

This is an old question but I think I can contribute. As said before, a software-based memory wipe isn't the best solution, simply because the power can be suddenly cutted-off, so the wipe software will not be executed.

I can imagine the best scenario to illustrate the problem: You run illegal business on your computer in your home. One day, the electric power suddenly disappear, and then a FBI squad storms the door of your house, arrest you and then a nerd technician quickly opens the case of your computer and use inside it a cold gas to freeze the memory state to buy some time to do a Cold Boot Attack.

So, the best way to solve this problem is to make the computer case safer, by making it difficult to open (something like a vault), or even destroying the memory by heating the board using a battery-powered resistance, ignited by a tamper switch in the case. Few seconds at high temperatures can destroy the data, or even destroy the chips, witch isn't a big problem in this situation.

share|improve this answer

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.