Talk:Trusted Platform Module

Uses and security implications

I'm still not sure what TPM is used for and whether or not it's a good idea to use it at all. It seems like TPM can be used to store LUKS private keys [1]. What's the point of that? It seems like Windows uses it so that a user only has to enter their user password both to unlock the partition and to login [2]. VeraCrypt (and previously TrueCrypt) is against the usage of TPM. [3] —This unsigned comment is by Rdeckard (talk) 11:39, 23 February 2018. Please sign your posts with ~~~~!

PCR 0 should be avoided

This --tpm2-pcrs=0+7 flag is flat out wrong, but copied from howto to howto. :-/ (It appeared in a few blogposts, e.g. here, sometimes even with a , instead of a +, which is “doubly wrong”, in a way.)

The man page for systemd-cryptenroll explicitly discourages the use of PCR 0: “For most applications it should be sufficient to bind against PCR 7… …it's typically not advisable to include PCRs such as 0…”

The reason is that the key should not be bound to PCRs that change routinely and whose changes are benign. This includes system firmware (PCR 0). On recent Lenovo laptops, for example, firmware updates (fwupdmgr refresh; fwupdmgr upgrade;) can appear often, perhaps monthly. The key enrollment should not be invalidated after each firmware upgrade.

That↑ said, the default PCR 7 (picked in absence of the --tpm2-pcrs flag) is all that’s needed.

Andrej (talk) 20:06, 29 March 2023 (UTC)

I'm not an expert, but I'm not sure I agree with the advice given in the man page. Or, at least, I would like to see a source for the claim that "since the program code they cover should already be protected indirectly through the certificates measured into PCR 7." As far as I understand it, if you don't bind to PCR 0, someone could flash malicious firmware to your device, boot it up, have the TPM automatically unlock your drive (because you didn't bind to PCR 0 so it doesn't care if the firmware changed) and then use the malicious firmware to steal your data without knowing your user password. This could theoretically be done without physical access to your system, if you download malware that automatically flashes your BIOS. Of course, one could dispute the probability of this scenario, but I think it would be possible if you don't bind to PCR 0.

I'm pretty sure Windows binds to PCRs 0 and 7 (at least). That's why if you update your UEFI on a Windows laptop it will ask you to suspend disk encryption for one reboot cycle, so it can rebind the TPM PCRs. Not that we should blindly follow whatever Microsoft does, but I don't think it's bad to consider wider industry practice. I guess, in my opinion, the firmware is the ultimate root of trust, since it's the lowest layer of software on your computer (other than maybe IME), so it's integrity should be assured before anything else. I'm open to being convinced otherwise, though, especially since the man page seems to imply that it should be indirectly measured through PCR 7. I've just never heard that before.

Forgonewarrior (talk) 19:54, 11 April 2023 (UTC)

If firmware is forged then PCR0 is already useless. At boot chain UEFI BIOS is inherently trusted, so an advanced Evil Maid can just forge PCR0 read output. While NIST already gave out guidelines for signed BIOS and SPI Protected Range, but the implementation is up to the manufacturers, so PCR0 is useless. Source: https://www.c7zero.info/stuff/Evil%20Maid%20Just%20Got%20Angrier.pdf

Bitlocker doesn't use 0 and 7. It uses either 0 2 4 11 or 7 11 (the latter is preferred when 7 is bindable - for TPM 2.0, this is because PCR 7 on TPM 2.0 performs platform attestation in addition to just storing Secure Boot flag from TPM 1.2) https://learn.microsoft.com/en-us/windows-hardware/test/hlk/testref/954cf796-a640-4134-b742-eaf0ed2663ff#troubleshooting

So conclusion, PCR0 binding is useless (BIOS firmware inherently trusted). Binding PCR 4 will require rebinding everytime bootloader update, PCR 2 need rebinding after adding PCIe and other stuffs. On TPM 2.0 binding 7 is enough, on TPM 1.2 nothing is safe but at least TPM 7 is still a decent default (maybe bind 4 and 7 + hook to rebind everytime grub updates)

TL;DR: PCR 7 is a good default, especially for TPM 2.0. PCR 0 should not be used

N0k0m3 (talk) 03:53, 5 May 2023 (UTC)

Agree with the above and the notion that PCR 0 is arguably unnecessary.

The man page as of systemd 254 advises not to use PCR 0 and 2 as it is both redundant and fragile. Putting aside whether this advice is correct or not or unnecessary, measuring against literal PCR values for this component is certainly more fragile compared to signatures as firmware upgrade would risk locking the user out.

Unless binding to signatures are supported for PCR 0, this should not be recommended. Nu4425 (talk) 22:04, 6 October 2023 (UTC)

I've added [4] and am still in contemplation if current suffices to close the topic. Opinions/edits welcome. One consideration to keep in mind is that systemd-cryptenroll requires a prior passphrase/luks-key. So, the worst case of a user locking themself out (totally) via misconfiguration is reduced by that. --Indigo (talk) 15:02, 8 October 2023 (UTC)

That's true. The user wouldn't be completely locked out unless TPM2 is the only method for unlocking the LUKS2 volume.

The necessity of PCR 0 is still up for debate, and would actually be interested in another opinion. Since this is the case, it should not be included in the default example which I've already changed.

The default example on the wiki which should be left simple--kept to systemd-cryptenroll's current defaults and recommendations. As of systemd 254 this is PCR 7. Nu4425 (talk) 05:11, 9 October 2023 (UTC)