Is it possible to boot an encrypted server remotely and securely?

Question

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.

Answer 1

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.

Answer 2

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:

• Copy SSH keys from storage (offline attack)
• Memory dumping - Cold boot attack
• Console access
• DMA Attack

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.

Answer 3

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.

Answer 4

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.

---

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.