TPM on Embedded Systems: Pitfalls and Caveats to Watch Out For

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

> The key difference in threat models is that the device manufacturer often needs to protect their intellectual property (firmware, algorithms, and data) from the end-user or third parties, whereas on a PC, the end-user is the one protecting their assets.

I would love to see more focus on device manufacturers protecting the user instead of trying to protect themselves.

Prime example where the TPM could be fantastic: embedded devices that are centrally coordinated. For example, networking equipment. Imagine if all UniFi devices performed a measured boot and attested to their PCR values before the controller would provision them. This could give a very strong degree of security, even on untrusted networks and even if devices have been previously connected and provisioned by someone else. (Yes, there’s a window when you connect a device where someone else can provision it first.

But instead companies seem to obsess about protecting their IP even when there is almost no commercial harm to them when someone inevitably recovers the decrypted firmware image.

Note that it's really easy to conflate TPM and hardware root of trust (in part because UEFI Secure Boot was awfully named), and the two things are linked _only_ by measurements.

What a TPM does is provides a chip with some root key material (seeds) which can be extended with external data (PCRs) in a way which is a black box, and then that black box data can be used to perform cryptographic operations. So essentially, it is useful only for sealing data using the PCR state or attesting that the state matches.

This becomes an issue once you realize what's sending the PCR values; firmware which needs its own root of trust.

This takes you to Intel Boot Guard and AMD PSB/PSP, which implement traditional secure boot root of trust starting from a public key hash fused into the platform SoC. Without these systems, there's not really much point using a TPM, because an attacker could simply send the "correct" hashes for each PCR and reproduce the internal black-box TPM state for a "good" system.

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.

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.

> 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

Sigma-star does many very high quality embedded blog posts, and touches not popular and hardly discussed topics pretty in-depth.

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