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

Entry tags:

advogato,
fedora

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

As part of their "Defective by Design" anti-DRM campaign, the FSF recently made the following claim:
Today, most of the major streaming media platforms utilize the TPM to decrypt media streams, forcefully placing the decryption out of the user's control (from here).
This is part of an overall argument that Microsoft's insistence that only hardware with a TPM can run Windows 11 is with the goal of aiding streaming companies in their attempt to ensure media can only be played in tightly constrained environments.

I'm going to be honest here and say that I don't know what Microsoft's actual motivation for requiring a TPM in Windows 11 is. 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 a number of worthwhile security features. Given the choice, I'd certainly pick a computer with a TPM. But in terms of whether it's of sufficient value to lock out Windows 11 on hardware with no TPM that would otherwise be able to run it? I'm not sure that's a worthwhile tradeoff.

What I can say is that the FSF's claim is just 100% wrong, and since this seems to be the sole basis of their overall claim about Microsoft's strategy here, the argument is pretty significantly undermined. I'm not aware of any streaming media platforms making use of TPMs in any way whatsoever. There is hardware DRM that the media companies use to restrict users, but it's not in the TPM - it's in the GPU.

Let's back up for a moment. There's multiple different DRM implementations, but the big three are Widevine (owned by Google, used on Android, Chromebooks, and some other embedded devices), Fairplay (Apple implementation, used for Mac and iOS), and Playready (Microsoft's implementation, used in Windows and some other hardware streaming devices and TVs). These generally implement several levels of functionality, depending on the capabilities of the device they're running on - this will range from all the DRM functionality being implemented in software up 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 on the client device, and it's common for 4K and HDR content to be tied to hardware DRM. In any scenario, they stream encrypted content to the client and the DRM stack decrypts it before the compressed data can be decoded and played.

The "problem" with software DRM implementations is that the decrypted material is going to exist somewhere the OS can get at it at some point, making it possible for users to simply grab the decrypted stream, somewhat defeating the entire point. Vendors try to make this difficult by obfuscating their code as much as possible (and in some cases putting some of it in-kernel), but pretty much all software DRM is at least somewhat broken and copies of any new streaming media end up being available via Bittorrent pretty quickly after release. This is why higher quality media tends to be restricted to clients that implement hardware-based DRM.

The implementation of hardware-based DRM varies. On devices in the ARM world this is usually handled by performing the 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 at all, with ARM's TrustZone being an example of this. By putting the DRM code in TrustZone, the cryptography can be performed in RAM that the OS has no access to, making the scraping described earlier impossible. x86 has no well-specified TEE (Intel's SGX is an example, but is no longer implemented in consumer parts), so instead this tends to be handed off 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 of what drivers need to expose for this to work.

In any case, as part of the DRM handshake between the client and the streaming platform, encryption keys are negotiated with the key material being stored in the GPU or the TEE, inaccessible from the OS. Once decrypted, the material is decoded (again either on the GPU or in the TEE - even in implementations that use the TEE for the cryptography, the actual media decoding may happen on the GPU) and displayed. One key point is that the decoded video material is still stored in RAM that the OS has no access to, and the GPU composites it onto the outbound video stream (which is why if you take a screenshot of a browser playing a stream using hardware-based DRM you'll just see a black window - as far as the OS can see, there is only a black window there).

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.

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.

Flat | Top-Level Comments Only

Lest one get the impression that hardware DRM fairs any better than software: Even 4K/HDR versions of streaming media start making the rounds on pirate sites within a day or two of release.

As usual DRM fails to prevent piracy while hurting the experience of paying customers.

there's significant cost to the pirates for those widevine L1 keys. i.e. they sacrifice device after device as the keys get killed. It's much easier for netflix, amazon to blacklist an L1 key than it is to blacklist L3 keys (its almost pointless to do that from a piracy prevention perspective)

Are you sure about that? The vast majority (err ... all, as far as I can recall) of webrips I encounter are reencodes. You don't need access to the original DRM protected stream for that, only the final decoded output. HDCP is the weak link there. You can purchase very cheap dongles that strip the encryption.

What wouldn't surprise me in the slightest is if the widevine devices are stenographically embedding a fingerprint in the video signal and getting burned because of that. I don't have any evidence that's happening but it would surprise me if it wasn't.

A GPU could use a TPM to "activate" the "credential" to extract a symmetric session key and then do all the bulk decryption in the GPU. This does not invalidate your argument that the FSF is focusing on the wrong target though because the GPU vendors could just implement the TPM-like protocols in the GPU anyways.

https://news.ycombinator.com/item?id=42572090

A GPU couldn't do that, the OS could, and then pass it back to the GPU. But that would mean the session key was visible to the OS, which would defeat the entire point.

Oh, sorry, I see the scenario you're describing now (the GPU establishes a communication session with the TPM that's opaque to the OS) - the easy way around that would just be to fake a TPM, unless the GPU itself is going to have a database of every legitimate EK cert CA, which would mean this would stop working if the GPU were plugged into a machine with too new a TPM.

