> Now, TPMs are sometimes referred to as a TEE, and in a way they are. However, they're fixed function - you can't run arbitrary code on the TPM, you only have whatever functionality it provides. But TPMs do have the ability to decrypt data using keys that are tied to the TPM, so isn't this sufficient? Well, no. First, the TPM can't communicate with the GPU. The OS could push encrypted material to it, and it would get plaintext material back. But the entire point of this exercise was to avoid the decrypted version of the stream from ever being visible to the OS, so this would be pointless. And rather more fundamentally, TPMs are slow. I don't think there's a TPM on the market that could decrypt a 1080p stream in realtime, let alone a 4K one.
As to the first point... the TPM can't communicate with the GPU, but maybe the GPU could communicate with the TPM. The way that would happen is that the GPU would talk to the TPM directly, using `TPM2_StartAuthSession()` to start an encrypted session with the TPM then it would use `TPM2_ActivateCredential()` or `TPM2_Import()`/`TPM2_Load()`/`TPM2_RSA_Decrypt()` to decrypt a symmetric session key that the GPU would then use to decrypt the stream. I.e., the GPU would do the bulk crypto, but the TPM would do the key transport / key exchange.
That also addresses the second point: the TPM being slow is not a big deal because you'd only need it to do something slow once when starting the video playback.
Of course, the GPU could just include TPM-like features to get the same effect, which really proves the point which is that:
> The FSF's focus on TPMs here is not only technically wrong, it's indicative of a failure to understand what's actually happening in the industry. While the FSF has been focusing on TPMs, GPU vendors have quietly deployed all of this technology without the FSF complaining at all. Microsoft has enthusiastically participated in making hardware DRM on Windows possible, and user freedoms have suffered as a result, but Playready hardware-based DRM works just fine on hardware that doesn't have a TPM and will continue to do so.
Pretty much. All the DRM functionality can be in the GPU, and there might not even be a standard API like TPM 2.0 that anyone could use, so the result is even worse than if the GPUs used TPMs to implement DRM.
Though, if one were implementing DRM in the GPU or in the display monitor (why not) then the TPM 2.0 MakeCredential/ActivateCredential protocol is a very good fit, so one might as well use that, and even embed a TPM in the GPU and/or the monitor. If you do the bulk decryption in the monitor then the user doesn't even get to screenscrape (eavesdrop on) the connection between the GPU and the monitor. One could even implement just a small portion of TPM 2.0 -- everything needed to establish an encrypted session (`TPM2_CreatePrimary()` and `TPM2_StartAuthSession()`, but also `TPM2_FlushContext()`) and `TPM2_ActivateCredential()`, and maybe a bit more if attestation is required (`TPM2_Quote()` and `TPM2_CreateLoaded()`). What would one attest? I think one would use a platform certificate and its key as the signing key for a TPM2_Quote()-based attestation. The point would be to prove that the device is a legitimate GPU or monitor made by an approved vendor.
If you dislike DRM then TPMs are not the enemy. Particularly the TPM on any server or laptop is not the enemy. TPMs in GPUs or monitors might be, but Windows 11 requiring a TPM on the box has nothing to do with that, and again, the GPU/monitor could implement the ActivateCredential protocol internally w/o a TPM anyways.
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.
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.
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.
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.
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).
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
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.
> 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.
> 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.
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.
Well of course. My comment was about how TPMs could be used but how still you were correct that TPMs aren't the FSF's enemy. I was exploring that space to further show that.
As to the first point... the TPM can't communicate with the GPU, but maybe the GPU could communicate with the TPM. The way that would happen is that the GPU would talk to the TPM directly, using `TPM2_StartAuthSession()` to start an encrypted session with the TPM then it would use `TPM2_ActivateCredential()` or `TPM2_Import()`/`TPM2_Load()`/`TPM2_RSA_Decrypt()` to decrypt a symmetric session key that the GPU would then use to decrypt the stream. I.e., the GPU would do the bulk crypto, but the TPM would do the key transport / key exchange.
That also addresses the second point: the TPM being slow is not a big deal because you'd only need it to do something slow once when starting the video playback.
Of course, the GPU could just include TPM-like features to get the same effect, which really proves the point which is that:
> The FSF's focus on TPMs here is not only technically wrong, it's indicative of a failure to understand what's actually happening in the industry. While the FSF has been focusing on TPMs, GPU vendors have quietly deployed all of this technology without the FSF complaining at all. Microsoft has enthusiastically participated in making hardware DRM on Windows possible, and user freedoms have suffered as a result, but Playready hardware-based DRM works just fine on hardware that doesn't have a TPM and will continue to do so.
Pretty much. All the DRM functionality can be in the GPU, and there might not even be a standard API like TPM 2.0 that anyone could use, so the result is even worse than if the GPUs used TPMs to implement DRM.
Though, if one were implementing DRM in the GPU or in the display monitor (why not) then the TPM 2.0 MakeCredential/ActivateCredential protocol is a very good fit, so one might as well use that, and even embed a TPM in the GPU and/or the monitor. If you do the bulk decryption in the monitor then the user doesn't even get to screenscrape (eavesdrop on) the connection between the GPU and the monitor. One could even implement just a small portion of TPM 2.0 -- everything needed to establish an encrypted session (`TPM2_CreatePrimary()` and `TPM2_StartAuthSession()`, but also `TPM2_FlushContext()`) and `TPM2_ActivateCredential()`, and maybe a bit more if attestation is required (`TPM2_Quote()` and `TPM2_CreateLoaded()`). What would one attest? I think one would use a platform certificate and its key as the signing key for a TPM2_Quote()-based attestation. The point would be to prove that the device is a legitimate GPU or monitor made by an approved vendor.
If you dislike DRM then TPMs are not the enemy. Particularly the TPM on any server or laptop is not the enemy. TPMs in GPUs or monitors might be, but Windows 11 requiring a TPM on the box has nothing to do with that, and again, the GPU/monitor could implement the ActivateCredential protocol internally w/o a TPM anyways.