Wipe RAM on shut down to prevent Cold Boot Attack

Question

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/

Answer 1

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.

Answer 2

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.

Answer 3

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.

Answer 4

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.

Answer 5

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.

Answer 6

What no-one else has mentioned yet is that 0xPoly on GitHub coded a Linux/OSx tool for this 6 years ago. It's called Centry. From the page we have features:

Features

• User-friendly GUI interface
• When in panic mode, Centry can:
  • Lock the screen
  • Unmount all Truecrypt disks and clear the password/keyfile cache
  • Write zeros to RAM using sdmem (on UNIX-like systems)
  • Force an ACPI shutdown (equivilent holding down the power button)
  • Propogate the panic signal to all other nodes in the network
• Settings to improve security on ECC-enabled systems
• Extensively customizable
• Compatable with Linux and Mac OS; with significantly more security in Linux.

Answer 7

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.