Unix & Linux Stack Exchange is a question and answer site for users of Linux, FreeBSD and other Un*x-like operating systems. Join them; it only takes a minute:

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

How can I encrypt my system (at best using lvm + dm-crypt/luks) such that suspend to RAM works and that everything is in an encrypted state when suspended to RAM?

share|improve this question
I don't think you can. RAM is not encrypted. If you mean suspend to disk instead (aka hibernate), that's doable. – derobert Apr 30 '13 at 18:01
I really mean RAM. And I don't know if the question is really equivalent to encrypting RAM, just the image saved to RAM has to be encrypted... – student Apr 30 '13 at 19:02
Which image saved to RAM? AFAIK, suspend to RAM doesn't save an image to RAM, it just leaves RAM powered (so what was there when it suspended is still there when it wakes) – derobert Apr 30 '13 at 19:03
I don't think an image is saved in RAM. Only the peripherals and CPU go to sleep, but RAM stays on containing all data before the suspend command. Or something close to that. It also doesn't make sense to encrypt it, it's not possible to read the data if you remove the RAM modules. – forcefsck Apr 30 '13 at 19:12
@forcefsck its possible to read RAM after removing it. Basic procedure is your chill the RAM, and then it'll retain its contents without power for quite a while—many minutes. Plenty of time to read it. I can Google up some links if you're interested. – derobert Apr 30 '13 at 21:07

What you're asking for is not a simple suspend-to-RAM, which leaves the RAM powered on and shuts down everything else. Since you'd be wiping cleartext process data from RAM, you need to marshall it all to the suspension image. So you have to invoke the hibernation (i.e. suspend-to-disk) code. The realistic way to do that would be to create an encrypted ramdisk, declare it as swap space, and fill the memory with other processes. Even then kernel data would not be encrypted; to do that, I think you'd need a sizable kernel patch.

On the other hand, if you're willing to suspend to disk, this is a solved problem. The hibernation image is stored in the swap space. Your swap space should already be encrypted given your security requirement. Make sure that it is encrypted with a known key and not with a random one (some setups with encrypted swap use /dev/random as the key file for the swap space, which results in a different key at each boot, so it is impossible to resume a hibernated image). Major distributions should support hibernation out of the box, including resuming from an encrypted swap space.

share|improve this answer
Wouldn't using /dev/random for the key file be painfully slow during a boot process? There's not much entropy on hand at boot time, and it'd take a while to collect. – mc0e Apr 1 '15 at 4:44
@mc0e Indeed /dev/urandom would be a better choice except on a freshly-installed system or live CD, but I think installers tend to use /dev/random, partly out of a misconception that /dev/urandom isn't suitable for cryptography and partly to be safe in the minority but existent cases where /dev/urandom is indeed unsafe. – Gilles Apr 1 '15 at 8:18
more generally /dev/urandom is inappropriate in all cases where you can't store data securely from your previous boot. If the entropy store is on a disk which is also encrypted (and of course it needs to be writable) then that's OK. The boot process therefore can't be made dependent on the RAM disk content being available till some time after the main disk is unlocked. – mc0e Apr 2 '15 at 10:16

Check out tpm-luks : https://github.com/shpedoikal/tpm-luks

It stores your encryption keys in your computer's trusted platform module.

Another option may be TRESOR, which uses CPU registers to store secret keys.

share|improve this answer
Do I understand this correctly as follows: Your solutions prevents the system to store keys in RAM such that reading the RAM attacks won't give full system access to the attacker because he cannot find the keys there. But it doesn't prevent that the attacker can read files which are currently in RAM and may contain security relevant data? If not it would be nice if you could explain what your solution does... – student May 1 '13 at 7:37
Most methods of mitigating cold-boot attacks are focused on protecting disk encryption keys. According to this paper, "Although the concept of memory encryption has been actively researched for over three decades, it has yet to be used at the core of operating system designs to provide confidentiality of code and data." Also, according to this answer, such systems require a special type of CPU. – jcharaoui May 1 '13 at 22:52

Your Answer


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.