Hacker News Reader

Comment by pregnenolone | Hacker News Reader

They’re useful for attestation, boot measurement, and maybe passkeys, but I wouldn't trust them to securely handle FDE keys for several reasons. Not only do you have to trust the TPM manufacturer – and there are many – but they also have a bad track record (look up Chris Tarnovsky’s presentation about breaking TPM 1.x chips). While parameter encryption has been phased out or not used in the first place, what's even worse is that cryptsetup stores the key in plaintext within the TPM, and this vulnerability remains unaddressed to this day.

https://arxiv.org/abs/2304.14717

https://github.com/systemd/systemd/issues/37386

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

View on HN

My pet peeve is that the entire TPM design assumes that, at any given time, all running software has exactly one privilege level.

It’s not hard to protect an FDE key in a way that one must compromise both the TPM and the OS to recover it [0]. What is very awkward is protecting it such that a random user in the system who recovers the sealed secret (via a side channel or simply booting into a different OS and reading it) cannot ask the TPM to decrypt it. Or protecting one user’s TPM-wrapped SSH key from another user.

I have some kludgey ideas for how to do this, and maybe I’ll write them up some day.

[0] Seal a random secret to the TPM and wrap the actual key, in software, with the sealed secret. Compromising the TPM gets the wrapping key but not the wrapped key.

Can't that just be done by sealing to PCRs? By protecting the unsealing key with PCR which depends on the OS (I usually use the secure boot signing key PCRs since they are different between systems and stable across updates) and some PCR which gets extended by the OS (or for stuff stored in NV making it readlocked during boot). Then any process that launches later can no longer access it and booting another OS also doesn't help.

That helps with FDE (except to the extent that one might want to connect an encrypted device after boot), but it doesn't help in the slightest with SSH keys. The TPM has nothing remotely resembling per-user PCRs.

> The TPM has nothing remotely resembling per-user PCRs.

The system could extend one of the PCRs, or an NVPCR, with some unique user credential locked to the user directory. Then you can't recreate the PCR records in any immediate way.

But you can't just recreate a key under one of the hierarchies anyway. You still need to posses the keyfile.

> The system could extend one of the PCRs, or an NVPCR, with some unique user credential locked to the user directory. Then you can't recreate the PCR records in any immediate way.

Sure, but can the system context-switch that PCR between two different users?

> Sure, but can the system context-switch that PCR between two different users?

Right, no it can't.

But this was not really something the TPM was suppose to solve.

How could the TPM ever have an idea or be able to verify the other sides' privilege level, besides knowing that the other side is able to access it (the TPM)?

Off the top of my head, here are some options. They all boil down to having a privileged driver talk to the TPM and less privileged programs mediate their access through the driver.

1. Have some PCRs that are not in the TPM at all but instead have their values sent from the driver along with any command that references them.

2. Have some policy commands that are aimed at the driver, not the TPM. The TPM will always approve them, but they contain a payload that will be read and either accepted or rejected by the driver.

3. Have a way to create a virtual TPM that is hosted by the real TPM and a way to generate attestations that attest to both the real TPM part (using the real TPM's attestation key hierarchy and whatever policy was needed to instantiate the virtual TPM) and to the virtual TPM's part of the attestation. And then give less-trusted code access only to the virtual TPM.

#3 would be very useful for VMs and containers and such, too.

Root-of-trust measurement (RTM) isn't foolproof either.

https://www.usenix.org/system/files/conference/usenixsecurit...

Reply on news.ycombinator.com