https://mjg59.dreamwidth.org/70954.html
Account name: [ ] Password [ ] [Log in]
(OpenID?) (Forgot it?) [ ] Remember Me
You're viewing [personal profile] mjg59's journal
Create a Dreamwidth Account Learn More
[ ] [Interest ] [Go]
Reload page in style: site light
Matthew Garrett
The GPU, not the TPM, is the root of hardware DRM
The GPU, not the TPM, is the root of hardware DRM
Jan. 1st, 2025 02:31 pm
[personal profile] mjg59
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.
Tags:
* advogato,
* fedora
* Previous Entry
* Add Memory
* Share This Entry
* Next Entry
---------------------------------------------------------------------
* 16 comments
* Reply
---------------------------------------------------------------------
Flat | Top-Level Comments Only
Hardware DRM is broken too
Date: 2025-01-02 03:46 am (UTC)
From: (Anonymous)
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.
* Link
* Reply
* Thread
* Hide 1 comment
* Show 1 comment
Re: Hardware DRM is broken too
Date: 2025-01-02 08:19 pm (UTC)
From: (Anonymous)
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)
* Link
* Reply
* Thread from start
* Parent
no subject
Date: 2025-01-02 06:07 am (UTC)
From: (Anonymous)
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
* Link
* Reply
* Thread
* Hide 5 comments
* Show 5 comments
no subject
Date: 2025-01-02 06:15 am (UTC)
From: [personal profile] mjg59
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.
* Link
* Reply
* Thread from start
* Parent
* Thread
* Hide 4 comments
* Show 4 comments
no subject
Date: 2025-01-02 06:17 am (UTC)
From: [personal profile] mjg59
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.
* Link
* Reply
* Thread from start
* Parent
no subject
Date: 2025-01-02 09:13 am (UTC)
From: (Anonymous)
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.
* Link
* Reply
* Thread from start
* Parent
* Thread
* Hide 2 comments
* Show 2 comments
no subject
Date: 2025-01-02 11:45 am (UTC)
From: (Anonymous)
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.
* Link
* Reply
* Thread from start
* Parent
no subject
Date: 2025-01-02 12:19 pm (UTC)
From: (Anonymous)
`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.
* Link
* Reply
* Thread from start
* Parent
TPM definitions
Date: 2025-01-02 12:01 pm (UTC)
From: (Anonymous)
"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.
* Link
* Reply
* Thread
* Hide 1 comment
* Show 1 comment
Re: TPM definitions
Date: 2025-01-02 02:42 pm (UTC)
From: (Anonymous)
In this case, TPM means Trusted Platform Module, not Technical
Protection Measure.
* Link
* Reply
* Thread from start
* Parent
no subject
Date: 2025-01-02 12:07 pm (UTC)
simont: A picture of me in 2016 (Default)
From: [personal profile] simont
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?
* Link
* Reply
* Thread
* Hide 2 comments
* Show 2 comments
no subject
Date: 2025-01-02 01:51 pm (UTC)
From: (Anonymous)
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.
* Link
* Reply
* Thread from start
* Parent
* Thread
* Hide 1 comment
* Show 1 comment
no subject
Date: 2025-01-02 01:59 pm (UTC)
simont: A picture of me in 2016 (Default)
From: [personal profile] simont
Very informative, thank you! Maybe it wasn't the world's stupidest
question after all. :-)
* Link
* Reply
* Thread from start
* Parent
Microsoft's motivation
Date: 2025-01-02 03:22 pm (UTC)
From: (Anonymous)
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.
* Link
* Reply
no subject
Date: 2025-01-02 07:58 pm (UTC)
From: (Anonymous)
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.
* Link
* Reply
* Thread
* Hide 1 comment
* Show 1 comment
no subject
Date: 2025-01-02 10:50 pm (UTC)
From: (Anonymous)
Streaming companies do it only for compliance reasons. I doubt that
they care as much. Same with HDCP being a compliance obfuscation.
* Link
* Reply
* Thread from start
* Parent
* Previous Entry
* Add Memory
* Share This Entry
* Next Entry
* 16 comments
* Reply
Flat | Top-Level Comments Only
Profile
Matthew Garrett
About Matthew
Power management, mobile and firmware developer on Linux. Security
developer at Aurora. Ex-biologist. [personal profile] mjg59 on
Twitter. Content here should not be interpreted as the opinion of my
employer. Also on Mastodon.
Page Summary
* (Anonymous) - Hardware DRM is broken too
* (Anonymous) - (no subject)
* (Anonymous) - TPM definitions
* [personal profile] simont - (no subject)
* (Anonymous) - Microsoft's motivation
* (Anonymous) - (no subject)
Expand Cut Tags
No cut tags
Top of page