[zb3]

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:

Unless there are exploits..

[jeroenhd]

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.

[zb3]

> You can live a perfectly normal life without apps.

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?

[vaylian]

> The APIs have been there for ages

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.

[jeroenhd]

> But to me TPMs are still mostly a black boxes that prevent me from installing Linux unless I disable secure boot.

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.

[solenoid0937]

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

[toast0]

It's absolutely useful for corporate owned infrastructure.

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.

[justincormack]

Thats not true. Almost no consumer systems ship with SGX.

[mschuster91]

> This is just standard infrastructure security practice at any tech company of meaningful size.

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.

[gspr]

It is true that it is pretty common in large companies. It is also true that it feels very hostile to some people (myself included).

[solenoid0937]

The audience of this article are people working with infrastructure, not people developing user facing products. See quote: "If your infra consistently enforces mTLS ..."

[UltraSane]

Exactly. Remote attestation is nothing more than an elaborate hashing and signing scheme using trusted hardware and is VERY useful.

[lcvw]

I mean, all tech can be used in different ways. My experience has been much more on the preventing root kits side, rather then vendor lock in.

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.

[GreenVulpine]

Make no mistake. Shoving user-hostile malware down people's throats is the primary use case for this in the consumer space. Bootloader malware is very esoteric right now. Enterprise might have valid use cases beyond screwing people but none of them make sense for a consumer device.

[mjg59]

You say that, and also remote attestation is how Signal knows it's talking to a legitimate SGX enclave running the expected payload

[mindslight]

Being able to come up with compelling use cases for a technology does not redeem that technology from creating a terrible power imbalance that incentives will mean is inevitably abused. Whenever anyone hears "remote attestation", they should think of the already-pervasive Cloudflare CAPTCHA nagwalls, and then think of those becoming something you can only get past by buying a new computer running a proprietary locked-down OS and browser.

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.

[greyface-]

> running the expected payload

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.

[gucci-on-fleek]

You are 100% correct, but this is still mostly fine: without SGX, you need to completely trust Signal, since it could trivially modify the server-side code. But with SGX, you only need to trust that Signal and Intel won't both collude.

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

[AnthonyMouse]

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

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.

[greyface-]

The path to compromise that you describe exists, of course. But it's not the only way. For example, a zero-day in SGX combined with privileged access to AWS infrastructure could compromise Signal's SGX setup without any knowledge or collusion by Signal or Intel. As you note, it is not unreasonable for a project of Signal's stature to expect to face adversaries with such capabilities.

[Zak]

There's some value in that, but Signal's main security proposition is that you don't have to trust the infrastructure. E2EE means even compromised server software can't read message contents.

[gruez]

He's talking about contact discovery, which can't be solved by just slapping e2ee on it

[lcvw]

I definitely want to do a post on confidential computing as well. Super cool stuff.

[throwaway7679]

Maybe you could do a post on... remote attestation.

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.

[bobbiechen]

Oh yeah, just like all cryptography is just a way for bad people to hide their criminal activity.

I'd read the confidential computing post! (used to work in this space myself)

[lcvw]

I think consumer devices should have opt-outs for sure. But personally I am much more comfortable with myself and my family having fully locked down apple phones then anything else on the market right now, precisely because of how difficult it is to get persistent malware into that ecosystem.

[ls612]

I get this argument and tell my parents (who know nothing about tech) to get iPhones for this reason but as an economist it is obvious to me the political economy equilibrium implications of this technology are an extreme centralization of power. We are one Covid-like crisis/moral panic away from a regime of only government licensed devices with identity and software integrity attestation can use the internet, and the masses will cheer on the prosecution of the tech nerds who try to circumvent it.

[zb3]

Out of curiosity, do you like ads? I assume you don't.. so how would you react if Apple followed Google and prohibited ad blocking apps + removed that capability from web browsers?

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

[what]

When did google prohibit ad blocking in their browser?

[AnthonyMouse]

https://9to5google.com/2026/06/15/google-chromes-next-update...

[zb3]

The moment they decided not to add extension support to their mobile browser.

I'm not talking about desktop because this is not where remote attestation is used by them.

[Rohansi]

> none of them make sense for a consumer device.

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.

[AnthonyMouse]

That's the use case it can't really work for.

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.

[Rohansi]

Riot Games relaxed the requirements of their Vanguard anticheat by requiring TPM attestation among other things [1].

> 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

[AnthonyMouse]

> Riot Games relaxed the requirements of their Vanguard anticheat by requiring TPM attestation among other things

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.