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?

  • 1
    I believe you will find this new very interesting: extremetech.com/extreme/…
    – kiBytes
    Jan 20, 2014 at 15:39
  • 3
    You mean a physical attack like this one?
    – Gurzo
    Jan 20, 2014 at 16:07
  • @Gurzo that'd be my thought.
    – MDMoore313
    Jan 20, 2014 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. Jan 20, 2014 at 22:00

5 Answers 5


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.

  • 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? Jan 20, 2014 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. Jan 20, 2014 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. Jan 20, 2014 at 22:12
  • @ThomasPornin perhaps something like en.wikipedia.org/wiki/PrivateCore Jan 22, 2014 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. Jan 22, 2014 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.

  • 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. Jan 20, 2014 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. Jan 21, 2014 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. Jan 21, 2014 at 14:22
  • Ok. Given your comment, I'm updating my answer. Jan 22, 2014 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. Jan 22, 2014 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.


Physical disk encryption goes a long way towards stopping a lot of simple hacks. I teach computer science and cyber security, but occasionally the extremely restrictive policies of the school system cause me to work around their security. Because the school system does not use disk encryption I am able to gain local administrator access on the windows machine in under 5 min thanks to physical access. I would not be able to do this if they were using full disk encryption.

  • With what are you doing this, chntpw from a live system?
    – peterh
    Nov 4, 2018 at 18:32
  • I think you could do it also with physical encryption in most cases. The question is, where is the decryption key. In most cases, windows disk encryptions are using a long key, which is stored on the disk, salted with a password (which should exist in the brain of the user/admin). This is breakable by a dictionary attack.
    – peterh
    Nov 4, 2018 at 18:33

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.

  • Update: The algorithm it uses is an LFSR, which is indeed not cryptographically secure.
    – forest
    Nov 5, 2018 at 2:54

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .