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

#21

Post by Nextgrid » Wed, Jan 21, 2026, 6:13 PM UTC

RedShift1 wrote: post #9

bangaladore wrote: post #6

Earlier quoted context omitted.

It doesn't help that the TPM spec is so full of optional features (and the N spec versions), so it's often annoying to find out what the vendor even supports without signing an NDA + some. TPMs work great when you have a mountain of supporting libraries to abstract them from you. Unfortunately, that's often not the case in the embedded world.

Even on desktop it's terrible, I wanted to protect some private keys of a Java application but there is no way to talk to a TPM using Java so handsandshouldersup gesture.

The TPM needs a way to authenticate your Java application, since the TPM otherwise does not know whether it's actually talking to your application or something pretending to be it.

This means you generally need an authenticated boot chain (via PCR measurements) and then have your Java app "seal" the key material to that.

It's not a problem with the TPM per-se, it's no different if you were using an external smartcard or HSM - the HSM still needs to ensure it's talking to the right app and not an impersonator (and if you use keypair authentication for that, then your app must store the keypair somewhere - you've just moved the authentication problem elsewhere).

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

#22

Post by astrobe_ » Wed, Jan 21, 2026, 6:14 PM UTC

jhallenworld wrote: post #10

Do you really need a TPM if you have something like ARM TrustZone?

I think the general problem is that SoC-based security relies on internal "fuses" that are write-once, as the name suggests, which usually means that they are usable by the manufacturer only.

TPMs can be reprogrammed by the customer. If the device needs to be returned for repairs, the customer can remove their TPM, so that even the manufacturer cannot crack open the box and have access to their secrets.

That's only theory though, as the box could actually be "dirty" inside; for instance it could leak the secrets to obtained from the TPM to mass storage via a swap partition (I don't think they are common in embedded systems, though).

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

#23

Post by [deleted] » Wed, Jan 21, 2026, 6:29 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…

[deleted]

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

#24

Post by stefan_ » Wed, Jan 21, 2026, 6:31 PM UTC

ValdikSS wrote: post #11

jhallenworld wrote: post #10

Do you really need a TPM if you have something like ARM TrustZone?

Sure, why not? You have a reference implementation for both TrustZone OP-TEE (from Microsoft!) and in-Linux-kernel. No need to code anything, everything is already there, tested and ready to work. https://github.com/OP-TEE/optee_ftpm Or you mean dedicated TPM?

As I understand it, you can not actually deploy a fTPM (in embedded and other scenarios) unless you run your own full PKI and have your CA signed off by Microsoft or some other TPM consortium member. So sure the code exists, but it's also just a dummy implementation, and for any embedded product that is not super cost conscious I will forever recommend to just buy the $1 chip, connect it via SPI and live happily ever after. Check the box, in embedded most non-technical people can't even begin to understand what FDE means anyway.

If you don't need the TPM checkbox, most vendors have simple signing fuses that are a lot easier than going fTPM.

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

#25

Post by plagiarist » Wed, Jan 21, 2026, 6:56 PM UTC

bangaladore wrote: post #5

dfajgljsldkjag wrote: post #2

It is wild that session encryption is not enabled by default on these chips. I feel like most vendors just slap a tpm on the board and think they are safe without actually configuring it properly. The article is right that physical access usually means game over anyway so it seems like a lot of effort for a small gain.

In many industries, once someone has physical access to a device, all bets are off. And when used correctly, TPMs can provide tons of value even when not encrypting the bus.

Yes, definitely. I would use a TPM on a Pi device regardless of the imperfections if I could find one for a normal price. My threat model is that I don't store anything sensitive on the device but as a guardrail it also cannot be trivially decrypted without the hardware token.

I am using TMP for this on x86 machines that I want to boot headless. If I need to replace the disk I can just do a regular wipe and feel pretty comfortable.

I'd use a Yubikey or other security token with the Pi, but the device needs to boot without user intervention and the decryption code I'm aware of forces user presence whether or not the Yubikey requires that.

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

