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.

  • 1
    No one mentioned out of band management. iLO, iDRAC, etc. Weird. Mar 12, 2014 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. Mar 13, 2014 at 3:00

4 Answers 4


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.

  • 3
    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, 2014 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, 2015 at 19:58
  • 2
    "Only need to trust Intel and PrivateCore". That's where the problem lies. PrivateCore's vCage is not open source. How much of the memory do they encrypt? Do they leave 2 pages unencrypted? 2 MiB? 256 MiB? High quality remote attestation with full memory encryption would be amazing, but when a company is promising the moon, I would like to see if they can actually fulfill that promise, rather than simply get a VPS for $1000/month based on almost blind trust.
    – forest
    Apr 5, 2016 at 2:16
  • Now that's not to say I think that vCage is a scam. It's certainly a great idea and from what I read of the implementation details, it's pretty solid, but it's such a complex topic that I just can't believe that they have found all the gotchas.
    – forest
    Apr 5, 2016 at 2:16

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.

  • 3
    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, 2014 at 19:12
  • @Chiggs This should be implemented as rc.selfdestruct ;) Mar 13, 2014 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.


Updated Answer:

Yes. This is not only possible, but this is an existing feature offered by Microsoft (Note: Microsoft's system is likely breakable in theory, since TPMs and theoretically possible to compromise). "Shielded VMs" are designed specifically to be hosted remotely while still secured against "compromised or malicious administrators in the fabric, such as storage admins, backup admins, etc." They accomplish this by encrypting disk/state of the VMs.

See A closer look at shielded VMs in Windows Server 2016 for discussion (Server 2019 adds Linux support).

You should be suspicious of the giant asterisk next to "Server administrator" in the infographic below. High-level, securing a VM from the server administrator requires the use key-based or TPM-based attestation.

Subsection of Microsoft's Infographic

Previous 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.

You must log in to answer this question.

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