I fully get the DRM hate.
Now I donāt really follow the Windows world but I thought the goal of the newer TPM stuff was to be able to provide a trusted boot chain the way Apple does. Iām under the impression that some of the earlier versions allowed the TPM module to be a separate piece of hardware from the CPU and thus exposed an hardware attack path where someone could snoop or man in the middle.
If you have a full trusted chain you can certainly use that to ensure that the DRM isnāt being tampered with. But I kind of doubt thatās the main reason behind all of it. There are enough good reasons they may want better security on the hardware outside of that it seems justifiable that they might push it.
Iām not arguing itās good or bad, I just donāt think itās 100% about DRM and the rest is a smoke screen.
DRM is a government sanctioned desecration, by corporations, of your private property rights, by its very definition.
Whether itās in the GPU, CPU, TPM, or any other part of computing property you ostensibly own, is an utterly irrelevant distraction, the root is the unholy alliance of government and capital power.
This is a much more accurate statement than the hate on the TPM. As the article describes, it is the GPU that has its own separate memory space that it can show on the screen without the CPU being involved at all.
I expect next generation workarounds will involve virtual GPUs.
I have to wonder A) What does DRM realistically accomplish for the media companies? And, B) How are these DRM schemes actually being defeated? I do occasionally don my pirate hat* and have never had an issue finding what I want at the quality I want within an hour of a episode/movie being released to streaming. That would seem to indicate that these efforts at DRM are actually failing to have any noticeable effect at all.
[*] Jellyfin & and the -arr daemons are far more usable and stable then wading through the various streaming services interfaces, so I'll download episodes even though I do actually pay for the streaming services.
Thereās some technical details missing here. I get decrypting the video on a gpu makes it harder to screen capture, but canāt you just still emulate the GPU in software or directly capture the digital video output? The GPU still has no unique hardware private key, right?
Doesn't the article forgot to mention that TPM allow to do trusted boot and remote attestation ? It sounds like to me that could very well be used to make software DRM more efficient (by making sure you run a DRM friendly OS for example)
>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.
This sounds 100% on-brand for the FSF. The FSF's primary public-facing persona has peculiar computing habits so far removed from the mainstream that it's likely he has absolutely no clue how the real world works.
In fact by his own statement he has to rely on volunteers to update his website.
It's disappointing to me because the FSF could be so much more influential today, but the cult of personality around RMS has really destroyed their public credibility among "normies", the most important demographic to convince.
When the FSF finally realizes that a political organization such as theirs needs a public face with charisma and social skills, it will be too late.
The embedded politics of the ātā in ātpmā and āteeā are super interesting and revealing. They are ātrustedā only from the perspective of the developer; to the user, they represent the complete lack of trust.
Suggestion for a compromise: Make it mandatory for TPM vendors to provide a user option to wipe all attestation keys and rebrand them as āembedded security keysā (and maybe promise to never use them for DRM, which per TFA nobody is anyway).
I feel like untangling the attestation capability (which I do believe has non-user-hostile/non-zero-sum uses!) from the secure key storage one might ultimately help their adoption.
Ah yes. DRM.
1. Companies offer service that people don't want to pay for, and blame piracy.
2. Someone realizes that they can eliminate piracy and make lots of money by offering good service.
3. Piracy slowly dies, because people prefer ā¬5 monthly subscription over torrent.
4. Other companies catch up. The market gets fragmented. By the nature of the market, it becomes impossible for one company to offer clearly good service.
5. Piracy gets fashionable again because it's more accessible than having twenty ā¬50 subscriptions, half of them with ads.
6. Companies offer service that people don't want to pay for, and blame piracy.
But afaik the TPM (or fTPM if no chip is present) is used to establish and restrict trusted access to the replay-protected memory block that the GPU (or other) DRM chain services depend upon to do their thing.
IMHO the author does overrestrictively interpret the FSS statement to discredit them.
i've done a lot of work with Arm TrustZone, OP-TEE, and Arm Trusted Firmware. it's really nice. in Arm, the TEE is user-supplied, not vendor-supplied, so it gives an isolated execution environment for any sensitive code you might want to put in there. hardware peripherals (tzc/spu) allow you to designate certain bus addresses or memory ranges as "secure" during the early firmware initialization, meaning Linux (or whatever OS you use) cannot read or write to them. furthermore, unlike a TPM, the TEE isn't running in parallel on a co-processor -- it only runs when Linux yields control (cooperative scheduling) so it provides functionality without wrestling away control.
The author seems misinformed about the purpose of TPM to DRM schemes.
The purpose of a TPM, in this case, is not to provide encryption, but instead to provide so-called āauthenticityā. A TPM with its attestation capabilities can allow a remote validator to attest the operating system and system software you are running via the PCRs which are configured based on it, with Secure Boot preventing tampering. [1] Google tried to implement APIs to plug this into the Chrome browser, which was later abandoned after backlash. [2]
In this case, the TPM can allow services like Netflix or Hulu to validate the hardware and software you are currently running, which provides the base for a hardware DRM implementation as stated in the article. Donāt be surprised if your non-standard OS isnāt allowed to play back content due to its remote validation failing if this is implemented.
TPMs also have a unique, cryptographically verifiable identifier that is burnt into the chip and can be read from software. This allows for essentially a unique ID for each computer that is not able to be forged, as it is signed by the TPM manufacturer (in most cases Intel/AMD as TPMs on consumer hardware are usually emulated on the CPUs TEE). If you were around for the Pentium III serial controversy, this is a very similar issue. It's already used as the primary method of banning users on certain online video games, but I wouldnāt be surprised to see it expand to services requiring it to prove you arenāt a ābotā or similar if it gets wider adoption.
There is a great article going more into detail about the implications of TPM to privacy from several years ago, which was the basis for this reply. [3]
[1]: https://github.com/MicrosoftDocs/azure-docs/blob/main/articl...
[2]: https://github.com/explainers-by-googlers/Web-Environment-In...
> GPU vendors have quietly deployed all of this technology
Citation or technical details needed.
Obviously it "makes sense" that for 4K HD content you "probably" want to offload the decoding into the GPU, but this is the first time I see this mentioned and there are no links to technical details.
In contrast, TEE / TrustZone and even the recent AVF with pVM - these are well documented technologies.
If you go deep enough down the rabbit hole, it becomes very clear why a TPM is necessary.
DMCA 1201 should be reversed and DRM itself should be illegal.
Is it possible that some of the readers FSF is targeting may not be using a dedicated GPU.
> 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.
> 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.
It is quite obvious: to force people to buy a new PC. TPM provides no added security value for the vast majority of users[1] but it is a convenient hardware that has only started to become standard (fTPM) in PCs built in the last ~8 years so it provides an excuse for Microsoft to declare computers older than that (which can run Windows 10) obsolete using "security" as an easy scapegoat.
[1]: https://gist.github.com/osy/45e612345376a65c56d0678834535166
2008, Protected Audio/Video Path (PAVP), https://www.anandtech.com/show/2622/2
Movie studios wanted a way of securing the content between the time the AACS was decrypted and the HDCP encryption took over. Once the AACS was decrypted the encoded movie was sitting in main memory and could be intercepted by any other application.. The solution was to re-encrypt the data once it was pulled off the disc (I'm not kidding).. encryption would be done by the application.. The graphics driver would be able to pass along the encrypted data to the GPU, which would then decrypt and decode it in hardware and then the entire framebuffer would be HDCP encrypted by the GPU before sending it out over DVI/HDMI.The top comment pretty much sums up everything thatās wrong with DRM:
> 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.
[flagged]
The author is correct in that media DRM is tied to GPU vendors on the field right now.
But hardware backed DRM can be so much more invasive beyond that. I have no doubts the long term goal of MS is to have a Windows version of Play Integrity.[0] So total control over everything that happens on your device. Just to give an example of what could happen if this becomes reality: https://en.m.wikipedia.org/wiki/Web_Environment_Integrity
This tech extended to browsers could easily mean that sites could refuse to serve you if your machine is running any bigcorp unapproved software. An easy example of that would be adblockers.
Unless we get lucky with secure world compromises like the Tegra X1 bootrom exploit[1] or get real good at passing legistlation that forces companies to give you all the private keys to your own machine, the future for personal computing is looking grim.
[0]: https://developer.android.com/google/play/integrity
[1]: https://github.com/fail0verflow/shofel2