4 ms·

How would the GPU verify it's speaking to a real TPM? You'd need to bake the full set of legitimate EK cert CAs into it somehow (charitably let's say that's a s

by mjg59 2y ago

How would the GPU verify it's speaking to a real TPM? You'd need to bake the full set of legitimate EK cert CAs into it somehow (charitably let's say that's a signed blob that the driver pushes in at startup), but that's still going to be a terrible user experience because you won't get media playback if your machine has a TPM that's too new or from too niche a vendor.

mike_hearn 2y ago
Right, and more to the point there's nothing special about a TPM design-wise. It's actually a very odd kind of chip that only really exists due to the unique political and market requirements of the PC industry. If you look at vertically integrated platforms like Apple's, or the games consoles, or smartphones, there's no TPM. There are subsystems that do similar things, but none of them follow the TPM design specs. Even Intel abandoned it when designing SGX. SGX doesn't involve a TPM at any point. So for a GPU vendor there's no reason to introduce the additional complexity of handshaking with a TPM. Blowing a private key into some eFuses at the factory is relatively easy, add a RAM encryption engine on top and you're already providing better security than what a TPM provides.
- cryptonector 2y ago
  TPM is a missed opportunity. What I really want for security is a solid secure enclave scheme on the CPU itself so my SE code can blaze. The TPM is not programmable and is very limited, both in terms of its API and in terms of its capabilities (e.g., number of keys loaded, number of algorithms supported, ...) and in terms of its performance. My point in my above reply was to say that even if TPMs were used by GPUs then TFA's point would still stand.
  - mike_hearn 2y ago
    Despite the bad press it's received over the years, SGX is a very solid design and works pretty well. Some of the papers presenting breaks turned out to be quite misleading when I looked closely at them some years ago. If you want a general purpose TEE then you could do worse than play with it. Unfortunately it's not available on consumer hardware anymore, and in the cloud only Azure really supports it AFAIK. And you have to write apps for it specifically, and then you have to have clients that know how to do remote attestation and bind it to secure channels, and you have to program in a threat model in which rewinds are possible at any moment. This is very hard, and it turns out most people in the market don't really care about their data that much (are happy to share it with trustworthy institutions). So it never really took off. But the tech is decent.
    - cryptonector 2y ago
      Amazon has their Nitro secure enclave system that's pretty easy to use. IIUC its based on isolating the code that runs it and in it onto one core set aside for just that, possibly just when it's needed. Having the SE be easy to use is a key thing. Not that the Nitro approach extends well to consumer hardware (it doesn't).
      - mike_hearn 2y ago
        The problem with Nitro is that a TEE doesn't really work if the adversary makes your CPUs. SGX works, conceptually, because of the division of labor between Intel and the people running the machines: 1. Intel can't break into your enclave even by subverting SGX, because it doesn't have access to the computers (isn't your cloud operator or network admin). 2. The people with access to the computer can't break into your enclave, because SGX blocks everyone except the enclave owner and Intel. With Nitro, Apple's approach and a few others the logic becomes: 1. Amazon can't break into your enclave even if Nitro has a back door because Amazon don't have acces.... oh, wait. SGX is conceptually sound because subverting it at the design level requires the CPU maker and the cloud operator to team up against you. This could happen, especially if you use a US cloud and the US government gets involved, but the bar is much higher. And of course you can always choose to run the hardware somewhere the USG can't get at it, requiring a coalition of those two governments or providers
        cryptonector 2y ago
        Governments as threats... that's way beyond what people who want DRM consider within their threat models. TFA was about TPM not being relevant to DRM. For most public cloud users having to trust the cloud operator is just a fact of life. Even if the SE were strong up to but excluding collaboration of the CPU vendor and the cloud operator, the user would have to run most if not all of their code in the SE, which is one thing the SEs invariably can't do.
cryptonector 2y ago
> How would the GPU verify it's speaking to a real TPM? Option 1: as I said, the GPU could have its own, and yes in that case the EK cert would be known to the GPU (or it could have a platform-like cert issued by the GPU OEM). Option 2: the platform vendor can teach the GPU the EK cert (or the public key for some primary key anyways). Option 3: the GPU could learn it on first use. > charitably let's say that's a signed blob that the driver pushes in at startup That's what TPM vendors do as to the EK cert. Surely if they can do that then so can GPU and platform vendors. Indeed, some platform vendors ship with platform certs. > but that's still going to be a terrible user experience because you won't get media playback if your machine has a TPM that's too new or . What do you mean "too new"? Like, you replaced your TPM? That's a thing on servers, but not laptops. As to "from too niche a vendor", as long as the platform vendor teaches the GPU what the EK cert is, or makes a platform-like cert that the GPU can use to authenticate the TPM, then it's good enough. Anyways I suspect that MSFT and others don't mind an incrementalist approach. You have a system that can do it their way? Great, it will. You have a system that cannot do it their way? Fine, they'll do weak software DRM for now. There's probably no other way to to get to their dream DRM everywhere state.
- mjg59 2y ago
  > What do you mean "too new"? Like, you replaced your TPM? That's a thing on servers, but not laptops. I buy a GPU in 2025. I buy a new motherboard in 2026 and plug the GPU into it. How does the GPU learn about the new EK CA? These are devices that can be moved between systems, you can't delegate this to the platform vendor or TOFU, the GPU would need to generate independent trust in the TPM.
  - cryptonector 2y ago
    One way I might handle this would be to have a TPM on the GPU itself. Then you can move the GPU about all you like, and it will work. The GPU would have to implement an API and protocol that allows the DRM site to do attestation via software running on the CPU, but that seems doable. The other way would be accept that the GPU that the content is to be played on might not be the same as the device on which the TPM exists. You could have the GPU on a computer halfway around the world and use a TPM from another system to which the user account is registered on the DRM site. Not great, but as a form of account sharing and subject to account sharing detection, it's not bad.

by mjg59 2y ago

mike_hearn 2y ago

Right, and more to the point there's nothing special about a TPM design-wise. It's actually a very odd kind of chip that only really exists due to the unique political and market requirements of the PC industry. If you look at vertically integrated platforms like Apple's, or the games consoles, or smartphones, there's no TPM. There are subsystems that do similar things, but none of them follow the TPM design specs. Even Intel abandoned it when designing SGX. SGX doesn't involve a TPM at any point. So for a GPU vendor there's no reason to introduce the additional complexity of handshaking with a TPM. Blowing a private key into some eFuses at the factory is relatively easy, add a RAM encryption engine on top and you're already providing better security than what a TPM provides.

cryptonector 2y ago
TPM is a missed opportunity. What I really want for security is a solid secure enclave scheme on the CPU itself so my SE code can blaze. The TPM is not programmable and is very limited, both in terms of its API and in terms of its capabilities (e.g., number of keys loaded, number of algorithms supported, ...) and in terms of its performance. My point in my above reply was to say that even if TPMs were used by GPUs then TFA's point would still stand.
- mike_hearn 2y ago
  Despite the bad press it's received over the years, SGX is a very solid design and works pretty well. Some of the papers presenting breaks turned out to be quite misleading when I looked closely at them some years ago. If you want a general purpose TEE then you could do worse than play with it. Unfortunately it's not available on consumer hardware anymore, and in the cloud only Azure really supports it AFAIK. And you have to write apps for it specifically, and then you have to have clients that know how to do remote attestation and bind it to secure channels, and you have to program in a threat model in which rewinds are possible at any moment. This is very hard, and it turns out most people in the market don't really care about their data that much (are happy to share it with trustworthy institutions). So it never really took off. But the tech is decent.
  - cryptonector 2y ago
    Amazon has their Nitro secure enclave system that's pretty easy to use. IIUC its based on isolating the code that runs it and in it onto one core set aside for just that, possibly just when it's needed. Having the SE be easy to use is a key thing. Not that the Nitro approach extends well to consumer hardware (it doesn't).
    - mike_hearn 2y ago
      The problem with Nitro is that a TEE doesn't really work if the adversary makes your CPUs. SGX works, conceptually, because of the division of labor between Intel and the people running the machines: 1. Intel can't break into your enclave even by subverting SGX, because it doesn't have access to the computers (isn't your cloud operator or network admin). 2. The people with access to the computer can't break into your enclave, because SGX blocks everyone except the enclave owner and Intel. With Nitro, Apple's approach and a few others the logic becomes: 1. Amazon can't break into your enclave even if Nitro has a back door because Amazon don't have acces.... oh, wait. SGX is conceptually sound because subverting it at the design level requires the CPU maker and the cloud operator to team up against you. This could happen, especially if you use a US cloud and the US government gets involved, but the bar is much higher. And of course you can always choose to run the hardware somewhere the USG can't get at it, requiring a coalition of those two governments or providers
      - cryptonector 2y ago
        Governments as threats... that's way beyond what people who want DRM consider within their threat models. TFA was about TPM not being relevant to DRM. For most public cloud users having to trust the cloud operator is just a fact of life. Even if the SE were strong up to but excluding collaboration of the CPU vendor and the cloud operator, the user would have to run most if not all of their code in the SE, which is one thing the SEs invariably can't do.

cryptonector 2y ago

> How would the GPU verify it's speaking to a real TPM? Option 1: as I said, the GPU could have its own, and yes in that case the EK cert would be known to the GPU (or it could have a platform-like cert issued by the GPU OEM). Option 2: the platform vendor can teach the GPU the EK cert (or the public key for some primary key anyways). Option 3: the GPU could learn it on first use. > charitably let's say that's a signed blob that the driver pushes in at startup That's what TPM vendors do as to the EK cert. Surely if they can do that then so can GPU and platform vendors. Indeed, some platform vendors ship with platform certs. > but that's still going to be a terrible user experience because you won't get media playback if your machine has a TPM that's too new or . What do you mean "too new"? Like, you replaced your TPM? That's a thing on servers, but not laptops. As to "from too niche a vendor", as long as the platform vendor teaches the GPU what the EK cert is, or makes a platform-like cert that the GPU can use to authenticate the TPM, then it's good enough. Anyways I suspect that MSFT and others don't mind an incrementalist approach. You have a system that can do it their way? Great, it will. You have a system that cannot do it their way? Fine, they'll do weak software DRM for now. There's probably no other way to to get to their dream DRM everywhere state.

mjg59 2y ago
> What do you mean "too new"? Like, you replaced your TPM? That's a thing on servers, but not laptops. I buy a GPU in 2025. I buy a new motherboard in 2026 and plug the GPU into it. How does the GPU learn about the new EK CA? These are devices that can be moved between systems, you can't delegate this to the platform vendor or TOFU, the GPU would need to generate independent trust in the TPM.
- cryptonector 2y ago
  One way I might handle this would be to have a TPM on the GPU itself. Then you can move the GPU about all you like, and it will work. The GPU would have to implement an API and protocol that allows the DRM site to do attestation via software running on the CPU, but that seems doable. The other way would be accept that the GPU that the content is to be played on might not be the same as the device on which the TPM exists. You could have the GPU on a computer halfway around the world and use a TPM from another system to which the user account is registered on the DRM site. Not great, but as a form of account sharing and subject to account sharing detection, it's not bad.