Remote Attestation
liamcvw.com
liamcvw.com
> Using a TPM, we can remotely, cryptographically prove a couple of things:
Unless there are exploits..
Yes, there can be exploits, but hardware exploits over a restricted interface (TPM2) are significantly rarer then normal software vulns. Everything is about risk mitigation, there is no perfect security.
I'd not be able to put up with that, but more importantly, I'd not want to be in the position where I can't even protest anything because there's no alternative to switch to..
I'm not talking about desktop because this is not where remote attestation is used by them.
That is, the thing that people are actually talking about when they use that term: The means for companies and governments to usurp the ownership of consumer devices.
I'd read the confidential computing post! (used to work in this space myself)
SGX does not cryptographically guarantee this. It cryptographically guarantees that the processor contains a legitimate provisioning key signed by Intel. Intel pinky promises that its processor will then only use this provisioning key in certain ways. This promise is essentially unauditable, and previous SGX bugs have shown that Intel isn't really in a position to make it anyway.
The most likely attacks on Signal involve trusted insiders or configuration errors, and SGX mostly prevents these, since to exploit it, you'd need to bribe insiders in both Signal and Intel, or find configuration errors in both of their software stacks.
Collusion is certainly still possible, but it's much harder to pull off, since it typically requires nation-state-level resources to exploit. Signal does actually have nation-state adversaries, but the vast majority of other software projects don't.
(I personally think that remote attestation is the single biggest risk to the free software movement, but I begrudgingly accept that Signal is a very good use case for it.)
Since there have been multiple SGX key extraction vulnerabilities already, all you would have to do is compromise Signal and then use the key extracted from any of those devices, and "compromise Signal" is the same thing you would have to do if they weren't using SGX at all.
Since there have been with bypass on service X, we should remove auth because all you need is the vulnerability.
Address space layout randomization wouldn't exist with this mindset, and yet it does and helps for many exploits.
SGX is not fully secure. But neither are the other part of the stack. Security (or trust in this case) is done through layers because it's a question of when you'll be vulnerable, not ifs.
The only way to make remote attestation into a neutral technology is to prohibit privileged keys being loaded (and retained) by device manufacturers. This would make it impossible for arbitrary protocol counterparties to know if their attestation requests are being answered by hardware, or merely emulated in software. This approach is the only way to preserve computing freedom (ie the very concept of protocols that mediate between mutually-untrusting parties) in the presence of this technology.
One of the valid use cases on consumer devices is video game anti-cheat software. Theoretically remote attestation can enable them to be less invasive.
With enterprise devices you can enroll a specific device and only allow its key. Someone who finds a vulnerability in a different device model, or even the same device model when they don't have one of your actual devices, can't use it because it's not enrolled. (That doesn't actually require remote attestation, the same works without any kind of TPM, but it mitigates a gaping hole that remote attestation has otherwise.)
Because in the video game case the cheater can choose whatever device they want, so they choose one with a vulnerability, which the developers can't prevent without blocking the millions of innocent people who have the same hardware. It's also the solution to yesterday's problem because cheaters are now using cheat hardware that acts as a user input device, and then attesting to what software is running buys you nothing because the cheating is happening in hardware.
> It's also the solution to yesterday's problem because cheaters are now using cheat hardware that acts as a user input device
Cheats like these are not as devastating to the game as the ones that read or manipulate memory in the game process itself. You can't see people through walls with cheat hardware acting as a user input device (IOMMU should prevent DMA cheats but those aren't user input devices).
[1] https://xcancel.com/riotgames/status/2069829543276216564
Only on Windows, and then we're back to the thing being a net negative for the consumer again. Also not proven that it's actually effective, in which case we get the cost without the benefit.
> Cheats like these are not as devastating to the game as the ones that read or manipulate memory in the game process itself.
It allows aimbots and the like which are the most common form of cheating and more than enough to destroy the game for other players.
> You can't see people through walls with cheat hardware acting as a user input device (IOMMU should prevent DMA cheats but those aren't user input devices).
For which they can use different cheat hardware.
It's unclear how IOMMU is supposed to prevent this since many hardware devices actually need to access the relevant memory locations, e.g. your drive is going to write directly to the game's memory because that's how the game's code/data gets into memory to begin with or gets reloaded after being evicted when the user doesn't have unlimited RAM.
On top of that, the cheat hardware could attach to the memory slots. Consumer PCs often don't support memory encryption and it wouldn't work for this anyway, since memory encryption is meant for cold boot attacks or similar rather than live analysis/modification. The performance requirements of RAM require block modes like XTS which allow replay attacks (undo cheats) and data flow analysis. Or worse, they just use a replay attack to get ACE on the device that passes attestation.
Attempting to secure a device in the physical possession of the attacker is very challenging and in general should not be the basis of anything you intend to actually be secure.
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.
But it's also useful for DRM stuff like authorized 4k blu-ray playback on PCs... which is only allowed on systems with Intel SGX.
The problem is, the same features we want for infrastructure are automatically being abused to restrain our consumer hardware - and to make it worse, for barely a good reason at all.
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.
True. But my impression is that the whole TPM ecosystem is poorly documented. Maybe I just don't know where to look. But to me TPMs are still mostly a black boxes that prevent me from installing Linux unless I disable secure boot.
To benefit the most from security, you need to understand what the security mechanisms can and cannot do. And I feel that there is no good explanation out there to get starting with playing around with TPMs. If you already work at a big tech company, then you can probably find a mentor who might even have contributed to the TPM standards. But if you don't, then it seems to be really hard to properly learn how TPMs can be used.
Then I think you misunderstand what TPMs are. Secure boot works without TPMs and TPMs are usuable without secure boot. I have secure boot disabled on my laptop (until I have time to figure out how to generate my own keys reliably) but store my SSH keys on the TPM. You can also set up secure boot without ever initializing the TPM.
As for the documentation, the entire interface and the operations it can perform are well-documented: https://trustedcomputinggroup.org/resource/tpm-library-speci... Every command, response, and the logic behind the operation are written out. There's no need to write your own TPM driver, of course; software like https://tpm2-software.github.io/ makes the entire process quite easy. The project even has bash scripts explaining how to do things like storing secrets in the TPM using.
The TPM itself can do multiple things (storing secrets with or without a password ("PIN"), applying brute-force protection, using "measurements" submitted by the OS and firmware as a requirement for unlocking secrets, doing cryptographic operations, random number generation) but most often it's just used to store a key and then keep it locked away from the rest of the computer until you've proven that you're the user/OS that has put the key in there. Combine that with something like disk encryption, or managing a certificate, and you've got a way to protect against even some kernel-level malware.
This is getting outdated extremely fast.. Have you heard about at least:
- banking apps being required to do transfers (web login is "insecure")
- government apps in Italy/Brazil enforcing Play Integrity?
- EUDI/age verification, where even EU apps are enforcing Play Integrity?
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...
As far as I can tell, it flags unlocked bootloaders? So this is already huge freedom lost.
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.
There's also Memory Integrity Enforcement on the iPhone 17 chips which makes all memory exploits detectable by the OS so it can trigger a reboot and report the bug to Apple.
And even when exploits are found, the boot chain attestation means rebooting your iphone always clears out any malware that made it past normal sandboxing. Particularly at risk individuals should enable lockdown mode and periodically reboot.
The main attack left is brute forcing the lock screen password and bypassing the cooldown timer. This seems to be the method most used for getting access to phones. This is defeated by having an actual text password rather than the 6 digit password.
So yes they have advanced hacking tech, but the iphone security is remarkably effective and as a user there are a couple of simple measures that make it pretty much unbreakable.
If you believe you are at risk of having your phone taken and plugged in to a Cellebrite like device, enable Lockdown Mode, set a good password and if possible hit the power button 5 times to disable face id.
Notice also that remote attestation doesn't enable that. The device can never do that itself since if it was compromised it would just display "attestation passed" on the screen without actually doing it.
When the reality is the iPhone is actually quite a good example that great security is possible with enough investment.
Nobody was ever claiming that. The claim is that because it isn't bulletproof, remote attestation is pointless, since it has a different failure mode where once keys can be extracted the attacker can't be deprived of them, so there is no way to return the installed base of existing devices to a state of being able to trust their attestations.
I had a calendar malware that I had to remove from my sister's iphone just last year.
There's been also (and still exists) fake apps pushed with appstore ads, not sure if you count this or not.
and neither do thousands of “fake apps” that no one installs
The calendar malware pushes garbage ad notification in loops on the iphone and is triggered without user intent.
And then it's not just "fake apps" but apps designed to steal your credentials appearing at the top of the appstore.
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.
Isn't that what you want on that platform? ADCS even supports issuing remote-attested TPM certs via EK, no need to reinvent the wheel.
> on Linux and Mac exists own OS solutions/access.
I'm not sure what the story is on MacOS, but on Linux the options are definitely lacking. From what I can tell, tpm2-openssl is the most mature solution, but that doesn't support binding to PCRs at all, and validating EK signatures on the server side is left as an exercise to the reader.
> Implementing it isn't trivial at all, otherwise you would already seen (not vibe-coded) open source implementions spawning on GitHub.
If I had to guess, I'd say another issue is that TPM remote attestation is seen as an "enterprise" feature. Open source projects like smallstep support it, but only via their paid enterprise offerings.
This is really cool. Did not know about it: https://learn.microsoft.com/en-us/windows-server/identity/ad...
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)
Remote attestation reveals the fact the computer belongs to corporations and governments. The user's attempts to claim ownership are "tampering".
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.
> 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.
Also, isn't the EK (and therefore its cert) unique per-device, allowing you to tell it apart? The fact that the manufacturer used the same upstream key to sign both certs doesn't matter, just like a CA can sign multiple TLS certs with one root key.
The point I was making was about registering new EKs/certs into your set of trusted servers. While you can tell the TPMs apart from each other, knowing the EK/cert belongs to your hardware's TPM vs someone else's is the tricky part.
PC hardware still isn't tamper resistant though. Memory may be encrypted but its contents can be tampered with in other ways. Only SGX made a serious attempt to be tamper resistant, although Intel eventually sacrificed that to boost performance.
This is what some smartphones seem to do. I don't know if server motherboards do it but it would help a lot against this kind of attack.
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...
> If your infra consistently enforces mTLS
This is for mutual authentication in corporate infrastructure. Attestation is a critical security property for these environments.
No it's not. Every corporate network to which I've connected worked just fine without it.
Just because it appears to be working fine doesn't mean you are in control of it. Without hardware attestation, how do you know the machines are running the software you think they are?
As one of our Founding Fathers put it: "Those who give up freedom for security deserve neither."
Remote Attestation: Just Say No.
Ensuring our remote employees’ machines are secure is a serious problem for us, and it’s absolutely impossible to require employees to be diligent. We require attestation upon connection to our corporate VPN that checks for basic things such as latest security patches, certain tools installed, etc.
It's not that remote attestation can't be used for good. Obviously it can. It's that there's so many ways we can use it for evil, and given the track the world is on, it's quite obvious it will be.
If your device will attest that it's running their code then they refuse access to the service under any other conditions, and then you can't do any of those things because their code won't allow it.
It's also a huge antitrust problem because it precludes new independent platforms from being used, since it cements the chicken and egg problem that people won't use a device that can't access existing services and the services won't support a system nobody uses. In other words, WINE is banned and Firefox is banned and everyone is stuck with IE/Edge on Windows forever.
I think you have a fair use-case when you think about corporate machines, that are not personal devices. However, the more this type of remote attestation is used, the more likely it is that politicians will also require it on private machines, because "we have the technology". And then you won't be able to run any software that you want, because it could potentially be used for serious crimes like pirating music.
Ben Franklin understood that and so included qualifiers in the quote, which was "Those who would give up essential Liberty, to purchase a little temporary Safety, deserve neither Liberty nor Safety".
> If your infra consistently enforces mTLS
For example mutual TLS enforcement is something that can happen on my phone to prevent me reading what an app is uploading. It prevents me from auditing things, at least as easily as it used to be: add your key to the trusted keys list and see if e.g. a claim about on-device processing is true. It isn't only the corporate world that uses it, or at least, not only on their own devices