Current (scanty) documentation shows LUKS binding examples without PCR bindings, or with binding to PCR 7/8/9 only (or either of it).
This is highly insecure!
This is no better than just storing plaintext encryption key in the motherboard’s NVRAM or it TPM NVRAM. It’s suitable only for ‘binding’ LUKS key to that exact TPM/motherboard, to prevent the disk to be decrypted without obtaining the PC, but no more. Anyone with physical access to this PC can extract LUKS encryption key in any OS, by booting from USB for example, in 5 minutes, without any obstacles, hacks or workarounds, just by using standard TPM tools.
Now about PCR 7/8/9: these are not measured by UEFI, but updated by the bootloader (GRUB2). This is as insecure as absence of PCR bindings, but the attacker would need to perform one extra step to obtain decryption key: to measure these values right as GRUB2 would do, these are public and usually are a measures of GRUB commands, kernel and initramfs.
It seems that currently Clevis is not ready for every-day unattended usage for TPM decryption of LUKS partitions. For secure key storage, it should be binded to PCR 0, 2, 4, 5, 8 and 9 at least. The key should be updated to updated PCR values with kernel update or initramfs regeneration, but I found no code/scripts and no documentation entries on where is it performed. Without this key regeneration you’ll get automatic LUKS decryption only until first kernel/initramfs update.
I want to be wrong, but I found this topic after I discovered Fedora IoT website, which states:
Security in mind
Security is important for IoT devices especially since they likely don’t have the security of a data center. With support for TPM2, SecureBoot, and automated storage decryption with Clevis, Fedora IoT is built with a focus on security.
I have my own set of dirty scripts to unlock LUKS partitions with TPM key (not Clevis, my laptop has TPM 1.2 which is not supported by that proejct), and Fedora GRUB2 configuration scripts modify Grub environment variables (grubenv file) which creates additional complexity to measured boot. I’ve commented all that long time ago, but remembered that I recently seen on the IoT website and decided to check what did they done as a workaround for mentioned issue.
I’ve downloaded Fedora IoT raw disk image, to find that it doesn’t even support UEFI mode booting, which means it doesn’t support Secure Boot either. After that I’ve downloaded an ISO file, which has UEFI (and Secure Boot) support. I’ve unpacked it to find that there’s no Clevis installed inside. No Clevis or Measured Boot documentation could be found for Fedora IoT.
Given all that, I assume that the claims on Fedora IoT website are mostly false (you can’t do proper automatic and secure storage decryption using TPM without measured boot and automatic recomputing of PCR values, which I did not find anywhere), and currently Clevis is not ready to be used with LUKS+TPM.
I hope I’m wrong and just missed something. I’ll ask Fedora IoT developers to clarify this question.
UPD: it seems that Clevis TPM2 module treat model is to protect the system from remote attacker only.
The Clevis security model relies in the fact that an attacker will not be able to access both the encrypted data and the decryption key.
The tpm2 pin is different in this regard, since a key is wrapped by a TPM2 chip that is always present in the machine. This does not mean that there are not use cases for this pin, but it is important to understand the fact that an attacker that has access to both the encrypted data and the local TPM2 chip will be able to decrypt the data.
This is either by design intentionally, or Clevis developers are not savvy enough with TPM to implement it properly. I’m puzzled of the fact that Fedora IoT mentions Clevis on the website: IoT device are physically present in potential attacker hands.