The GPU, not the TPM, is the root of hardware DRM

So is an authenticator app.

Also, SMS isn't, because attackers often get access to the SMS network itself (see e.g. Salt Typhoon) in which case they can do automatic mass account stealing because they can see all the totally unencrypted SMS codes.

The security of SMS really is that bad.

> Sure, let's say that's true. The obvious implication is that these users actually don't care about whether they're running Windows 11 or not, and thus the Windows 11 TPM requirement is utterly irrelevant in their decision to buy a new computer. > I don't see how this supports the theory that this is all about revenue from Windows OEM licenses from forced hardware upgrades.

what on earth makes you think that "what the users actually don't [or do care about]" has any affect on what corporate IT does with their users' devices?

do you think corporate IT is going to say "oh ok" when a user says "i don't want to upgrade to Windows 11 or a laptop that has TPM"

c'mon. lol.

It doesn't need to be a lot - just replaced in the same cadence as the latency from initial broadcast to key revocation. Even if it's all in-house in Netflix and the watermark sufficient to identify the specific device key not all releases are made instantly after being made available on the platform, it still has to be downloaded, verified, watermark extracted before the key can be revoked.

If that's just a total of a single day, 365 cheap netflix devices per year certainly isn't out of the question, especially with the number of people involved in the many ripping groups.

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