Today, most of the major streaming media platforms use TPM to decrypt media streams, strongly placing the decryption out of the user’s control.(from HERE).
It’s part of a general argument that Microsoft’s insistence that only hardware with a TPM can run Windows 11 is intended to help streaming companies in their attempt to ensure that media can only be played on tightly controlled environments.
I’ll be honest here and say that I don’t know what Microsoft’s actual motivation is for requiring TPM in Windows 11. I’ve been talking about TPM stuff for a long time. My job involves writing a lot of TPM code. I think having a TPM enables many useful security features. Given the choice, I would definitely choose a computer with TPM. But in terms of whether it’s worth enough to lock Windows 11 to hardware that doesn’t have a TPM that can run it? I’m not sure that’s a worthwhile tradeoff.
what am i CAN said FSF’s claim is 100% false, and since it’s the only basis for their overall claim about Microsoft’s strategy here, the argument is somewhat damaged. I am not aware of any streaming media platforms that use TPMs in any way whatsoever. THERE is the hardware DRM used by media companies to restrict users, but it’s not in the TPM – it’s in the GPU.
Let’s go back for a moment. There are many different DRM implementations, but the big three are Widevine (owned by Google, used on Android, Chromebooks, and other embedded devices), Fairplay (Apple’s implementation, used for Mac and iOS), and Playready (Microsoft’s implementation, used by Windows and other hardware streaming devices and TVs). These generally implement several levels of functionality, depending on the capabilities of the device they run on – this ranges from all DRM functionality implemented in software to the hardware path that will be discussed shortly. Streaming providers can choose what level of functionality and quality to provide based on the level implemented by the client’s device, and often for 4K and HDR content will be tied to hardware DRM. In either scenario, they stream encrypted content to the client and the DRM stack decrypts it before decoding and playing the compressed data.
The “problem” with DRM software implementations is that the decrypted material will exist somewhere that the OS can get to it at some point, making it possible for users to get only the decrypted stream, which somewhat defeats the whole point. Vendors try to make it difficult by obfuscating their code as much as possible (and in some cases putting some of it in-kernel), but almost all software DRM is at least somewhat broken and the copy of any new streaming media will be available. via Bittorrent soon after release. This is why higher quality media tends to be limited to clients that implement hardware-based DRM.
Hardware-based DRM implementations vary. In the ARM world devices this is usually handled by implementing cryptography in a Trusted Execution Environment, or TEE. A TEE is an area where code can be executed without the OS having any insight into it, with ARM’s TrustZone being an example of this. By placing the DRM code in TrustZone, cryptography can be performed on RAM that the OS does not have access to, making the scraping described earlier impossible. x86 doesn’t have a well-specified TEE (Intel’s SGX is an example, but is no longer implemented in consumer parts), so it tends to be left to the GPU. The exact details of this implementation are somewhat opaque – of the previously mentioned DRM implementations, only Playready does hardware DRM on x86, and I haven’t found any public documentation on what needs to be disclosed. of drivers to make it work.
In any case, as part of the DRM handshake between the client and the streaming platform, the encryption keys are negotiated with the key material stored in the GPU or the TEE, inaccessible from the OS. Once decrypted, the material is decoded (again on the GPU or on the TEE – even in implementations that use TEE for cryptography, the actual media decoding can happen on the GPU) and displayed. An important point is that the decoded video material is still stored in RAM that the OS does not have access to, and the GPU composites it into the outbound video stream (so if you take a screenshot in a browser playing a stream using hardware- based DRM you just see a black window – as far as the OS can see, there is the just a black window there).
Today, TPMs are sometimes called a TEE, and in a way they are. However, this is a fixed function – you can’t run arbitrary code in the TPM, you just have whatever functionality it provides. But TPMs ACT has the ability to decrypt data using keys tied to the TPM, so isn’t that enough? Well, no. First, the TPM cannot communicate with the GPU. The OS can push its encrypted material, and it gets back the plaintext material. But the whole point of this exercise is to avoid the decrypted version of the stream that the OS does not see, so it is useless. And more fundamentally, TPMs slow. I don’t think there is a TPM on the market that can decrypt a 1080p stream in realtime, let alone a 4K one.
The FSF’s focus on TPMs here is not just technically wrong, it indicates a failure to understand what is actually happening in the industry. While the FSF is focusing on TPMs, GPU vendors are quietly deploying all of this technology without the FSF complaining. Microsoft actively participated in making hardware DRM in Windows possible, and user freedoms suffered as a result, but Playready hardware-based DRM works fine on hardware without TPM and will continue to do so.
2025-01-02 02:09:00
