Information Security Stack Exchange is a question and answer site for information security professionals. It's 100% free, no registration required.

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

I've been researching into some methods to ensure that disk encryption keys can't be stolen, and one that I've come across is called TRESOR. With this kernel patch, you can create a partition that is encrypted using AES, and the keys are stored in the CPU caches instead of in RAM. At first, I thought this was great, but upon further questioning, I've come to the conclusion that any decrypted data still stored in RAM is vulnerable to a physical cold boot dump. A potential way for this to be secure is encrypting the contents of usable OS RAM using TRESOR and then creating an encrypted partition, since the keys will be in the encrypted RAM, and the RAM's keys in the CPU cache. I still don't know if this is a secure method, or how sound it is. Is it even possible to prevent a physical attack on full disk encryption, and if so, how can I?

share|improve this question
I believe you will find this new very interesting:… – kiBytes Jan 20 '14 at 15:39
You mean a physical attack like this one? – Gurzo Jan 20 '14 at 16:07
@Gurzo that'd be my thought. – BigHomie Jan 20 '14 at 18:52
@kiBytes Hopefully an attack of that sort will be impossible in a datacenter due to interference from other machines, and by time my machine would be powered down and moved, the RAM contents would be gone. – Clay Freeman Jan 20 '14 at 22:00
up vote 7 down vote accepted

For the CPU to actually process the data, the data must be in cleartext at some point. TRESOR uses the CPU registers, presumably harder to read than RAM for physical attacker, but its scope is limited to the encryption key: that key is in the registers, but the data that is encrypted or decrypted is still in RAM. There are only a handful of registers in the CPU, there is simply no room for more data.

Using a TRESOR-backed RAM disk, you have "encrypted files" with fast access (since that's RAM), but they are still "files" in the view of the kernel and application code. The data will be decrypted in RAM at some point.

If you really want all RAM to be encrypted at all times, then the choice is either to use a CPU which includes the hardware to do such encryption (there are some smartcard CPU which do that, but no PC-like CPU to my knowledge), or to make a complete virtual machine whose virtual CPU is implemented TRESOR-like with automatic encryption and decryption upon each memory access. The actual encryption mode would need some thorough thinking (it is not easy to encrypt data securely while still allowing fast decryption with random access). I am not aware of any prototype; but it is theoretically feasible. A nice project for a student (it could even be the main result of a PhD). It would be awfully slow.

share|improve this answer
Do you have an example of some hardware that support full RAM encryption? I might be interested in purchasing such hardware. Also, wouldn't a virtual machine with a TRESOR-like vCPU still be vulnerable from the host level since the CPU registers are stored in the host's RAM? – Clay Freeman Jan 20 '14 at 21:58
I had found one but it was a 80C51 processor, i.e. the kind of thing found in cheap smartcards. As for the "virtual machine" I do not mean it in the "VMWare / QEMU" sense, rather as in "Java Virtual Machine": the physical CPU runs an emulator for a custom CPU. – Thomas Pornin Jan 20 '14 at 22:08
I can see what you mean now. Is there anything like a DIMM interface that automatically encrypts a stick of RAM? If you have a link to any piece of hardware or software that you think will help, send it my way. – Clay Freeman Jan 20 '14 at 22:12
@ThomasPornin perhaps something like – woliveirajr Jan 22 '14 at 12:51
@woliveirajr I've attempted to make contact with PrivateCore to learn more about what they provide. That's a very good find! I'd like to have more than one option down the road though if possible. Preferably open source. – Clay Freeman Jan 22 '14 at 17:40

Well, there is some old saying from Microsoft (I know, not the best security source) that says:

Law #3: If a bad guy has unrestricted physical access to your computer, it's not your computer anymore.

And why is that applicable to your case? Because if you have sufficient cryptography, your hard disk is secure if someone steals it. But if the person can have access to your RAM chips right after your server was powered down, he can try to recover the keys in the scenario you just said.

Storing the keys in the CPU cache would minimize it, as you said, but unencrypted data could still be available in RAM chips.

And what if he has access to your computer before you power it on? Are you considering physical protection before booting up? otherwise, the bad guy can create some fake login screen and grab your password even if your whole system is encrypted. Or he can attach some keylogger. Or he can attach some device and clone your RAM chips from the beggining. Or he can change your BIOS and do that too. Or... well, take a look at the NSA catalog, for example, to have some ideas of the potential attack.

So your computer has to be physically secure. And by that, it means that not only physical access must be hard (for example, given enough time to the RAM content vanish), but also that he can't capture magnetic radiation from the CPU or motherboard or keyboard, nor noises, nor pictures from you typing or moving the mouse.

If you really need that level of security that taking out RAM chips out of your computer is necessary, you probably need even more security than you expect.


After your comment:

I'm wanting protection so that my clients' data cannot be retrieved physically from the server while it is running, just powered off recently, or has been powered off for a while.

I think that I can expand a little my answer, just thinking in this physical aspect.

  • To protect your data after your server is powered off for a while:

Encryption is your friend. If someone takes out a HDD that's encrypted with strong algorithm and strong password, he'll take forever doing brute force to attack it.

Points to consider:

a) whole disk encryption requires that you or some program "type" the password when mounting it. If it's you, you'll have to be available to turn it on every time. If it's a program, where to store the key

