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)

PCR register table

The referred UAPI table is itself not authoritative and makes exclusions like "How other operating systems — in particular Windows — use PCRs, is out of scope of this document.", which we need to cover to some extent. The PCR register itself is stable, we'd mostly remove links to our own content and a place for contextual info (e.g. users multi-booting). So, I'm against removal for now. Indigo (talk) 19:33, 6 December 2024 (UTC)

I'm against its removal too. IMO we can improve the table to a better state than what the UAPI group or TCG has. The only thing missing from our table would be an "Extended by" column listing which software changes a PCR. -- nl6720 (talk) 07:19, 7 December 2024 (UTC)

Thanks for putting up the talk page. I agree that the uapi table is not authoritative, but it still is more accurate right now than the wiki one. I was about to copy paste some of the missing stuff and figured this makes no sense, just like duplicating man pages.

For most people, a lot of the PCRs really aren't useful. That's why I think focusing (1) the useful PCRs and explaining why they make sense and (2) adding info which is missing from the uapi table makes more sense than yet another table. Cvlc (talk) 22:55, 7 December 2024 (UTC)

As soon as I find some time I'll put up an article on signed PCR policies and PCRlock, which both make more sense in my opinion and really aren't any harder to use anymore than raw PCR hashes. That's why as much as I'm interested in PCR hashes, I'm afraid keeping all this info might confuse people more than be useful to anyone. Cvlc (talk) 23:01, 7 December 2024 (UTC)

I think these are all valid points and clearly good additions. More and more software will make use of PCR registers, so it's indeed seems useful to not only use the table as a crosslink anchor but be able to add context with a new column where applicable.

At the same time I follow the point that most users will benefit from a structured approach to deploy the new systemd tools. Albeit they may be most useful for their main intend first - "factory"-style images/hosts/machines. Yet, that should not matter, many users will be able to apply a structured guidance for their hardware/purpose. Just keep in mind it's systemd tools. The kernel offers different API to the TPM, systemd decides on one that's useful for its purpose, but other software other use cases.

IMO you should switch the remove template to Template:Expansion. Depending on phrasing, we can keep this item linked to it for the time being regarding scoping, or open a new one. --Indigo (talk) 20:24, 9 December 2024 (UTC)

Changed the template to expansion. I still think the table in its actual form needs to go though :)

Maybe a subsection per meaningful PCR, and examples as to why they make sense ? For example, the warning which is somewhere about making sure SB is enabled before tying to PCR 7 would go under PCR 7, etc.. Cvlc (talk) 23:41, 29 December 2024 (UTC)

I changed the table slightly. IMO the PCR descriptions need a lot of improvement (I wonder from where they originated), but I still think it's worth it to keep the table. ❄️❄️ nl6720 (talk) 11:24, 30 December 2024 (UTC)

A more up to date version of this table is also being maintained here, although it is missing the bits relating to Windows. https://man.archlinux.org/man/systemd-cryptenroll.1#TPM2_PCRs_and_policies Kolly (talk) 13:34, 7 January 2025 (UTC)

That's a neat man presentation, yes. I'd vouch to link it instead of the UAPI, but it also misses all the addendum notes that page has. Then again, it lists PCR 16/23 when the UAPI does not even mention them .. It makes sense to link it from systemd-* articles and, in my opinion, it does not hurt to crosslink all sources above the table either, maybe pointing out differences. Example: I write from a notebook which uses PCR16 optionally. It is a corner-case, but there will be a few of such. --Indigo (talk) 21:19, 7 January 2025 (UTC)