#26

Post by ValdikSS » Wed, Jan 21, 2026, 7:04 PM UTC

bri3d wrote: post #16

ValdikSS wrote: post #14

Earlier quoted context omitted.

Well, you have much more control of lower-level boot process on ARM chips, and each of the SoC manufacturers have their own implementation of Trusted Boot which relies on the cryptography and secrets inside the SoC rather than TPM as in x86/UEFI boot process. In context of trusted boot — not much. If your specific application doesn't require TPM 2.0 advanced features, like separate NVRAM and different locality levels…

> their own implementation of Trusted Boot which relies on the cryptography and secrets inside the SoC rather than TPM as in x86/UEFI boot process. TPM and x86 trusted boot / root of trust are completely separate things, linked _only_ by the provision of measurements from the (_presumed_!) good firmware to the TPM. x86 trusted boot relies on the same SoC manufacturer type stuff as in ARM land, starting with a fused p…

On ARM, you control the whole boot process on many SoCs, and can make your own bespoke secure/trusted/measured boot chain, starting from bootrom to the very latest boot stages (given that your SoC manufacturer has root of trust and all the documentation on how to use it), without TPM.

You more or less can't do that on x86, and have to rely on existing proprietary code facilities to implement measured boot using TPM (as the only method), for which you can implement trusted boot, using TPM and all the previous measures proprietary code made to it.

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

#27

Post by bri3d » Wed, Jan 21, 2026, 7:05 PM UTC

jhallenworld wrote: post #10

Do you really need a TPM if you have something like ARM TrustZone?

They're different problem spaces, TrustZone is a trusted execution environment and TPM is an API for performing key storage and attestation which revolves around system state (PCRs).

Essentially, TPM is a standardized API for implementing a few primitives over the state of PCRs. Fundamentally, TPM is just the ability to say "encrypt and store this blob in a way that it can only be recovered if all of these values were sent in the right order," or "sign this challenge with an attestation that can only be provided if these values match." You can use a TEE to implement a TPM and on most modern x86 systems (fTPM) this is how it is done anyway.

You don't really need an fTPM either in some sense; one could use TEE primitives to write a trusted application that should perform similar tasks, however, TPM provides the API by which most early-boot systems (UEFI) provide their measurements, so it's the easiest way to do system attestation on commodity hardware.

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

#28

Post by bri3d » Wed, Jan 21, 2026, 7:11 PM UTC

ValdikSS wrote: post #26

bri3d wrote: post #16

Earlier quoted context omitted.

> their own implementation of Trusted Boot which relies on the cryptography and secrets inside the SoC rather than TPM as in x86/UEFI boot process. TPM and x86 trusted boot / root of trust are completely separate things, linked _only_ by the provision of measurements from the (_presumed_!) good firmware to the TPM. x86 trusted boot relies on the same SoC manufacturer type stuff as in ARM land, starting with a fused p…

On ARM, you control the whole boot process on many SoCs, and can make your own bespoke secure/trusted/measured boot chain, starting from bootrom to the very latest boot stages (given that your SoC manufacturer has root of trust and all the documentation on how to use it), without TPM. You more or less can't do that on x86, and have to rely on existing proprietary code facilities to implement measured boot using TPM (…

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 KM hash into the PCH FPFs to advance the lifecycle state at EOM, which is basically the same thing you'd do with most ARM SoCs.

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

#29

Post by zauguin » Wed, Jan 21, 2026, 7:17 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…

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.

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

#30

Post by ValdikSS » Wed, Jan 21, 2026, 7:40 PM UTC

bri3d wrote: post #28

ValdikSS wrote: post #26

Earlier quoted context omitted.

On ARM, you control the whole boot process on many SoCs, and can make your own bespoke secure/trusted/measured boot chain, starting from bootrom to the very latest boot stages (given that your SoC manufacturer has root of trust and all the documentation on how to use it), without TPM. You more or less can't do that on x86, and have to rely on existing proprietary code facilities to implement measured boot using TPM (…

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.