So how would it be explained that high quality versions of pirated video streams, ie. 4k are available the same day as 1080p?

tee, tpm, gpu... it doesn't matter, drm gets broken.

My takeaway here is

- the fsf is fine with the tpm, as long as it runs free software (apparently the kind of work you do)
- the fsf has a problem with drm, not with the tpm
- the fsf might have mixed up win11 tpm requirement to be a drm requirement - but that's not really clear at this point for me. i'd like to see what a drm developer says about that
- the fsf absolutely should demand accountability from gpu vendors as well regarding drm
- you continue to "shill" tpm even though you have been burned by events like microsoft accidently prohibiting linux to boot - something you said would never happen. This very sentence of mine is likely super offensive to you and will likely continue to reinforce your narrow view on this, so it kind of defeats me writing this.

So like, could I see a scenario where hardware drm on Windows is implemented in a way that in order for 4k stuff to playback the session key comes from the tpm and then decryption is handled by the gpu. Microsoft then gets to say everything is secure (compliance blabla) and piracy people get to copy and release unencrypted 4k media on bittorent. Plausible?

cowardly anon, too lazy to create an account
In any case, I'm remain very interested in your technical writing and posts like these from you.

The point is, fundamentally, because of where the TPM is situated in the system, it can't be used in a "DRM secure" manner, any keys would end up in the OS (or the GPU has to have weird amounts of knowledge hardcoded in it)

the TPM is not involved in DRM, because there's no benefit to the DRM to have the TPM involved.

as for how 4K stuff ends up on the internet, all it takes is the TEE on one of many android devices with L3 widevine implementations being compromised - like on any Tegra X1 device where you have arbitrary code execution in the bootrom.

you continue to "shill" tpm even though you have been burned by events like microsoft accidently prohibiting linux to boot

I would like you to explain to me how a TPM can prevent a machine from booting.

The closest thing I can find is Microsoft pushing out SBAT updates that broke double boot. Which is Secure Boot, which has nothing to do with the TPM. At all.

"Playready hardware-based DRM works just fine on hardware that doesn't have a TPM"

Any example?

It would help to clarify what definition of "TPM" is being used. For example, from an EU copyright law perspective, the TEE or GPU funcionality described here is definitely a technological protection measure/technical measure.

In this case, TPM means Trusted Platform Module, not Technical Protection Measure.

Ok, so what is the definition? Chips conforming to ISO/IEC 11889? If so, it seems there are two assumptions I'd like to read more about:

- That the FSF talks about ISO/IEC 11889 too
- That the mentioned GPUs and TEE do not conform to ISO/IEC 11889

Also an assumption that we should care about such DRM-industry-defined standards, but we can skip that one.

(I'd also still like an example of TPM-free hardware running those DRMs.)

The FSF is talking about TPMs as defined by the Trusted Computing Group, as demonstrated by their reference to them being required for machines to run Windows 11. No GPU implements this specification.

If you want to see this work on a device without a TPM, simply take any machine capable of running Windows 10 that doesn't have a TPM, plug in a Geforce 10 series or later card, and observe that the Netflix app will serve you 4K HDR video.

This is surely the world's stupidest question on the subject, but: Windows 11 won't run on hardware without a TPM, but on the other hand, it runs just fine in free virtualisation systems. I've run Win11 VMs myself on stock Ubuntu Virtualbox. (On a host machine that as far as I know doesn't have a TPM.)

Surely Virtualbox can't provide anything that is "trusted" (by anyone at all) in the way that a TPM is supposed to be? Is there a special exception made for VMs on the grounds that it would be just too awkward if there weren't? Or is there some genuinely relevant property shared by TPM-equipped hardware and virtual machines, and not possessed by TPMless hardware?

As far as I know, 1) Windows 11 will run on hardware without a TPM if asked very nicely (and will run on hardware with the obsolete TPMv1 without much prompting), and 2) it indeed has an exception specifically for VMs, or at least had one around 21H2 from what I remember [it may have been removed?].

But also 3) Virtual machines can provide software-emulated TPMs (Hyper-V does, QEMU does, latest VirtualBox does) – although those won't have a valid EK (attestation certificate), but many things don't really care about attestation; they merely need OS-controlled storage without any of the DRM frills.

Specifically I suspect that Windows' TPM requirement is primarily due to BitLocker auto-unlock and/or Windows Hello (both the consumer FIDO2 one and the Business one), i.e. MS wanting to guarantee that those will be available on every system, instead of "may work if your manufacturer bothered to wire it up, I guess".

