Wipe RAM on shut down to prevent Cold Boot Attack

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:

• Tails RAM Wipe introduction
• Some more information about tails RAM Wipe implementation
• Liberte Linux RAM Wipe introduction
• More implementation details about Liberte Linux RAM Wipe implementation
• memtest not deleting everything
• Test if RAM Wipe is working
• Tails mailing list discussion
• Another Tails mailing list discussion
• Kernel bug report

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

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

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.

Also, this paper confirms that DDR3 is not susceptible to a CBA. 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

Wipe cache 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.

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.