b) encrypt just data/folders, the same problem "where to store the key to turn it on" exists.

  • To protect data after the server was powered off recently, or while running:

While running, you would need that the path between HDD - RAM - CPU is encrypted, as the answer from Thomas Pornin explains, and that I'm not aware of any server with a CPU able to do so. And you would need to worry about compatibility with some periphericals, since PCI, PCI express, firewire, etc., rely on DMA to speed up things. So, you could have performance issues.

An easier way to avoid that is, well, physically protecting your server. Like some safe room, where the server is powered down and warmed to certain temperature (to avoid someone stealing your RAM chips). Or even destroying chips with controlled blast or voltage peaks. Anything that make it harder for someone breaking in and go away with your server under his arms.

And, of course, all this leaves out the that many attacks can be done remotely, without any physical presence, just using software and so on.

share|improve this answer
I plan to use the sysfs interface to enter the password remotely, so I should be safe from physical attacks on input devices. I'm planning this for a server in a datacenter that will be hosting VPSes. If you can offer any suggestions for security, they will be helpful. – Clay Freeman Jan 20 '14 at 22:05
Got it. But, well, for what you asked, I think that any answer would go about the physical aspect of it. If you're thinking about protect one VPS from another using disk encryption, perhaps you're going on the wrong way. If you'd like to chat about it, tell me and I'll be in the chat room. – woliveirajr Jan 21 '14 at 10:56
I'm wanting protection so that my clients' data cannot be retrieved physically from the server while it is running, just powered off recently, or has been powered off for a while. – Clay Freeman Jan 21 '14 at 14:22
Ok. Given your comment, I'm updating my answer. – woliveirajr Jan 22 '14 at 11:53
The paths between CPU - RAM - HDD wouldn't necessarily have to be encrypted when communicating, but things definitely need to be encrypted when stored in RAM or HDD. Other than that, it seems as though a host operating system and an unencrypted section of RAM would be needed to allow PCI devices and such to function properly. Unfortunately, regarding physical server security, I would be unable to protect the server in the manner that you describe since I plan to colocate in a datacenter. I've considered this as maybe the only solution to my problem though. – Clay Freeman Jan 22 '14 at 17:45

I'm assuming that OP is building a server, and shipping it to the colo facility.

Physical security would include:

  • embed RAM, CPU and associated circuitry with a PMMA/Al2O3 composite (electrically insulating, thermally conductive and very durable)
  • optionally include dead-man circuits in above that nuke CPU and RAM
  • disconnect all external connectors except power and needed NIC(s) but don't alter external appearance
  • install multiple case intrusion switches, with each one killing power when triggered (even better, have them nuke CPU and RAM unless disarmed remotely)
  • disable remote management capability

Software security would include:

  • boot remotely using dropbear for ssh to initramfs
  • after bootup, overwrite LUKS keyslots and header with random bits (none of that needed until reboot)
  • when rebooting, ssh to initramfs and restore LUKS keyslots and header
  • do frequent secure backups

That should do it, except against very determined and skilled adversaries.

share|improve this answer

Some filesystems support DAX, which stands for Direct Access. It's a feature which bypasses the page cache, so a filesystem encrypted with TRESOR will not leak much if any unencrypted data when you read and write to it. You can put a file in tmpfs and create a loopback device and encrypt it with TRESOR, then format it with a filesystem that supports DAX. This will be an encrypted, cold boot-immune ramdisk.

You could also create a very large tmpfs filesystem and put a huge file in it, taking up the majority of your memory (90 or 95%), until your system is so slow with so little memory that it is unusable. Then encrypt that memory-resident file with TRESOR and use it as a swap file. This will effectively allow the majority of your memory to remain encrypted, while a small amount that is most frequently used will remain unencrypted. I've experimented with this myself, and in a virtual machine at least, I can get it down to about 256 MiB of unencrypted memory. If you tweak the kernel and play with enough sysctls, you should be able to get it down to as low as 64.

Some projects you might be interested in:

CryptKeeper: Improving Security with Encrypted RAM

RamCrypt: Kernel-based Address Space Encryption for User-mode Processes

A Bytecode Interpreter for Secure PRogram Execution in Untrusted Main Memory

If you only need to encrypt the memory space of individual processes such as nginx, php-fpm, etc, then RamCrypt is absolutely what you want. It is a modified version of TRESOR, works for the 3.19 kernel (although it is very to port to newer kernels, with just a few rejects involving new header files and some functions changing names), and has an acceptable perf impact.

DDR3 and DDR4 memory supports a feature called "memory scrambling". It's used to reduce excessive di/dt (interference from successive 1s and 0s on the bus), and makes classical cold boot attacks harder. I'm not aware of what algorithm it uses, or if it's cryptographically secure or not. Read pages 26-30 on Secret of Intel Management Engine for how it's stumped at least one instance of reverse engineering.

share|improve this answer

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.