6

Although this is closely related to the recently closed question Evil maids in the server room [closed], I believe that it's more answerable.

I'd like to unlock LUKS volumes on remotely hosted servers, using initramfs with BusyBox, and Dropbear as SSH server. In the answer to the closed question cited above, paj28 notes:

 Remote boot techniques like dropbear are vulnerable to a remote variant of
 the evil maid attack. For example, someone with physical access could tamper
 with the dropbear partition, and have it leak the key on the next reboot.

The attack is also described in LUKS mermaids of remote unlock.

In the BusyBox initramfs environment, I'd like to verify the integrity of a remote server before sending the passphrase for unlocking LUKS. I can verify file integrity by checking sha256 checksums against a local list. But would that detect modification of the initramfs to capture the passphrase?

I can easily get eth0's MAC, and I can use traceroute to detect changes in the network environment. Perhaps I can add hwinfo to the initramfs to confirm the hardware environment. What changes could go undetected by those tests?

I'm not asking for a solution, but if there's an elegant one that I'm missing, please let me know.

Community
  • 1
mirimir
  • 726
  • 4
  • 11
  • If _you_ didn't reboot the system, don't trust it. Don't attempt to boot it. Just cancel your lease and restore your backup onto another server elsewhere. You also need to monitor the RAID array if present. – Michael Hampton Dec 07 '13 at 04:14

2 Answers2

4

You don't. You can't.