And neither of those features ask for attestation from the TPM; e.g. BitLocker just relies on the boot measurements unchanging from one boot to another, while Hello treats the TPM like if it were a classic smartcard.

Very informative, thank you! Maybe it wasn't the world's stupidest question after all. :-)

Microsofts motivation for TPMs in Windows is probably:
- Windows Hello (aka FIDO2, WebAuthn, Passkey)
- Bitlocker
- AD and cloud device management (Intune)

All of these require secure storage of secret keys. Many features in Windows and Active Directory environments require that the machine can authenticate itself to the domain controller etc. Companies also like to use it for VPN keys.

Android and iOS also make much more use of hardware key storage for all kinds of things than desktop operating systems.

A big problem is that the FSF is living in the 2000s when the TPM was the biggest worry, from Microsoft's ill-fated NGSCB.

While DRM sucks, streaming companies have a reason to use it: you don't own the content and they don't want people to slipstream content. And yes, I know pirate sites slipstream anyways.

The FSF needs to move on to newer problems, like Google Play Integrity API and modding. Or the fact that iPhones/Huawei/Verizon devices don't allow third-party OSes. Or how about preventing addictive ad-ridden feeds, that would be big.

Streaming companies do it only for compliance reasons. I doubt that they care as much. Same with HDCP being a compliance obfuscation.

So this whole dance is necessary to placate shareholders of entertainment companies, who can not accept the quality of service choices of the free market? And the panem and circensis nature of the whole entertainment industry? If a political entity gets a choice between fighting piracy and peacefull citizens through media consumption , it will choose survival, lobbyism be damned.

Does it really matter how correct the details of the FSF's argument is? Since you seem to understand the reason for their opposition to TPM, etc. What difference does the GPU stuff make? The article bash really only serves to undermine the FSF, which seems to be your intention (hm?). i.e. The lockout of the hardware is the only issue that matters (and it really deserves a lot of attention), not trivia about how it was introduced.

I suppose it doesn't matter how correct the details are, because the FSF being blatantly wrong has never stopped them in the past.

For a serious answer, doing political advocacy from incorrect premises causes you to make major strategic errors.

The FSF made an explicit claim about how TPMs are used, and argued that this was why Microsoft imposed a requirement for systems to have a TPM to run Windows 11. Since the first of these things is false, it entirely undermines the second. Hardware lockout is repugnant, but just making stuff up is not going to convince anyone of that.

The incriminating FSF sentence seems to be: Today, most of the major streaming media platforms utilize the TPM to decrypt media streams, forcefully placing the decryption out of the user's control. which doesn't say much about how, nor than why, TPM is used during media decryption, just hinting that TPM plays a part in the whole process (and we agree that it may not).

There is no "may not" - it does not. At all. Every single plausible interpretation of the statement is false.

It matters because it's obvious to any reader who understands the area in more than a cursory fashion that the FSF is either wrong, or lying through its teeth to get you to believe that there's a problem with TPMs, but not with Protected Video Path and similar technologies.

If I know that the FSF is either completely wrong or dishonest on a subject where I understand what's going on, why would I trust it on anything?

First, DRM is not just for video services.

Second, TPM 1 with SPI/LPC header on the motherboard is not DRM. DRM. It is simply a means of providing privacy in the presence of persistent malware. It doesn't protect against physical access: if a user needs to compromise his system he can always plug in a cheap microcontroller board.

Thirdly, any TEE, including those based on TPM 2.0, which is right in the processor and with remote attestation is primarily for DRM.

Fourth, protected media path is not the whole DRM, but only one of its components.

You're mixing up TPM 2.0 (which can also go on the SPI/LPC header that a TPM went on) with AMD's fTPM and Intel's PTT.

AMD fTPM and Intel PTT are implementations of TPM 1.0 and 2.0 on a microcontroller inside the main CPU; you can (and people do) have an external TPM 2.0 chip on the appropriate bus instead of inside the main CPU. And you could do remote attestation with TPM 1.0, not just with TPM 2.0.

Discrete TPMs and integrated TPMs both support remote attestation.

> Thirdly, any TEE, including those based on TPM 2.0, which is right in the processor and with remote attestation is primarily for DRM.

Can you point to a single application of TPM as a DRM in the PC space?

IMO Microsoft wants a TPM to do their own version of Google Play Integrity to force users to use OEM-provided software and block any app if it runs if the Windows installation was tampered in any way so OEMs can shove malware and bloatware down people's throats, people can't install Linux on their PCs, users are forced to upgrade their OS when Microsoft says so, etc.

Perfect article, sadly FSF are in year 2010 and will be necessary
a renovation of activism projects

A problem I see with the FSF's approach is that the people they need to influence (legislators, CEOs etc) are already deeply comfortable with the idea of dual-use technologies - that is, technology that can be used both for a good purpose, and for an evil purpose - and the FSF's argument is essentially "this tech has evil uses and is in the hands of someone we don't trust, therefore it's bad".

