Take the 2-minute tour ×
Information Security Stack Exchange is a question and answer site for Information security professionals. It's 100% free, no registration required.

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

3 Answers

up vote 5 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 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 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 at 22:12
    
@ThomasPornin perhaps something like en.wikipedia.org/wiki/PrivateCore –  woliveirajr Jan 22 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 at 17:40
show 2 more comments

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.

Update

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 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 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 at 14:22
    
Ok. Given your comment, I'm updating my answer. –  woliveirajr Jan 22 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 at 17:45
show 2 more comments

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
add comment

Your Answer

 
discard

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.