[Foxboron]

> But the whole point of binding a key to hardware is to be secure even if a remote attacker has gotten root on your machine. An attacker with root can simply replace the software that reads your PIN with a modified version that also saves it somewhere. Then they can use the key whenever your computer is online, even if they can't copy the key off.

It protects against extraction, not usage on the machine itself. Of course they can use the secret on the compromised machine.

> And although that's a bit limiting, once they've SSHed to a host as me once they can add their own key to authorized_keys in many cases.

Assuming they can edit the file.

> That's why Yubikeys and U2F keys and suchlike have a physical button.

The TPM spec has a policy setup to account for some fingerprint reader that can be used to authenticate. I haven't been able to figure out how/what/whys of the implementation here but this is very much a thing.

[michaelt]

> It protects against extraction, not usage on the machine itself. Of course they can use the secret on the compromised machine.

Yes, this is why I was careful to say that the benefits are obscure, rather than saying they're entirely nonexistent.

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.

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.

[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.