Add TPM2 systemd-cryptenroll to Tips and Tricks

[stenwt]

This worked for me; I'm not sure if it's complete, or the most secure possible configuration, but it's frustrating to try to piece this together from blogs and discussion pages, so looking to firm it up here; would appreciate testing/confirmation/edits/corrections.

[cgwalters]

--tpm2-pcrs=0+7

We found out in https://github.com/containers/bootc/issues/421 that you probably don't want to do that...it will appear to work just fine until the day that you update shim (which we don't do by default, but will happen if you run bootupctl update).

Also for pcr0, I'd be a little wary as I suspect at least running things like fwupd to update the platform firmware may change that PCR.

Basically in general, IMO systemd upstream is doing the right thing in supporting binding to PCRs, but it's extremely easy to blast off your own feet with it. (Like many other security technologies, it's a balance between preventing attacks vs system usability)

[stenwt]

--tpm2-pcrs=0+7

We found out in containers/bootc#421 that you probably don't want to do that...it will appear to work just fine until the day that you update shim (which we don't do by default, but will happen if you run bootupctl update).

Also for pcr0, I'd be a little wary as I suspect at least running things like fwupd to update the platform firmware may change that PCR.

Basically in general, IMO systemd upstream is doing the right thing in supporting binding to PCRs, but it's extremely easy to blast off your own feet with it. (Like many other security technologies, it's a balance between preventing attacks vs system usability)

Is the takeaway here to omit the --tpm2-pcrs flag?

[samcday]

I don't think you can do that? The way cryptenroll works (as I understand it) is to derive a key from the specified PCRs and add that to a free LUKS slot.

I think @cgwalters is warning us that PCRs are subject to change in surprising ways. Take a look at this page: https://uapi-group.org/specifications/specs/linux_tpm_pcr_registry/

In fact, it's not just the shim itself that can affect PCR 7, I'm pretty sure if you let fwupd upgrade your DBX with newer sig exclusions that also influences PCR 7 state. Upgrading your system BIOS will certainly cause PCR 0 to change.

I think these are all okay though. It's just worth mentioning in these docs you're proposing to add that using TPM2 to bind your disk is a convenience thing and that you absolutely MUST keep a regular passphrase enrolled in a keyslot of your LUKS container in case the PCRs change.

[travier]

Thanks for writing this! I'll give it a try.

[travier]

So I've found the following related discussions:

• https://github.com/fedora-silverblue/issue-tracker/issues/409
• https://github.com/fedora-silverblue/issue-tracker/issues/369
• https://github.com/fedora-silverblue/issue-tracker/issues/431
• https://fedoramagazine.org/use-systemd-cryptenroll-with-fido-u2f-or-tpm2-to-decrypt-your-disk/

Reading this PR, I think it would be great to figure out why the systemd-pcrphase module is not enabled by default in the initramfs.

[travier]

I've made https://gitlab.com/fedora/ostree/sig/-/issues/33 for Rawhide/F41 to help improve the situation here.