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.

Imagine you have a server that is at a location which is not trustworthy. People might have physical access to the machine who are not supposed to look at the data stored on it.

In this scenario I thought about setting up a server with full disk encryption. This means that the key needs to be entered before the system can fully boot. As long as I have physical access entering the key without a third party getting to know it is feasible.

However, when the server needs to be booted remotely I need to enter the key without being present. Linux offers the possibility of running a lightweight SSH server before fully booting the system so that you can enter the key. However, the certificate for this SSH server obviously needs to be stored unencrypted (because it needs to be read before the key is entered) so attackers can access it and fake our server thus gaining knowledge of the key.

Is there any way to make this process secure? In the best case this would even be OS-independent.

share|improve this question
No one mentioned out of band management. iLO, iDRAC, etc. Weird. –  HopelessN00b Mar 12 '14 at 7:35
Or a simple IP KVM with an encrypted channel. In cases where others have physical custody, like this one, note that you're protecting against accidents more than against malicious actors who work for the company who has custody of your machines. –  Anti-weakpasswords Mar 13 '14 at 3:00

4 Answers 4

up vote 10 down vote accepted

Microsoft's 3rd immutable law: "If a bad guy has unrestricted physical access to your computer, it's not your computer anymore." So you have to trust the people running your data-centre. That's what trust means in information security: it's what you are reluctantly forced to do when you can't fully control, avoid, or transfer a risk.

Still, you will want to put as many controls in as you can. In this case, a TPM module is probably your best bet - the key is burned into the silicon of the chip when it's made, and so is very difficult to extract.

Windows and Linux both support TPM based full disk encryption; so does VMWare ESXi, which would also give you OS independence.

Lastly, @hopelessn00b et al point out something I should have remembered - the remote management cards you can get on enterprise-class servers use strong encryption. That's a great way to get ssh access to the console in hardware, so you don't have to mess with the config of your box.

share|improve this answer
Take note that this law is getting challenged with the arrival of Private Core vCage and Intel SGX. In the case of vCage you basically only need to trust Intel and Private Core. Briefly, vCage provide a L3 resident hypervisor validated with remote attestation. The information is in clear-text only within the CPU. –  northox Mar 24 '14 at 21:40
PDF slides from vCage authors with some details forum.stanford.edu/events/2014/2014slides/plenary/… (Oded Stanford Annual Forum 2014.pdf) and lot of marketing. –  osgx Mar 5 at 19:58

The problem you describe is accurate. I have considered the same problem, and have come up with some "solutions" that can be helpful.

Lets start by listing some possible attacks:

Now, lets list some countermeasures.

  • TPM - Ideally, you would store the keys in a TPM module. This question covers how LUKS can be configured to support TPM. At this point, you would be able to "safely" store your SSH keys from most offline attacks.

  • Chassis Intrustion - You would be interested if someone opened your chassis. Many motherboards come with intrusion detection which can be connected to the chassis. Depending on your motherboard, you should be able to trigger a shutdown + key deletion if someone should open the computer chassis. Some explanation to this can be found in this question.

  • Glue - When the system is running, it is unencrypted. You would like to minimize the attack surface, by gluing it shut. USB peripherals, PCI busses, etc should be inaccessible. This, combined with chassis-intrusion, it would be hard to get to the memory before the computer starts shutting down.

  • Disabling other boot methods and peripherals- Cold boot attacks can use bootable USB devices to quickly dump the memory content before it looses state.

  • Disabling console access - If you are not using the console, disabling it will keep other from using it as well. You can also compile the kernel without VGA support to keep any connected monitors dark

These are some of the options you have, some more extreme and paranoid, but that is maybe what your setup requires.

share|improve this answer
On the physical security front - how about self-destruction via thermite? I've heard that makes it pretty hard to recover the keys... –  Chiggs Mar 12 '14 at 19:12
@Chiggs This should be implemented as rc.selfdestruct ;) –  Dog eat cat world Mar 13 '14 at 12:35

If you have sensitive cryptographic key to be used on a server, you should use a Hardware Security Module. This is a device which offers tamper resistance against physical attack. Moreover an offline attack against this module is more difficult to perform (if the attacker removes the HSM from the server you eventually see it). Some models may also propose a secure channel for remote access in order to allows a remote user with valid credential to unlock the keys.

share|improve this answer

Well, let me offer a theoretical solution to this problem which is secure. Of course, this is only useful for theoretical purposes, but it suggests that your problem is, at least in principal, solvable:

You have the following "stuff":
1. Key: A private key.
2. Plaintext: Your private data
3. Server: An untrusted machine (untrusted because someone else has physical access)

To update the contents of the server:
1. Encrypt the entire plaintext with your key.
2. Update the encrypted plaintext to the server.

To retrieve the contents of the server:
1. Download the entire cyphertext from the server.
2. Decrypt the cyphertext with your key.

I believe this approach is provable safe, on condition that you're willing to make various assumptions (i.e., the same assumptions you make when using SSL and the like).

So, it's possible, at least in theory, to store secure stuff on an untrusted machine. To go a step further, people have even found ways (currently impractical) to execute encrypted CPU instructions on an untrusted machine.

Therefore, I believe that it is theoretically possible to boot an encrypted server remotely. The next question, of course, is if there is any sort of practical, provably safe solution. I'm not sure. However, even if the answer is no, it might not be no forever.

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.