Hacker News Reader

Comment by amluto | Hacker News Reader

This is someone related to a major TPM pet peeve of mine: the TPM only really cares about global device state and has no concept that a device may be a multi-user system, have multiple processes with different security levels, have multiple tenants, etc.

For example, it really ought to be possible to seal a secret such that it can only be unsealed if PCRs have certain values (the usual TPM thing) and the requester of the unseal operation is tagged by the OS (software TCB) as having a certain identity. The latter part is entirely missing from the TPM spec. (The identity could be a hash of the process, just a UUID, or just about anything else as long as it was reasonably well associated with the process in question. Obviously there are subtleties here.)

If the TPM worked the way I wanted, an unprivileged process running alongside Chrome would be completely unable to use the TPM to pretend to be Chrome.

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)?

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

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

I'm not even sure why OS exposes TPM directly to applications instead of having a virtual store for credentials that could be backed by whatever.

UPD. nvm, that's not what's happening

> having a virtual store for credentials that could be backed by whatever.

An OS can do this. But it’s extremely awkward for an OS to do so in a way that is itself TPM-backed without kludging something disgusting on top of the TPM2 formats using OS-managed state, severely restricted functionality, and probably losing compatibility with the broader TPM ecosystem.

It didn’t have to be this way. The TPM authorization format could have had a field like “OS-managed identity” that the OS’s TPM stack would validate. And maybe even cool features like a standardized way for the OS to measure an application and for the application to use those measurements in its authorization. But none of this exists.

Reply on news.ycombinator.com