In reply to @js:ukvly.org
hey everyone. Is there a good overview somewhere what the different TPM PCRs are usually used for?

https://github.com/systemd/systemd/pull/26185

This sounds like you won't be able to just systemd-cryptenroll with a TPM anymore without taking ownership of the TPM, is that right?

If the owner auth is empty, you have a worthless TPM

Can anyone explain what they mean by this?

In reply to @elvishjerricco:matrix.org

https://github.com/systemd/systemd/pull/26185

This sounds like you won't be able to just systemd-cryptenroll with a TPM anymore without taking ownership of the TPM, is that right?

I figured this out finally. Basically the problem is that if the TPM has any authorization set on the key hierarchy, systemd simply can't use it. Because the easy way to use the TPM (the way systemd does it) is to always have the TPM recreate the same "primary key" (meaning the key at the root of the hierarchy, derived from the seed burned into the hardware). This key is what systemd asks the TPM to use to seal and unseal stuff (note that it remains internal to the TPM). But you're not allowed to create keys if the hierarchy requires authorization that you can't provide. So systemd just doesn't work if that authorization exists.

But anyone who takes ownership should almost certainly create an SRK (storage root key) and store it in the TPM. This is a primary key in the hierarchy that systemd wants to use. Since it's stored in the TPM, systemd can just ask the TPM to use it without having to create it.

So unauthorized users are able to use the keys stored on the TPM how they like, but they can't change the key hierarchy within the TPM or ask it for new keys. The PR changes systemd to work this way instead when the SRK exists in the TPM.

So it should have absolutely no effect except that now more people can use systemd's TPM support