[Foxboron]

> I'll admit that's a benefit, but it seems very small benefit considering the far-reaching changes it's needed like kernel lockdown mode, the microsoft-signed shim, distro-signed initrd, the difficulties it creates with DKMS, and so on

None of this is needed to take advantage of TPMs.

> Whereas people who need to bind their SSH key to hardware can get a higher degree of security with a far smaller attack surface by simply spending an hour's wages on a Yubikey.

Yubikeys are expensive devices, and TPMs are ubiquitous. Better tooling solves this problem.

[michaelt]

> None of this is needed to take advantage of TPMs.

You're not binding the secret to PCR values? I thought TPM fans loved those things?

I don't blame you - they look like a design-by-committee house of cards to me, with far too many parties involved and far too much attack surface. Just like the rest of the TPM spec.

[Foxboron]

> You're not binding the secret to PCR values? I thought TPM fans loved those things?

Binding things to PCR values doesn't imply you need Secure Boot, signed initrd, lockdown mode, shim and signed kernel modules. All of these things are individual security measures that can be combined depending on your threat model.

> I don't blame you - they look like a design-by-committee house of cards to me, with far too many parties involved and far too much attack surface. Just like the rest of the TPM spec.

The v2.0 version of TPM doesn't really make PCR policies easier to use, so I've had troubles getting them properly integrated into the tools I write as you need to deal with a key to sign updated policies. `systemd-pcrlock` might solve parts of this but it's all a bit.. ugly to deal with really.

The entire TPM specc is not great. But I find TPMs too useful to ignore.