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!


  • 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. " Aug 21, 2012 at 9:51
  • 2
    Use case: it knocks on the door. Current situation: you can shut down but it takes 5 minutes until encryption goes effective (risk of cold boot attack). With a RAM wipe script: press the panic button and everything is almost instantly secure. When the script is ready it could easily be expanded, go active when removing an USB drive. That could even work if someone robs a notebook, if the victim is fast enough to remove the USB drive. Aug 21, 2012 at 11:25
  • 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, 2012 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, 2012 at 14:19
  • 6
    You know, this degree of paranoia will only make the black helicopter guys that much more interested in you. Aug 21, 2012 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.

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.

  • 1
    I found another paper from 2010. dtic.mil/cgi-bin/GetTRDoc?AD=ADA545078 [PDF] Some bits are also about DD3 but it definitively does not say DD3 is safe against this attack. Aug 21, 2012 at 16:48
  • 2
    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. Aug 21, 2012 at 17:50
  • 2
    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. Aug 21, 2012 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. Aug 21, 2012 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, 2012 at 19:15

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.

  • 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, 2012 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, 2012 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, 2012 at 15:14
  • Marvelous. Thank you very much for the link. It will be an interesting lecture.
    – mnmnc
    Aug 23, 2012 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. Aug 23, 2012 at 20:52

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.


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.

  • I always thought about thermite here :-) Aug 29, 2015 at 18:24
  • 1
    Thermite is indeed a nice solution... Easy to ignite and impossible to stop the reaction. You just need to make a safe activator circuit... Because if it starts the reaction by accident, you'll have a really hard time. Sep 8, 2015 at 19:17

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.

  • any claim to support ram holds the aes key? Oct 3, 2013 at 11:27
  • This shows you do not understand how ram works, you also need to have a ram controller to refresh it every N ms to retain the data.
    – Geoffrey
    Jul 24, 2015 at 11:41

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:


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

enter image description here


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.

  • 3
    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. Aug 21, 2012 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, 2012 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. Aug 22, 2012 at 0:54
  • 1
    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. Aug 22, 2012 at 1:02
  • 1
    @JamesMitch "you won't find a research paper claiming that the situation improved because of DDR 3" maybe you will not find any paper but i think if TrueCrypt authors claims to be that way - we can trust. Take a look in here: truecrypt.org/docs/?s=unencrypted-data-in-ram and read the first asterisk * at the bottom. Quote: "New types of memory modules allegedly exhibit a much shorter decay time (e.g. 1.5-2.5 seconds) than older types (as of 2008)." That means that since 2008 somethings have changed in RAM...
    – mnmnc
    Aug 22, 2012 at 6:30

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

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