There's also Android's hardware attestation API which apps can use to verify integrity in a more secure and privacy-respecting way than Google Play Integrity. An increasing number of apps are officially supporting GrapheneOS through this, and that number will only grow as GrapheneOS gains users.
https://grapheneos.org/articles/attestation-compatibility-gu...
I had made a dummy client as example and I must say that on development perspectives, it is wild.
There are some Go libraries, which support only RSA instead of EC for TPM Keys, on the C++ side you get most of results in Windows through the CryptoProvider, on Linux and Mac exists own OS solutions/access.
Implementing it isn't trivial at all, otherwise you would already seen (not vibe-coded) open source implementions spawning on GitHub.
Good take - remote attestation doesn't solve all problems on its own but it is a very powerful tool in the platform security toolbox (and very cool "to boot" :P)
> Uses a lot of acronyms without even saying what they stand for let alone an explanation
> Article entirely unhelpful
Many such cases
The TPMs are on separate chips from the main processor. If something were to man-in-the-middle the communications with the TPM, the hash digests can be "corrected" so the TPM thinks the boot artifacts were in the intended state. At least the ones I've worked with were SPI, but I've seen I2C ones as well. Either way, these are low speed, easy to mess with buses.
Also you want to pay real close attention to how you onboard new devices. The article states
> The EK comes with a x509 cert signed by the manufacture’s PKI. So the EK proves the TPM is legit.
This lets you know the TPM you are performing remote attestation of is made by a particular manufacturer, but an attacker can go buy a TPM chip from the right manufacturer off digikey, and feed it the intended hashes in pcr extend commands. For the attacks the TPM is supposed to prevent, you have to assume they could re-direct the tpm requests your remote validation service is trying to run to their own device by compromising the boot artifacts. You still have to figure out how to make sure your workflows are onboarding the TPM from _your_ hardware, not just a TPM from the same manufacturer.
Ironic how this post got upvoted in parallel to polar opposite in the #1 slot: "John Deere owners will get the right to repair equipment under FTC settlement" https://news.ycombinator.com/item?id=48838876
Engineers may debate about what-about-isms of vulnerabilities and counterexamples of TPM failures, but that misses the point: We should be debating about where society will be when devices you paid for serve other masters.
Probably we should just write/vibe/demand better software. Otherwise we're going to end up with a law demanding TPMs that watch more than just your firmware...
> Using a TPM, we can remotely, cryptographically prove a couple of things:
Unless there are exploits..
You won't be able to send email or bank if you aren't running the snitch or any configuration where you could defeat it.
Hell in a boring dystopia run by adults this could theoretically be a good thing! Never miss the next obvious school shooter!
Then look at who actually runs our country.
As one of our Founding Fathers put it: "Those who give up freedom for security deserve neither."
Remote Attestation: Just Say No.