And stripped of emotion, the FSF's argument is essentially "this technology is dual-use, and the people you are choosing to trust with it are people we think are untrustworthy". But the technology is being used to solve problems you already have (TPMs used to back unphishable credentials, for ensuring that log-ins only come from your company's approved devices, and not from a hacker's device), and the problems that the FSF talks about are mostly hypothetical for now, as long as your suppliers that you trust don't turn on you.

For the FSF to convince people, it first needs to get its facts consistently right, so that it's not easy to discredit (which it's failed to do here), and secondly needs to actually try to convince people who currently trust Microsoft, Apple, Google et al but have no position on the FSF yet.

The biggest problem with DRM software such as Widevine, Fairplay and others, is the limited number of devices it is available to, Google and Apple have ultimate control of Widevine, and Fairplay respectively. This means that they have the right to limit it to certain devices (hardware and software combinations.)

GNU/Linux for X86 and ARM devices such as a Laptop and the Raspberry Pi respectively do have support for the Widevine library.

Often you can get it in the "Non-Free" software repository of a Linux distro such as Debian or Ubuntu. But often times it's not a version compatible with the best version of your OS.

There was no WidevineCDM library for 64 bit ARM, so users with a 64 bit raspberry pi had to use the 32 bit version of Debian for streaming.

And these versions in the repository are I believe just for Chrome. Which brings me to the next example of the same problem.

The Widevine library has to be the correct one for a specific browser. If it is made for firefox it has to use GeckoMediaPlugins. WidevineCDM for Chrome uses something different and closed source. So you have to use the correct version of the library for your browser and your OS, and there is no guarentee that it will be available for either. There could have a version for Firefox that only supports X64 Linux or if there is another for ARM it could be a version which only supports 32 bit ARM Linux. Other independently developed browsers could be left out in the cold.

And it has been reported the version in the Linux repositories can have quality problems with streaming, not allowing 4K either. Even on Windows, people have noticed a quality difference when using a browser, compared to a smart TV or streaming device. Content from sailing websites look better apparently.

People are spending 100s or even thousands on Smart TVs, which will probably be obsolete in a few years, just so they can get a good quality stream. And when they're obsolete, the streaming apps will cease to function no doubt, due to software updates being discontinued. Hope the landfills are big enough. Maybe they can make a section next the mountain of old FireTV sticks.

I find FSFs continued bashing of TPMs upsetting. I wish there was a bigger push towards TPM in the Linux and open source communities.

Stuff like D-RTM can replace device lockdown like Intel Boot Guard and AMD PSB, thus allow users the freedom to replace their firmware with an open source alternative. Maybe then we'd see more devices running coreboot.

ME firmwares are intel signed arbitrary code. It implements HDCP in intel integrated gpu and is part of protected media part. There are lots of criticism of ME (and I personally think anything except bootguard isn't useful in end user devices) and DRM is a horrible one.

Like anything else streaming services relies on market size. They'll use abusive measures like DRM only when most of consumer base can run it. I don't think most x86 users have discrete gpu and things like ME and trusty widevine app are making hardware DRM viable.

(idk if amd PSP works the same).

OTOH some people are seeing the silverlining that users will switch to linux due to tpm requirement in windows and soon cancel netflix when highest it gives is 720p. IMO the opposite will happen, those who even bother will see netflix doesn't work and switch back to windows and apply the script kiddy level tpm bypass.

We often forget in these discussions that people don't know and care if they're being treated as potential thieves, or that hardware DRM on 'premium quality' content is saving streaming business. At least 1080p is available in pirate sites for almost all contents and even for many pirated contents have higher quality than low bit rate streams. If everyone watching at 1080p cancels subscription tomorrow the charges for others will rise sky high to keep the parasites aka shareholders happy. Similarly music DRM never works but see at spotify.

People. don't. care.

(anon cause openid creds nog synced to this phone).

forgive the grammar :)

Flat | Top-Level Comments Only

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

Hardware DRM is broken too

Re: Hardware DRM is broken too

Re: Hardware DRM is broken too

no subject

no subject

no subject

no subject

no subject

no subject

TPM definitions

Re: TPM definitions

Re: TPM definitions

Re: TPM definitions

no subject

no subject

no subject

Microsoft's motivation

no subject

no subject

no subject

Distracting from FSF's point

Re: Distracting from FSF's point

Re: Distracting from FSF's point

Re: Distracting from FSF's point

Re: Distracting from FSF's point

Re: Distracting from FSF's point

no subject

TPM 2.0 is not always "right in the processor"

no subject

no subject

no subject

Dual-use technologies

The biggest problem with DRM software

no subject

Intel me is tee and supports DRM

Re: Intel me is tee and supports DRM