It would be a nice addition if big tech didn't abuse this to shove user-hostile software into devices which the user has paid for (like smartphones).. thanks to this attitude, whenever I see "remote attestation" I associate this with "hostile"..
> Using a TPM, we can remotely, cryptographically prove a couple of things:
> whenever I see "remote attestation" I associate this with "hostile"
HN is bizarre. This is just standard infrastructure security practice at any tech company of meaningful size. You are misunderstanding the target use case and audience of this article.
The user is choosing to use apps that do remote attestation against the user's will. You can live a perfectly normal life without apps. It's quite annoying that I can't watch full-quality Netflix or use Google Pay on my rooted smartphone, but I'll survive.
TPM's, just like Secure Boot for that matter, can be an amazing security boon if used right. The APIs have been there for ages but only companies like Apple, Google, and Microsoft have started using them because every time someone from the open source community suggests using these technologies you get flooded with people raging on forums about how big tech is coming to subdue us and eat our babies.
You can use this technology to verify that nobody has inserted a Microsoft bootloader into your boot process, or to ensure that only your GrapheneOS smartphone is able to connect to your WiFi. You can make it so border control guards/airport security cannot dump your hard drive and connect to your VPN. The same technology that allows Microsoft to lock down employee laptops can be used to lock out the people that want to threaten your freedom.
> Unless there are exploits..
Everything with a computer in it is unusable if you accept "there may be exploits" as a counterargument. You cannot trust Signal's encryption because there may be exploits. You cannot trust your doctor's heart rate monitor because there may be exploits. You cannot trust your car's speedometer because there may be exploits. You cannot trust your browser to read HN, because there may be exploits.
>But what about attacks after boot? That’s your EDR’s problem. Trusted boot provides the bedrock to build a bunch of other primitives on top of. Including cryptographic proof your EDR is installed and running (at boot), immutable filesystems (verified at boot), signed upgrades, confidential computing, etc. Without it you can’t trust your hosts themselves and can’t make further security guarantees. Houses built on sand and all that.
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)
We use SPIFFE/SPIRE at work. It works well for our use case, remote embedded workflows that need to phone home. It's very exacting: everything must be exactly right for the attestation to succeed. So it takes extra effort when you commit to that path.
It's a nice idea, but I wouldn't design any system on the assumption that a TPM needs to stay secure for the system to be safe. There's been so many exploits. We can consider the iphone as an R & D platform for doing blackbox computations. In that nothing is allowed to run that Apple doesn't want. Protecting that is apples bread and butter and they care about it enough to value critical exploits in the millions. Yet people still find them all the time. I feel like if a company that invests millions in the concept can't make it secure then the concept probably isn't that great.
Waiting for when one can't boot Windows without running snitch software which analyzes everything you do first to ensure you aren't a pedophile then that you aren't a terrorist then that aren't disloyal or un-American.
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!
This is the dream of corporate authoritarians everywhere. The dystopian nightmare we all warned about because we saw it coming. "Security" is the "think of the children" fearmongering of the current environment.
As one of our Founding Fathers put it: "Those who give up freedom for security deserve neither."
Attestation of any type: A double edged sword, where you are guaranteed to lose freedom. Attestation entrenches, empowers, and enriches other entities that aren't you.
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...
The German Healthcare System is moving to the TelematikInfrastruktur 2.0, which has foundations in Zero Trust security, which includes also remote attestation and proof with TPM.
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.
Something worth calling out is that, as far as I've seen, most server TPM implementations are not great against physical access attacks. If servers might be physically compromised (eg. you are leaving a server unsupervised in a colo) shenanigans are still possible.
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.
GrapheneOS has an implementation of this with their Auditor app. You can use their service or you can use another Android. No freedom lost, just security gained.
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.
The auditor app itself does not result in any loss of freedom, but the widespread availability of remote attestation mechanisms on end-user devices incentivizes others to use it in a manner that does.
A purely local mechanism that lets the user check the integrity of their system is great. Making it easy for third parties to inspect it is a severe violation of user freedom and privacy.
I don't understand how this stuff prevents me from MITM:ing the attestation and routing requests to another device that is clean and attested? I.e. how do you know that the remote TPM belongs to the device you're talking to?
17 comments
[ 4.2 ms ] story [ 39.1 ms ] thread> Using a TPM, we can remotely, cryptographically prove a couple of things:
Unless there are exploits..
HN is bizarre. This is just standard infrastructure security practice at any tech company of meaningful size. You are misunderstanding the target use case and audience of this article.
TPM's, just like Secure Boot for that matter, can be an amazing security boon if used right. The APIs have been there for ages but only companies like Apple, Google, and Microsoft have started using them because every time someone from the open source community suggests using these technologies you get flooded with people raging on forums about how big tech is coming to subdue us and eat our babies.
You can use this technology to verify that nobody has inserted a Microsoft bootloader into your boot process, or to ensure that only your GrapheneOS smartphone is able to connect to your WiFi. You can make it so border control guards/airport security cannot dump your hard drive and connect to your VPN. The same technology that allows Microsoft to lock down employee laptops can be used to lock out the people that want to threaten your freedom.
> Unless there are exploits..
Everything with a computer in it is unusable if you accept "there may be exploits" as a counterargument. You cannot trust Signal's encryption because there may be exploits. You cannot trust your doctor's heart rate monitor because there may be exploits. You cannot trust your car's speedometer because there may be exploits. You cannot trust your browser to read HN, because there may be exploits.
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)
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.
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...
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.
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.
https://attestation.app/about
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...
A purely local mechanism that lets the user check the integrity of their system is great. Making it easy for third parties to inspect it is a severe violation of user freedom and privacy.
> Uses a lot of acronyms without even saying what they stand for let alone an explanation
> Article entirely unhelpful
Many such cases