> 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

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