Hacker News Reader

Comment by Nextgrid | Hacker News Reader

Wouldn’t that be the job of the software TCB to ensure only the appropriate user is given access (and prevent the user from accessing the TPM directly obviously)?

The TPM validates the state of the software TCB, and the software TCB validates the state of the lower layer, and so on.

View on HN

> Wouldn’t that be the job of the software TCB to ensure only the appropriate user is given access (and prevent the user from accessing the TPM directly obviously)?

This only works with the current TPM design if there is one “appropriate user”.

The real world contains Chrome, BitLocker, various VMs and containers, etc. The TPM does not properly accommodate this world.

The primitives of a tpm ("observations", which in practice map to ca-signing keys of various levels of boot stage) are a very poor match for the real world. In order for them to be usefully consistent, you have to have consistent inputs. That means you can't observe the kernel itself, but instead you observe a key that signs a kernel. This is awful when it's Microsoft signing a series of kernels that advance one-way but the TPM doesn't actually ratchet to prevent downgrade attacks (and would be even worse if it did, because then you'd inevitably brick machines again and again). Instead you trust a long-lived CA and God help you when you need to rotate it.

It's even worse if you're self-hosting the signing, to the point that despite a ton of work put into making it safe and understood I wouldn't do it with the current design; a bare-state unlock is more predictable and reliable but I'll make sure to regularly exercise my backup key and header.

> That means you can't observe the kernel itself, but instead you observe a key that signs a kernel.

You can observe the kernel. It’s just extremely awkward because upgrading the kernel will change the kernel.

Ugh?

I thought application talks to the OS and the OS that check before it do the TPM thing.

Reply on news.ycombinator.com