The best you can do is a trusted boot pathway using TPM which you make part of the partition unlocking process. But unless the hardware is locked to your personal signing key (which it probably isn't), then even that can be subverted.

Still, TPM is probably the closest you can get. This is non-trivial to implement, and it is unlikely that you'll find an off-the-shelf solution for this.

tylerl
  • 82,225
  • 25
  • 148
  • 226
  • TPM isn't reliable, because users can't rewrite (or even see) private keys, or validate chain of trust. And building my own TPM isn't feasible. Wouldn't tests that I mentioned detect at least some attacks? Is trust in the hosting provider the only relevant factor? – mirimir Dec 06 '13 at 04:03
  • 2
    The whole *point* of TPMs is that users can't copy or overwrite the private key. Perhaps you have a different idea of what *reliable* should mean. As for your tests, sure, anything will detect *some* attacks. But security doesn't come from the ability to detect *some* attacks. – tylerl Dec 06 '13 at 04:17
  • Perhaps "user" was poor wording. I'm talking about owners, or at least renters. If I need to trust some third party in using the TPM, that's no better than simply trusting the hosting provider. In any case, are you arguing that FDE is always pointless for hosted servers? – mirimir Dec 06 '13 at 05:00
  • 1
    TPM is tied to hardware. Its keys are available to *no one*. Were it not so, then the TPM would not be tied to hardware. Your hosting provider must be trusted, by definition. He has physical control over your device, which mean there is nothing but *nothing* you can do to stop him. Best bet is physical intrusion detection hardware, etc. But even that can be circumvented. FDE isn't pointless, but don't fool yourself into thinking that it will create a trusted environment out of an untrusted one. – tylerl Dec 06 '13 at 05:37
  • Thank you. I do appreciate that there is nothing that I can do to prevent hosting providers, or adversaries who have gained access, from doing as they will to my hardware. All that I seek are ways to detect changes before providing my passphrase. I'm not even expecting to know whether changes have enabled passphrase logging. I'll do my best to choose a trustworthy hosting provider. But circumstances may change, and I want another layer of protection, even though it may be imperfect. – mirimir Dec 06 '13 at 06:09
  • 1
    "You don't. You can't." This is fundamentally incorrect. Remote attestation _is_ possible when using a TPM. – forest Nov 29 '17 at 08:16
  • @Baal-zebub Remote attestation is only meaningful if you can trust the TPM. If you have never been in physical possession of the server, then you don't know for certain that the hosting company doesn't have the private key (e.g the TPM may be implemented in software). Protecting against the hosting company is fundamentally impossible because they control the initial conditions. – tylerl Nov 29 '17 at 09:25
  • The TPM is specifically designed to mitigate that risk. It is similar to a signed cert from a CA. You would have to argue that the hosting company has stolen this key in order to worry about a fake TPM. There is a reason it is impossible to run a TPM like this in software. This key is called the [Endorsement Key](https://technet.microsoft.com/en-us/library/cc770443(v=ws.11).aspx). It is designed to ensure that a genuine TPM can be recognized. – forest Nov 29 '17 at 09:36
  • 1
    Not only that, but the CRTM ensures that the root of trust ends with something which cannot be tampered with. – forest Nov 29 '17 at 09:44
  • @tylerl I am not sure I understand. What happens when the TPM fails? Do I lose all the data if I do full disk encryption with it? – inf3rno Apr 03 '20 at 01:48
1

You can use remote attestation, as provided by a TPM, using SRTM.

Ensuring a TPM is genuine

Despite what @tylerl says, you do not have to trust your own signing key for a TPM to provide attestation. A genuine TPM will use an Endorsement Key, or EK, which is a key burnt into the TPM at manufacture time, with the corresponding private key never being released to the public (similar to how PKI for the web works). The only way a fake TPM could be presented (such as being emulated in software) would be if the Endorsement Key is not secret. If your datacenter has a stolen EK, you have a lot more to worry about. A TPM will not protect you from such an adversary anymore than HTTPS will protect you from a rogue CA.

Measured boot

A TPM provides a feature called measured boot, the specifics of which can be found all over this website. The gist of it is that a secure, read-only component of your BIOS, called the CRTM, initiates a chain reaction where different components of your system are hashed and sent to the TPM. Unless all the hashes match a known-good state, the TPM will stay locked, or sealed. The only way it can ever be unsealed is when the system is in a known state. The exact data which it seals is arbitrary. It can be used to seal, for example, encryption keys, so the system can only be booted if the system has not been tampered with. It can also be used to store a secret value known only to you, such that malicious hardware cannot predict what this value is and present it to you. Only if you see it do you know that the TPM is both genuine and your system is in a sane state. This is the basis for Joanna Rutkowska's Anti-EvilMaid.

Integrity after TPM has done its job

The TPM's job ends once it boots your kernel. It ensures that all the rest of your system, from BIOS to option ROMs to bootloader to NVRAM has been measured, but after measuring the kernel, its job is done. The kernel has been measured, but the rest of the system is not. When you get to this point, the kernel must provide some sort of measurement. One feature Linux has is the Integrity Measurement Architecture, or IMA. IMA works by keeping a hash of all files on the system in an extended attribute. These hashes are compared verified using a master root hash which is stored in the TPM. The kernel will refuse to read any files with no hashes or who's hashes cannot be verified as legitimate. At this point, you have successfully undergone measured boot and are now in a trusted running environment.

Caveats

  • Measured boot does not prevent against some types of hardware attacks, such as DMA attacks. Preventing those is sometimes possible (e.g. with DMAR), but out of scope here.
  • If your adversary is powerful enough to get their hands on the DK, they can create a fake TPM in software and you won't know the difference.
  • In order to get a valid readout from the TPM, the system must be, at least initially, not compromised, or you must check the reported hashes against known-good values.
  • Some BIOSes may have an incorrect implementation of measured boot. For example, the CRTM may reside in writable flash storage, and a TPM relies on the CRTM being read-only.
  • An well-resourced adversary may be able to decap the TPM and read the contents inside with an electron microscope. This is very difficult, but physically possible.
  • Older versions of TPM (1.1) were vulnerable to platform reset attacks. You should use a newer TPM (2.0 or at least 1.2) to avoid this. Alternatively, Intel's integrated fTPM may work for you.
forest
  • 64,616
  • 20
  • 206
  • 257