9 ms·

Remote Attestation

110 points by lcvw 2mo ago

zb3 2mo ago
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..
- lcvw 2mo ago
  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 2mo ago
    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.
    - lcvw 2mo ago
      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 2mo ago
        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 2mo ago
        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 2mo ago
        When did google prohibit ad blocking in their browser?
        AnthonyMouse 2mo ago
        https://9to5google.com/2026/06/15/google-chromes-next-update-will-mark-the-end-of-popular-ad-blockers/ https://9to5google.com/2026/06/15/google-chromes-next-update...
        zb3 2mo ago
        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.
    - mjg59 2mo ago
      You say that, and also remote attestation is how Signal knows it's talking to a legitimate SGX enclave running the expected payload
      - lcvw 2mo ago
        I definitely want to do a post on confidential computing as well. Super cool stuff.
        throwaway7679 2mo ago
        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 2mo ago
        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)
      - greyface- 2mo ago
        > 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 2mo ago
        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.)
    - Rohansi 2mo ago
      > 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 2mo ago
        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 2mo ago
        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 https://xcancel.com/riotgames/status/2069829543276216564
        AnthonyMouse 2mo ago
        > 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.
- solenoid0937 2mo ago
  > 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.
  - gspr 2mo ago
    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 2mo ago
      The audience of this article are people working with infrastructure, not people developing user facing products. See quote: "If your infra consistently enforces mTLS ..."
  - toast0 2mo ago
    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 2mo ago
      Thats not true. Almost no consumer systems ship with SGX.
  - mschuster91 2mo ago
    > 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.
  - UltraSane 2mo ago
    Exactly. Remote attestation is nothing more than an elaborate hashing and signing scheme using trusted hardware and is VERY useful.
- jeroenhd 2mo ago
  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.
  - vaylian 2mo ago
    > 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 2mo ago
      > 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-specification/ 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/ 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.
nondescript2887 2mo ago
>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)
imglorp 2mo ago
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.
Uptrenda 2mo ago
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.
- klausa 2mo ago
  By that metric we should just pack it all up and call it a day on computing in general; because even despite literal trillions of dollars being spent on it, we still haven't found a way to make it secure.
  - Uptrenda 2mo ago
    You can make software secure though since it can be patched. How do you patch hardware if it has design flaws? The whole claim behind these hardware cages is they can't be accessed from outside the cage, period. So IMO, seeing multiple failings of this sort kind of makes me not want to trust it.
  - gmueckl 2mo ago
    Not all computing that is useful must also be absolutely secure. Maybe we just have overextended the use of computers into areas where using them generates too much risk? If so, where is the boundary?
- Gigachad 2mo ago
  The iPhone is actually working really well. There has never been a widespread malware attack on the iphone. Only highly targeted attacks on individuals. And Apple even has an answer for this as well with Lockdown mode which renders all of those previous exploits impossible. 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.
michaelmrose 2mo ago
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! Then look at who actually runs our country.
userbinator 2mo ago
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." Remote Attestation: Just Say No.
- stingraycharles 2mo ago
  Could you elaborate on why this is so evil? 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.
  - fooqux 2mo ago
    It's a tool. Remote attestation isn't "evil" in the same way a knife isn't inherently evil. It's how they're used. 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.
  - AnthonyMouse 2mo ago
    When you access a service with your own device, you control what your device does with what they send. You can block ads or malware, inspect code they send you or network traffic you send them to see if it's exfiltrating your private data, extract the data to analyze or keep as evidence when the service is violating a law or contract, write or use third party code to process the data when the service is trying to force a dark pattern interface on you, etc. 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.
davidfiala 2mo ago
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 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...
- solenoid0937 2mo ago
  You don't understand the use case or audience of this article: > If your infra consistently enforces mTLS This is for mutual authentication in corporate infrastructure. Attestation is a critical security property for these environments.
  - sfdlkj3jk342a 2mo ago
    > 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.
    - solenoid0937 2mo ago
      [flagged]
      - sfdlkj3jk342a 2mo ago
        > Do you debate vaccines with your doctors too? If by "debate", you mean I take their advice into consideration and then make my own decision without blindly trusting them, then yes I do.
madduci 2mo ago
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.
- lachiflippi 2mo ago
  > you get most of results in Windows through the CryptoProvider 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.
  - jcgl 2mo ago
    > 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. This is really cool. Did not know about it: https://learn.microsoft.com/en-us/windows-server/identity/ad-ds/manage/component-updates/tpm-key-attestation https://learn.microsoft.com/en-us/windows-server/identity/ad...
  - madduci 2mo ago
    Exactly, how Windows exposes the TPM functionalities is a far better experience than in other platforms
whiatp 2mo ago
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.
- simonjgreen 2mo ago
  I recall an event some years ago around Supermicro that was along these lines. Chips added during manufacturing by nation state that interfered with the operation of the BMC and TPM. Wasn't it the catalyst that pushed hardware supply chain concerns in to mainstream media?
