6 ms·

Remote Attestation TLS (RA-TLS)

47 points by c0l0 3y ago

c0l0 3y ago
I wanted to draw attention to this since it has strong "Web Integrity API" vibes, but works at a level that imho might be even more worrisome than what goes on between your browser and a web server - the TLS connection layer. The standard aims to integrate "platform attestion tokens" (like those provided by Arm CPU platforms, for instance: https://www.ietf.org/archive/id/draft-tschofenig-rats-psa-token-08.html https://www.ietf.org/archive/id/draft-tschofenig-rats-psa-to...) into TLS handshake client metadata, which will enable remote services to deny serving clients that do not pass SafetyNet/Play Integrity/Web Integrity-like attestation schemes before any application layer data has been exchanged at all. It is being drafted here: https://datatracker.ietf.org/doc/draft-fossati-tls-attestation/ https://datatracker.ietf.org/doc/draft-fossati-tls-attestati...
- mindslight 3y ago
  This might be less bad - being part of the protocol, browsers might implement this with much more obtuse UIs that hinder adoption, causing it to fail and the ecosystem to move on. Whereas putting the capabilities under flexible software control like Google's treacherous proposal allows for this slowly-boiling-frog dynamic we've already experienced with IP and browser leak based discrimination. (Like these days even Amazon is hitting me with CAPTCHAs to search products. sigh) But every remote attestation scheme is fundamentally an evil attack on personal computing, couched in legitimate sounding language like "security". The actual dynamic is that of a villain in a story arc who starts off with good intentions, but just wants increasingly more power to implement their desires, causing them to actually be evil.
  - zb3 3y ago
    Enclaves and remote attestations aren't bad per-se, it's just those where the user of the device is considered an "untrusted party". It makes more sense to consider your cloud provider an untrusted party, however I'd not rely on these technologies anyway, in practice they might not be as secure as advertised.
    - mindslight 3y ago
      In line with my second point, we can always see "legitimate" uses for more power. But novel centralized power generally accrues to those who already have power - hence your hedging about cloud providers ("however I'd not rely on these technologies anyway"). But yes, I've also put forth the argument that RA could be a neutral feature if it were under the control of the owner of the computer. Either prohibit manufacturers from bundling privileged keys with devices, or require that the chip be able to import and export all attestation keys through an appropriate maintenance mode. Then an end user would always be free to generate new keys or export bundled ones and run the attestation protocols in software, thus preserving their freedom to run whatever software they'd like. But the above dynamic would not result in widely used protocols for doing attestations, rather they would be a bespoke thing for specific use cases - like say an internal corporate website that can only be accessed by corporate laptops. Hence why I think it's correct to judge every attempt at remote attestation for the general web and/or consumer machines as "evil". Furthermore, the funny thing that wasn't part of these debates when both secure attestation and secure boot were only abstract threats - secure boot already covers most of the legitimate desires for secure attestation. For example deploying a server at a datacenter - secure attestation would be nice for knowing it's not been tampered with. But secure boot already provides that assurance. The main difference would seem to be that if a software bug allows arbitrary code execution, secure boot falls down immediately while secure attestation is supposed to catch that (although who knows if implementations would actually live up to that).
josephcsible 3y ago
Does this have a single legitimate use? I can't think of any. It seems like it's only useful for things like DRM.
- zb3 3y ago
  It attests the server, not the client.
  - JohnFen 3y ago
    That's not any better.
  - josephcsible 3y ago
    Why does this matter? Are you saying that does create legitimate uses? If so, what are they?
    - xenocratus 3y ago
      Imagine you're connecting to a VPN server. The service provider says they don't store logs - nowadays you have to trust them, and perhaps any audits they might have done in the past. Remote attestation allows you to get information about the actual VM that's running the service, so the provider can give you the image for the machine (or build steps for it), and what you get via remote attestation is cryptographic proof backed by the hardware that the machine you're talking to is indeed running that software, and not something else that the provider has deployed. And this is just a consumer-centric use, most use cases related to remote attestation have nothing to do with end consumer. The goal is usually to make sure that some workload or device that a company owns (say, a VM in the cloud, or an IoT device running in a field somewhere) are what the company expects them to be.
      - zb3 3y ago
        > cryptographic proof backed by the hardware that the machine you're talking to is indeed running that software Assuming both the software and hardware are secure, where hardware security includes resistance for attacks like fault injection and so on. This is fascinating for me, because it's like you could break the system if you were able to flip one single bit (load?) somewhere inside the SoC. So I guess this topic is about to get more popular.
matheusmoreira 3y ago
Allows them to whitelist clients. Kills off adversarial interoperability. Now you can't make you own compatible technology stack anymore, you have to use their approved ones which only ever do their bidding at your expense.
- jeroenhd 3y ago
  Which is a great feature for a locked down intranet, cloud cluster, or IoT network. Terrible for public facing websites, but with the time to adoption rates of TLS 1.3 (and disabling the outdated TLS 1.1 and 1.2) and the use of http/3, I don't think any important party is even going to try to put this into production for any customer facing system.
zb3 3y ago
Note that in this case, the "untrusted" party is the cloud provider, not the user. It's meant to attest servers. Fortunately newer intel consumer-class processors don't support SGX anymore.
- c0l0 3y ago
  Unfortunately, that is only correct for the example cited in the article I linked to. The RFC being drafted contains attestation possibilities for both clients and servers, as per sections 4.1. (TLS Client as Attester) and 4.2. (TLS Server as Attester). Nothing in this prevents servers from discrimincating against clients that fail to produce TPM-backed attestation that they run exclusively the exact software builds, cryptographically signed by a central arbiter of trust, that the server expects/requires them to.
  - zb3 3y ago
    That's why I mentioned intel deprecating SGX, because newer desktop CPU's don't support that, so it'd be impractical for websites to discriminate based on that. Also note that servers running in the cloud can naturally be clients. It's only bad if this is meant to restrict the power of the consumer over their own (non-rented) devices.
    - c0l0 3y ago
      I'm sorry to say that I am not convinced. In recent years, Microsoft has introduced [Virtualisation-based Security](https://learn.microsoft.com/en-us/windows-hardware/design/device-experiences/oem-vbs https://learn.microsoft.com/en-us/windows-hardware/design/de...) - funnily enough while recycling one of actual security experts' most-loathed acronym, "VBS" - for OS components that are deemed critical, such as Windows Defender Credential Guard. If your OS, that is now also a hypervisor, shards off some "critical" computation, such as computing RA-TLS nonces - into a privileged domain that your regular user domain may not access, and that privileged, TMP-attested domain is protected by all the secure/measured boot shenanigans that are going on with Windows 11 and its mandatory TPM, it's as game over as it was with SGX directly in your CPU (barring some grave implementation bugs that will make everything vulnerable to state-level actors regardless). Also, Arm silicon, for example, has TrustZone, which afaiui serves a similar purpose as SGX did.
nobody9999 3y ago
What's the advantage (I can't see any) of this scheme over using client certificates where appropriate? It seems to me that the "attestation" doesn't add anything (other than the ability to positively identify a device across multiple sites, which is a downside rather than an advantage) to the TLS session set up process. If a site (i.e., a corporate VPN) needs to ensure that a particular client is authorized to access it, client certificates and user authentication already provide such confirmation. I don't see why this is necessary for sites that, while they may wish to encrypt sessions with TLS, don't have any reason to track (and potentially block) devices that don't possess the properties (e.g., no ad blocker) they want to see. ISTM that this is antithetical to the peer-to-peer nature of the Internet and is just another way to restrict access for those who are deemed to be acting against the financial interests of large corporations. I have no interest in donating my CPU cycles and bandwidth to those who want to identify/categorize/advertise/restrict my access to the open internet. This could also kill off tools like curl, yt-dlp and other non-browser tools. Altogether a terrible idea. Or am I missing something important?
- xenocratus 3y ago
  > Or am I missing something important? The fact that the internet != traffic going to your laptop/PC/phone. There are a lot of non-consumer use-cases (think, processing of corporate data in the cloud, or deployment of industrial IoT devices) where you want very strong guarantees about the state of the entity you're talking to, stronger than a static x509 gives you. > over using client certificates The use-cases are also not restricted to client authentication (and "client" doesn't always mean outside of the cloud).
  - nobody9999 3y ago
    >The fact that the internet != traffic going to your laptop/PC/phone. >There are a lot of non-consumer use-cases (think, processing of corporate data in the cloud, or deployment of industrial IoT devices) where you want very strong guarantees about the state of the entity you're talking to, stronger than a static x509 gives you. I am aware that the Internet is not limited to websites and personal devices. In fact, I have implemented/secured/managed corporate networks with multiple secured data channels (both within the organization and its employees and in B2B and B2C contexts) many times. Securing such data (whether within a cloud infrastructure or across the open internet) streams doesn't require such remote "attestation." In fact, it adds an additional layer of complexity that, at least AFAICT, primarily adds the ability to track personal devices and usage across the wider internet. >> over using client certificates >The use-cases are also not restricted to client authentication (and "client" doesn't always mean outside of the cloud). Fair enough. call such certificates whatever you like. However in the corporate context, I'd much prefer to be able to verify authorized connections via a process within my control (e.g., issuing my own certificates to network-based devices, servers/VMs/containers/whatever) rather than relying upon some third-party (whether that's an SGX store or a remote "attestation" authority) for such authentication/authorization processes. I'll add that this (and by me, repeatedly, as well as many thousands of others) has been successfully accomplished without building a mechanism to uniquely identify arbitrary (as opposed to specific devices involved in sharing data streams) devices on the 'net. Which is, AFAICT, what this Internet Draft appears to be advocating.

47 points by c0l0 3y ago

c0l0 3y ago

I wanted to draw attention to this since it has strong "Web Integrity API" vibes, but works at a level that imho might be even more worrisome than what goes on between your browser and a web server - the TLS connection layer. The standard aims to integrate "platform attestion tokens" (like those provided by Arm CPU platforms, for instance: https://www.ietf.org/archive/id/draft-tschofenig-rats-psa-token-08.html https://www.ietf.org/archive/id/draft-tschofenig-rats-psa-to...) into TLS handshake client metadata, which will enable remote services to deny serving clients that do not pass SafetyNet/Play Integrity/Web Integrity-like attestation schemes before any application layer data has been exchanged at all. It is being drafted here: https://datatracker.ietf.org/doc/draft-fossati-tls-attestation/ https://datatracker.ietf.org/doc/draft-fossati-tls-attestati...

mindslight 3y ago
This might be less bad - being part of the protocol, browsers might implement this with much more obtuse UIs that hinder adoption, causing it to fail and the ecosystem to move on. Whereas putting the capabilities under flexible software control like Google's treacherous proposal allows for this slowly-boiling-frog dynamic we've already experienced with IP and browser leak based discrimination. (Like these days even Amazon is hitting me with CAPTCHAs to search products. sigh) But every remote attestation scheme is fundamentally an evil attack on personal computing, couched in legitimate sounding language like "security". The actual dynamic is that of a villain in a story arc who starts off with good intentions, but just wants increasingly more power to implement their desires, causing them to actually be evil.
- zb3 3y ago
  Enclaves and remote attestations aren't bad per-se, it's just those where the user of the device is considered an "untrusted party". It makes more sense to consider your cloud provider an untrusted party, however I'd not rely on these technologies anyway, in practice they might not be as secure as advertised.
  - mindslight 3y ago
    In line with my second point, we can always see "legitimate" uses for more power. But novel centralized power generally accrues to those who already have power - hence your hedging about cloud providers ("however I'd not rely on these technologies anyway"). But yes, I've also put forth the argument that RA could be a neutral feature if it were under the control of the owner of the computer. Either prohibit manufacturers from bundling privileged keys with devices, or require that the chip be able to import and export all attestation keys through an appropriate maintenance mode. Then an end user would always be free to generate new keys or export bundled ones and run the attestation protocols in software, thus preserving their freedom to run whatever software they'd like. But the above dynamic would not result in widely used protocols for doing attestations, rather they would be a bespoke thing for specific use cases - like say an internal corporate website that can only be accessed by corporate laptops. Hence why I think it's correct to judge every attempt at remote attestation for the general web and/or consumer machines as "evil". Furthermore, the funny thing that wasn't part of these debates when both secure attestation and secure boot were only abstract threats - secure boot already covers most of the legitimate desires for secure attestation. For example deploying a server at a datacenter - secure attestation would be nice for knowing it's not been tampered with. But secure boot already provides that assurance. The main difference would seem to be that if a software bug allows arbitrary code execution, secure boot falls down immediately while secure attestation is supposed to catch that (although who knows if implementations would actually live up to that).

josephcsible 3y ago

Does this have a single legitimate use? I can't think of any. It seems like it's only useful for things like DRM.

zb3 3y ago
It attests the server, not the client.
- JohnFen 3y ago
  That's not any better.
- josephcsible 3y ago
  Why does this matter? Are you saying that does create legitimate uses? If so, what are they?
  - xenocratus 3y ago
    Imagine you're connecting to a VPN server. The service provider says they don't store logs - nowadays you have to trust them, and perhaps any audits they might have done in the past. Remote attestation allows you to get information about the actual VM that's running the service, so the provider can give you the image for the machine (or build steps for it), and what you get via remote attestation is cryptographic proof backed by the hardware that the machine you're talking to is indeed running that software, and not something else that the provider has deployed. And this is just a consumer-centric use, most use cases related to remote attestation have nothing to do with end consumer. The goal is usually to make sure that some workload or device that a company owns (say, a VM in the cloud, or an IoT device running in a field somewhere) are what the company expects them to be.
    - zb3 3y ago
      > cryptographic proof backed by the hardware that the machine you're talking to is indeed running that software Assuming both the software and hardware are secure, where hardware security includes resistance for attacks like fault injection and so on. This is fascinating for me, because it's like you could break the system if you were able to flip one single bit (load?) somewhere inside the SoC. So I guess this topic is about to get more popular.

matheusmoreira 3y ago

Allows them to whitelist clients. Kills off adversarial interoperability. Now you can't make you own compatible technology stack anymore, you have to use their approved ones which only ever do their bidding at your expense.

jeroenhd 3y ago
Which is a great feature for a locked down intranet, cloud cluster, or IoT network. Terrible for public facing websites, but with the time to adoption rates of TLS 1.3 (and disabling the outdated TLS 1.1 and 1.2) and the use of http/3, I don't think any important party is even going to try to put this into production for any customer facing system.

zb3 3y ago

Note that in this case, the "untrusted" party is the cloud provider, not the user. It's meant to attest servers. Fortunately newer intel consumer-class processors don't support SGX anymore.

c0l0 3y ago
Unfortunately, that is only correct for the example cited in the article I linked to. The RFC being drafted contains attestation possibilities for both clients and servers, as per sections 4.1. (TLS Client as Attester) and 4.2. (TLS Server as Attester). Nothing in this prevents servers from discrimincating against clients that fail to produce TPM-backed attestation that they run exclusively the exact software builds, cryptographically signed by a central arbiter of trust, that the server expects/requires them to.
- zb3 3y ago
  That's why I mentioned intel deprecating SGX, because newer desktop CPU's don't support that, so it'd be impractical for websites to discriminate based on that. Also note that servers running in the cloud can naturally be clients. It's only bad if this is meant to restrict the power of the consumer over their own (non-rented) devices.
  - c0l0 3y ago
    I'm sorry to say that I am not convinced. In recent years, Microsoft has introduced [Virtualisation-based Security](https://learn.microsoft.com/en-us/windows-hardware/design/device-experiences/oem-vbs https://learn.microsoft.com/en-us/windows-hardware/design/de...) - funnily enough while recycling one of actual security experts' most-loathed acronym, "VBS" - for OS components that are deemed critical, such as Windows Defender Credential Guard. If your OS, that is now also a hypervisor, shards off some "critical" computation, such as computing RA-TLS nonces - into a privileged domain that your regular user domain may not access, and that privileged, TMP-attested domain is protected by all the secure/measured boot shenanigans that are going on with Windows 11 and its mandatory TPM, it's as game over as it was with SGX directly in your CPU (barring some grave implementation bugs that will make everything vulnerable to state-level actors regardless). Also, Arm silicon, for example, has TrustZone, which afaiui serves a similar purpose as SGX did.

nobody9999 3y ago

What's the advantage (I can't see any) of this scheme over using client certificates where appropriate? It seems to me that the "attestation" doesn't add anything (other than the ability to positively identify a device across multiple sites, which is a downside rather than an advantage) to the TLS session set up process. If a site (i.e., a corporate VPN) needs to ensure that a particular client is authorized to access it, client certificates and user authentication already provide such confirmation. I don't see why this is necessary for sites that, while they may wish to encrypt sessions with TLS, don't have any reason to track (and potentially block) devices that don't possess the properties (e.g., no ad blocker) they want to see. ISTM that this is antithetical to the peer-to-peer nature of the Internet and is just another way to restrict access for those who are deemed to be acting against the financial interests of large corporations. I have no interest in donating my CPU cycles and bandwidth to those who want to identify/categorize/advertise/restrict my access to the open internet. This could also kill off tools like curl, yt-dlp and other non-browser tools. Altogether a terrible idea. Or am I missing something important?

xenocratus 3y ago
> Or am I missing something important? The fact that the internet != traffic going to your laptop/PC/phone. There are a lot of non-consumer use-cases (think, processing of corporate data in the cloud, or deployment of industrial IoT devices) where you want very strong guarantees about the state of the entity you're talking to, stronger than a static x509 gives you. > over using client certificates The use-cases are also not restricted to client authentication (and "client" doesn't always mean outside of the cloud).
- nobody9999 3y ago
  >The fact that the internet != traffic going to your laptop/PC/phone. >There are a lot of non-consumer use-cases (think, processing of corporate data in the cloud, or deployment of industrial IoT devices) where you want very strong guarantees about the state of the entity you're talking to, stronger than a static x509 gives you. I am aware that the Internet is not limited to websites and personal devices. In fact, I have implemented/secured/managed corporate networks with multiple secured data channels (both within the organization and its employees and in B2B and B2C contexts) many times. Securing such data (whether within a cloud infrastructure or across the open internet) streams doesn't require such remote "attestation." In fact, it adds an additional layer of complexity that, at least AFAICT, primarily adds the ability to track personal devices and usage across the wider internet. >> over using client certificates >The use-cases are also not restricted to client authentication (and "client" doesn't always mean outside of the cloud). Fair enough. call such certificates whatever you like. However in the corporate context, I'd much prefer to be able to verify authorized connections via a process within my control (e.g., issuing my own certificates to network-based devices, servers/VMs/containers/whatever) rather than relying upon some third-party (whether that's an SGX store or a remote "attestation" authority) for such authentication/authorization processes. I'll add that this (and by me, repeatedly, as well as many thousands of others) has been successfully accomplished without building a mechanism to uniquely identify arbitrary (as opposed to specific devices involved in sharing data streams) devices on the 'net. Which is, AFAICT, what this Internet Draft appears to be advocating.