Comment by pregnenolone

3 days ago

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

9 comments

pregnenolone

Reply
amluto  3 days ago

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.

  • zauguin  3 days ago

    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.

    • amluto  3 days ago

      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.

      2 replies →

  • Avamander  3 days ago

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

    • amluto  3 days ago

      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.