For remotely unlocking LUKS volumes via SSH, how can I verify integrity before sending passphrase?

Question

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.

Answer 1

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.

Answer 2

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.