- crote 2mo ago
  Don't most (all?) modern CPUs have an embedded TPM? Plug-in TPMs were indeed a thing early on, but I thought that was a thing of the past by now. You can't exactly get in between the CPU and another part of the same CPU. 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.
  - 2mo ago
Cider9986 2mo ago
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. https://attestation.app/about 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-guide https://grapheneos.org/articles/attestation-compatibility-gu...
- matejdro 2mo ago
  > No freedom lost, just security gained As far as I can tell, it flags unlocked bootloaders? So this is already huge freedom lost.
  - rcxdude 2mo ago
    With grapheneOS you can lock the bootloader with your own keys. Huge difference. (That said, I don't know if the apps which demand the attestation trust anything but the official grapheneOS keys)
  - Cider9986 2mo ago
    Auditor doesn't cause any issues with your system if there's a problem besides letting you know. It's just for informative purposes so you can determine your system is secure.
- Zak 2mo ago
  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.
egorfine 2mo ago
This is an incredibly nice technology that absolutely will be used to prevent you from using your computer as you wish.
- phantomathkg 2mo ago
  This is also the technology that big and small OTT stream provider that they wish they can deploy on us.
- matheusmoreira 2mo ago
  It's all about who owns the keys to the machine. Attestation with our own keys is good for us. It becomes a problem when it's the manufacturer's key, the digital fiefdom owner's key or the government's key. Remote attestation reveals the fact the computer belongs to corporations and governments. The user's attempts to claim ownership are "tampering".
  - spacebanana7 2mo ago
    Not your keys, not your computer
- lurkerforawhile 2mo ago
  this stuff should only be used for military and other high risk environments. it's an anti-consumer, anti-reuse, e-waste generating nightmare.
DonsDiscountGas 2mo ago
> open explainer article > Uses a lot of acronyms without even saying what they stand for let alone an explanation > Article entirely unhelpful Many such cases
- pickleglitch 2mo ago
  I didn't even finish the article because this sort of thing pisses me off too much.
marginalia_nu 2mo ago
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?
- mindslight 2mo ago
  The TPM is tamper proof hardware that includes privileged crypto keys that are installed (generated) by the device manufacturer with their identity retained / cataloged. The asymmetry of these privileged keys are where the private/control concerns end up coming from. If these top-level keys were instead unknown to everybody except the device owner (including an enterprise), then there would be no way for a random third party attacker to know whether it was talking to a hardware RPM or a software emulation of one.
- getcrunk 2mo ago
  Same way drm works, it’s going to be in layer of hw/sw that you don’t have control over. We don’t have commonly have control on the cpu, chipset, uefi. And on the top side things like widevine on the application layer

110 points by lcvw 2mo ago

zb3 2mo ago

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

lcvw 2mo ago
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 2mo ago
  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.
  - lcvw 2mo ago
    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 2mo ago
      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 2mo ago
      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 2mo ago
        When did google prohibit ad blocking in their browser?
        AnthonyMouse 2mo ago
        https://9to5google.com/2026/06/15/google-chromes-next-update-will-mark-the-end-of-popular-ad-blockers/ https://9to5google.com/2026/06/15/google-chromes-next-update...
        zb3 2mo ago
        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.
  - mjg59 2mo ago
    You say that, and also remote attestation is how Signal knows it's talking to a legitimate SGX enclave running the expected payload
    - lcvw 2mo ago
      I definitely want to do a post on confidential computing as well. Super cool stuff.
      - throwaway7679 2mo ago
        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 2mo ago
        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)
    - greyface- 2mo ago
      > 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 2mo ago
        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.)
  - Rohansi 2mo ago
    > 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 2mo ago
      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 2mo ago
        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 https://xcancel.com/riotgames/status/2069829543276216564
        AnthonyMouse 2mo ago
        > 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.
solenoid0937 2mo ago
> 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.
- gspr 2mo ago
  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 2mo ago
    The audience of this article are people working with infrastructure, not people developing user facing products. See quote: "If your infra consistently enforces mTLS ..."
- toast0 2mo ago
  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 2mo ago
    Thats not true. Almost no consumer systems ship with SGX.
- mschuster91 2mo ago
  > 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.
- UltraSane 2mo ago
  Exactly. Remote attestation is nothing more than an elaborate hashing and signing scheme using trusted hardware and is VERY useful.
jeroenhd 2mo ago
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.
- vaylian 2mo ago
  > 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 2mo ago
    > 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-specification/ 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/ 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.

nondescript2887 2mo ago

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

imglorp 2mo ago

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.

Uptrenda 2mo ago

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.

klausa 2mo ago
By that metric we should just pack it all up and call it a day on computing in general; because even despite literal trillions of dollars being spent on it, we still haven't found a way to make it secure.
- Uptrenda 2mo ago
  You can make software secure though since it can be patched. How do you patch hardware if it has design flaws? The whole claim behind these hardware cages is they can't be accessed from outside the cage, period. So IMO, seeing multiple failings of this sort kind of makes me not want to trust it.
