Hacker News Reader

Comment by dfajgljsldkjag | Hacker News Reader

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.

View on HN

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.

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

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.

Reply on news.ycombinator.com