TPM on embedded systems: Pitfalls and caveats to watch out for • Hacker News Board

Re: TPM on embedded systems: Pitfalls and caveats to watch out for

#31

Post by amluto » Wed, Jan 21, 2026, 7:47 PM UTC

zauguin wrote: post #29

amluto wrote: post #20

Earlier quoted context omitted.

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…

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 d…

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.

Re: TPM on embedded systems: Pitfalls and caveats to watch out for

#32

Post by coppsilgold » Wed, Jan 21, 2026, 7:55 PM UTC

Note that during remote attestation you are deliberately leaking a unique static hardware ID to the one you are attesting to. There is usually some measure of indirection involved (EK -> AIK) such that additional collusion is required to recover the actual HWID (public_key of the fused Endorsement Key in the secure enclave).

Nothing prevents all the parties (the one you are attesting to and the central authority you use for indirection) to save everything and cross reference at any point in the future.

The same problem and often worse is present in DRM systems.

In the case of Widevine DRM you are actually leaking a static HWID to every license server, no collusion required. This is because there is no indirection involved, you give the license server the public key of the private key fused in the secure enclave for this purpose. The only safeguard is that every license server needs a certificate from Google to function (secure enclave will reject forming a request on invalid cert).

There are a lot of license servers.

As a side note, this is how they impose a cost on pirates. They employ forensic watermarks for the content streamed to subscribers - at the CDN level, they can do it cheaply using A/B watermarking, the cost is to store double the size of every file. When that content shows up in p2p piracy they trace it to the account and the device's DRM system public key and revoke its ability to view content (on the level of the license server) and ban the account.

Re: TPM on embedded systems: Pitfalls and caveats to watch out for

#33

Post by Foxboron » Wed, Jan 21, 2026, 8:34 PM UTC

amluto wrote: post #31

zauguin wrote: post #29

Earlier quoted context omitted.

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 d…

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.

Re: TPM on embedded systems: Pitfalls and caveats to watch out for

#34

Post by OrvalWintermute » Wed, Jan 21, 2026, 9:25 PM UTC

> Embedded devices are primarily based on Arm SoCs, in contrast to the x86/amd64-based CPUs common in PCs

ARM may have the market now… but RISC-V is the fastest growing and it may be poising to eat ARM’s lunch

Re: TPM on embedded systems: Pitfalls and caveats to watch out for

#35

Post by Avamander » Wed, Jan 21, 2026, 9:33 PM UTC

amluto wrote: post #20

pregnenolone wrote: post #8

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 w…

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…

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

Re: TPM on embedded systems: Pitfalls and caveats to watch out for

#36

Post by bri3d » Wed, Jan 21, 2026, 9:43 PM UTC

ValdikSS wrote: post #30

bri3d wrote: post #28

Earlier quoted context omitted.

You can do that on x86 too, the main difference is a combination of openness and who you need to sign an NDA with (which, granted, is a big difference, since most ARM vendors are more likely to be your friend than Intel). However, there are a ton of x86 based arcade machines, automotive systems, and so on which have secured root of trust and do not use UEFI at all. On Intel, you get unprovisioned chips and burn your…

I cracked into many x86-based arcade machines (and non-arcade gambling machines), and none of them used anything really bespoke. I never seen non-BIOS/UEFI x86 system in my life. Not going to say they are non-existent, but probably the only mention of not using UEFI on Intel chips was in the presentation of Linux optimization for automotive from Intel itself, where they booted Linux in 2 seconds from the cold boot.

I've seen the Intel bare-metal stuff in enough automotive products to call it extant in the wild; I've only heard of it being used in video arcade stuff so maybe I was misinformed there.

Anyway, I think we're both on the same page regardless that TPM and hardware root of trust are not the same thing. In some configurations TPM can (weakly) attest that the hardware root of trust is present, but it doesn't actually do any hardware trust root, and that looks architecturally very similar on x86 to how it looks anywhere else (mask ROM verifies a second bootloader against RTL or manufacturing fused chipmaker public key hash, second bootloader measures subsequent material against OEM fused key hash, and so it goes).

Re: TPM on embedded systems: Pitfalls and caveats to watch out for

#37

Post by amluto » Wed, Jan 21, 2026, 10:33 PM UTC

Foxboron wrote: post #33

amluto wrote: post #31

Earlier quoted context omitted.

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?

Re: TPM on embedded systems: Pitfalls and caveats to watch out for

#38

Post by amluto » Thu, Jan 22, 2026, 2:09 AM UTC

Avamander wrote: post #35

amluto wrote: post #20

Earlier quoted context omitted.

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…

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.

Re: TPM on embedded systems: Pitfalls and caveats to watch out for

#39

Post by mooracle » Sun, Jan 25, 2026, 11:55 AM UTC

The manufacturing paranoia is justified. I've seen IIoT setups where the contract manufacturer had full firmware access during flashing. TPM or not, if your CM has the keys at production time, you've just moved the trust boundary. What actually works: generate device credentials on-device after it leaves the factory, not during. Process design matters more than chip selection.

Re: TPM on embedded systems: Pitfalls and caveats to watch out for

#40

Post by Foxboron » Tue, Jan 27, 2026, 10:01 PM UTC

amluto wrote: post #37

Foxboron wrote: post #33

Earlier quoted context omitted.

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