- gmueckl 2mo ago
  Not all computing that is useful must also be absolutely secure. Maybe we just have overextended the use of computers into areas where using them generates too much risk? If so, where is the boundary?
Gigachad 2mo ago
The iPhone is actually working really well. There has never been a widespread malware attack on the iphone. Only highly targeted attacks on individuals. And Apple even has an answer for this as well with Lockdown mode which renders all of those previous exploits impossible. 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.

michaelmrose 2mo ago

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! Then look at who actually runs our country.

userbinator 2mo ago

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." Remote Attestation: Just Say No.

stingraycharles 2mo ago
Could you elaborate on why this is so evil? 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.
- fooqux 2mo ago
  It's a tool. Remote attestation isn't "evil" in the same way a knife isn't inherently evil. It's how they're used. 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.
- AnthonyMouse 2mo ago
  When you access a service with your own device, you control what your device does with what they send. You can block ads or malware, inspect code they send you or network traffic you send them to see if it's exfiltrating your private data, extract the data to analyze or keep as evidence when the service is violating a law or contract, write or use third party code to process the data when the service is trying to force a dark pattern interface on you, etc. 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.

davidfiala 2mo ago

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

solenoid0937 2mo ago
You don't understand the use case or audience of this article: > If your infra consistently enforces mTLS This is for mutual authentication in corporate infrastructure. Attestation is a critical security property for these environments.
- sfdlkj3jk342a 2mo ago
  > 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.
  - solenoid0937 2mo ago
    [flagged]
    - sfdlkj3jk342a 2mo ago
      > Do you debate vaccines with your doctors too? If by "debate", you mean I take their advice into consideration and then make my own decision without blindly trusting them, then yes I do.

madduci 2mo ago

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.

lachiflippi 2mo ago
> you get most of results in Windows through the CryptoProvider 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.
- jcgl 2mo ago
  > 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. This is really cool. Did not know about it: https://learn.microsoft.com/en-us/windows-server/identity/ad-ds/manage/component-updates/tpm-key-attestation https://learn.microsoft.com/en-us/windows-server/identity/ad...
- madduci 2mo ago
  Exactly, how Windows exposes the TPM functionalities is a far better experience than in other platforms

whiatp 2mo ago

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.

simonjgreen 2mo ago
I recall an event some years ago around Supermicro that was along these lines. Chips added during manufacturing by nation state that interfered with the operation of the BMC and TPM. Wasn't it the catalyst that pushed hardware supply chain concerns in to mainstream media?
crote 2mo ago
Don't most (all?) modern CPUs have an embedded TPM? Plug-in TPMs were indeed a thing early on, but I thought that was a thing of the past by now. You can't exactly get in between the CPU and another part of the same CPU. 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.
- 2mo ago

Cider9986 2mo ago

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. https://attestation.app/about 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-guide https://grapheneos.org/articles/attestation-compatibility-gu...

matejdro 2mo ago
> No freedom lost, just security gained As far as I can tell, it flags unlocked bootloaders? So this is already huge freedom lost.
- rcxdude 2mo ago
  With grapheneOS you can lock the bootloader with your own keys. Huge difference. (That said, I don't know if the apps which demand the attestation trust anything but the official grapheneOS keys)
- Cider9986 2mo ago
  Auditor doesn't cause any issues with your system if there's a problem besides letting you know. It's just for informative purposes so you can determine your system is secure.
Zak 2mo ago
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.

egorfine 2mo ago

This is an incredibly nice technology that absolutely will be used to prevent you from using your computer as you wish.

phantomathkg 2mo ago
This is also the technology that big and small OTT stream provider that they wish they can deploy on us.
matheusmoreira 2mo ago
It's all about who owns the keys to the machine. Attestation with our own keys is good for us. It becomes a problem when it's the manufacturer's key, the digital fiefdom owner's key or the government's key. Remote attestation reveals the fact the computer belongs to corporations and governments. The user's attempts to claim ownership are "tampering".
- spacebanana7 2mo ago
  Not your keys, not your computer
lurkerforawhile 2mo ago
this stuff should only be used for military and other high risk environments. it's an anti-consumer, anti-reuse, e-waste generating nightmare.

DonsDiscountGas 2mo ago

> open explainer article > Uses a lot of acronyms without even saying what they stand for let alone an explanation > Article entirely unhelpful Many such cases

pickleglitch 2mo ago
I didn't even finish the article because this sort of thing pisses me off too much.

marginalia_nu 2mo ago

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?

mindslight 2mo ago
The TPM is tamper proof hardware that includes privileged crypto keys that are installed (generated) by the device manufacturer with their identity retained / cataloged. The asymmetry of these privileged keys are where the private/control concerns end up coming from. If these top-level keys were instead unknown to everybody except the device owner (including an enterprise), then there would be no way for a random third party attacker to know whether it was talking to a hardware RPM or a software emulation of one.
getcrunk 2mo ago
Same way drm works, it’s going to be in layer of hw/sw that you don’t have control over. We don’t have commonly have control on the cpu, chipset, uefi. And on the top side things like widevine on the application layer