3 ms·

(Disclosure: I work at Anjuna, a member of the Confidential Computing Consortium. Opinions my own.) The value of remote attestation in general (setting aside t

(Disclosure: I work at Anjuna, a member of the Confidential Computing Consortium. Opinions my own.) The value of remote attestation in general (setting aside the implementation detail of RA-TLS) is that you have a form of software identity which is tied directly to the exact code that you're running. For example, if someone steals your service's API key, token, or cert, then they can impersonate your service. But if you are using remote attestation, they will not be able to generate the proper "credential" (a hardware-backed attestation document) to do it. Here on HN lately, I've seen a lot of focus on end user devices for things like Web Integrity. But at work I'm seeing mainly customer use cases which are purely internal and server-side - think reducing risk of insider threats, or simplifying cert management with SPIFFE/SPIRE. For some more publicly-visible use cases, MobileCoin's Fog system https://mobilecoin.com/learn/fog https://mobilecoin.com/learn/fog use remote attestation to ensure validator nodes are coordinating using the same code (rather than some malicious version). Or for a non-blockchain use case, Dashlane's Confidential SSO https://www.dashlane.com/blog/streamline-logins-dashlane-confidential-sso https://www.dashlane.com/blog/streamline-logins-dashlane-con... uses remote attestation so that encryption keys can only be accessed by approved code - reducing risk from insider threats. I just wrote a blog post on another use case we are beginning to see: truly verifiable services. Say you want to operate a managed instance of an open-source project, to save users the operational hassle. How would a user know you're really running that OSS project, rather than a malicious version that steals their data? Using remote attestation, you can actually prove that: https://www.anjuna.io/blog/remote-attestation-enhancing-identity-with-confidential-computing https://www.anjuna.io/blog/remote-attestation-enhancing-iden...

nobody9999 3y ago
>The value of remote attestation in general (setting aside the implementation detail of RA-TLS) is that you have a form of software identity which is tied directly to the exact code that you're running. For example, if someone steals your service's API key, token, or cert, then they can impersonate your service. But if you are using remote attestation, they will not be able to generate the proper "credential" (a hardware-backed attestation document) to do it. That's an excellent point and I agree it's important to ensure strong authentication/authorization for such applications. However, as suggested in the Internet Draft, this would go far beyond simply ensuring that a specific peer is authorized to access another specific peer. Rather, it would essentially assign (based on keys, presumably in a secure enclave) a globally unique identifier that can then be tracked across the entire internet, rather than just ensuring that a particular set of peers are authorized to securely communicate. This is not a new issue and, for the most part, is a solved problem that absolutely does not require that arbitrary devices be permanently fingerprinted/identified. I'm sure that many folks may disagree, especially since "remote attestation" is the new shiny, but that doesn't mean there aren't perfectly functional methods already in use that provide similar functionality -- without the potential for spying/tracking.
- bobbiechen 3y ago
  I see, it seems your objection is to the ARM PSA document - I'm not familiar with it but it seems that it is targeted towards IoT devices. I also don't want permanent fingerprinting, but I think it is a question orthogonal to remote attestation in general. All the tech is already out there and we can push back on specific uses; for example, the Estonian e-ID provides similar permanent fingerprinting _and association with a human_, but seems to be pretty popular among their citizens. On the other hand, the RATS architecture doc has several reference use cases which are useful and limited: https://www.rfc-editor.org/rfc/rfc9334.html#name-reference-use-cases https://www.rfc-editor.org/rfc/rfc9334.html#name-reference-u... . I think these are worth pursuing.
  - nobody9999 3y ago
    >All the tech is already out there and we can push back on specific uses; Yes, we can. And this proposal has privacy implications big enough to drive a column of tanks through. I have no issue with folks confirming the validity of software installed on devices they own, or of businesses vetting specific configurations for their employees/contractors/partners/cloud instances/device and even customers to access their networked environments, where's that's appropriate. In fact, that's been pretty much de rigeuer in corporate environments for decades, and I've helped implement such systems more than once. The issue I have with this proposal is that given the current surveillance capitalism[0] environment, it's likely that a variety of greedy scum will use the tools provided to deprecate privacy on a broad scale. As I said, securing networked environments is critical in many contexts, and we've been doing so for a long time. But building remote attestation (especially when it's not clear who, exactly, might do such attestation and what properties would make a device "untrustworthy") without clear boundaries in the current environment is a privacy disaster waiting to happen, IMHO. >On the other hand, the RATS architecture doc has several reference use cases which are useful and limited: https://www.rfc-editor.org/rfc/rfc9334.html#name-reference-use-cases https://www.rfc-editor.org/rfc/rfc9334.html#name-reference-u.... I think these are worth pursuing. It's not the architecture per se I object to, rather it's the almost certain abuse (in the absence of any regulation or limitations) of such an architecture that's the problem as I see it. [0] https://en.wikipedia.org/wiki/Surveillance_capitalism https://en.wikipedia.org/wiki/Surveillance_capitalism Edit: Added the missing link.

nobody9999 3y ago

>The value of remote attestation in general (setting aside the implementation detail of RA-TLS) is that you have a form of software identity which is tied directly to the exact code that you're running. For example, if someone steals your service's API key, token, or cert, then they can impersonate your service. But if you are using remote attestation, they will not be able to generate the proper "credential" (a hardware-backed attestation document) to do it. That's an excellent point and I agree it's important to ensure strong authentication/authorization for such applications. However, as suggested in the Internet Draft, this would go far beyond simply ensuring that a specific peer is authorized to access another specific peer. Rather, it would essentially assign (based on keys, presumably in a secure enclave) a globally unique identifier that can then be tracked across the entire internet, rather than just ensuring that a particular set of peers are authorized to securely communicate. This is not a new issue and, for the most part, is a solved problem that absolutely does not require that arbitrary devices be permanently fingerprinted/identified. I'm sure that many folks may disagree, especially since "remote attestation" is the new shiny, but that doesn't mean there aren't perfectly functional methods already in use that provide similar functionality -- without the potential for spying/tracking.

bobbiechen 3y ago
I see, it seems your objection is to the ARM PSA document - I'm not familiar with it but it seems that it is targeted towards IoT devices. I also don't want permanent fingerprinting, but I think it is a question orthogonal to remote attestation in general. All the tech is already out there and we can push back on specific uses; for example, the Estonian e-ID provides similar permanent fingerprinting _and association with a human_, but seems to be pretty popular among their citizens. On the other hand, the RATS architecture doc has several reference use cases which are useful and limited: https://www.rfc-editor.org/rfc/rfc9334.html#name-reference-use-cases https://www.rfc-editor.org/rfc/rfc9334.html#name-reference-u... . I think these are worth pursuing.
- nobody9999 3y ago
  >All the tech is already out there and we can push back on specific uses; Yes, we can. And this proposal has privacy implications big enough to drive a column of tanks through. I have no issue with folks confirming the validity of software installed on devices they own, or of businesses vetting specific configurations for their employees/contractors/partners/cloud instances/device and even customers to access their networked environments, where's that's appropriate. In fact, that's been pretty much de rigeuer in corporate environments for decades, and I've helped implement such systems more than once. The issue I have with this proposal is that given the current surveillance capitalism[0] environment, it's likely that a variety of greedy scum will use the tools provided to deprecate privacy on a broad scale. As I said, securing networked environments is critical in many contexts, and we've been doing so for a long time. But building remote attestation (especially when it's not clear who, exactly, might do such attestation and what properties would make a device "untrustworthy") without clear boundaries in the current environment is a privacy disaster waiting to happen, IMHO. >On the other hand, the RATS architecture doc has several reference use cases which are useful and limited: https://www.rfc-editor.org/rfc/rfc9334.html#name-reference-use-cases https://www.rfc-editor.org/rfc/rfc9334.html#name-reference-u.... I think these are worth pursuing. It's not the architecture per se I object to, rather it's the almost certain abuse (in the absence of any regulation or limitations) of such an architecture that's the problem as I see it. [0] https://en.wikipedia.org/wiki/Surveillance_capitalism https://en.wikipedia.org/wiki/Surveillance_capitalism Edit: Added the missing link.