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

16 points by Deeg9rie9usi 2 days ago | 9 comments

dfajgljsldkjag 2 hours ago |
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.
derekerdmann an hour ago |
If I remember correctly it's up to the client program to set up the session, not something to do with the vendor's implementation. It's conceptually similar to how an HTTPS client performs a TLS handshake after opening a socket before it can work with plain HTTP content.
bangaladore 42 minutes ago |
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.
RedShift1 20 minutes ago |
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.
bangaladore 43 minutes ago |
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.
amluto an hour ago |
> 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.
ValdikSS 39 minutes ago |
Sigma-star does many very high quality embedded blog posts, and touches not popular and hardly discussed topics pretty in-depth.
pregnenolone 33 minutes 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
jhallenworld 10 minutes ago |
Do you really need a TPM if you have something like ARM TrustZone?