Talk:Trusted Platform Module

From ArchWiki

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 sould 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:
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)
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)

move systemd-cryptenroll to separate article

If nobody minds this, I think the section systemd-cryptenroll should become a general purpose article (not focused on TPM only). With a few tweaks it applies to FIDO2 keys (as mentioned in and tested by myself right now), I imagine it similarly applied to other supported workflows (see like smartcard.

--Sado1 (talk) 14:38, 6 May 2023 (UTC)

I think this is a good idea. -- nl6720 (talk) 06:59, 12 August 2023 (UTC)