> Like most ordinary folks, my threat model is the use of TPM for DRM.
TPM is pretty much useless for DRM.
TPM is pretty much useless for DRM.
However, TPM-backed DRM on general-purpose OSes is impossible in the current world and is fear-mongering. The TPM can attest to a remote party that you've booted a certain OS, but this OS would need to maintain that chain of trust all the way for it to be effective. That's impossible due to the number of device drivers (which need kernel-level access by design) and various other privileged components a general-purpose OS requires (security software, etc), not to mention the attack surface of all that.
For a hypothetical TPM-backed DRM to work, you'd need Netflix to ship you an entire OS image that you can boot (which the TPM will prove to them that you've booted), and that OS image needs to magically have all the drivers for every potential PC their customers might have, and you need to convince people to reboot their machine every time they want to watch it.
This is all unnecessary considering the current status-quo of DRM is good enough, Widewine does not require a TPM and relies entirely on security by obscurity and it's considered good enough by the industry.
This is all theory though - workable TPM-backed DRM would require so much vendor cooperation, secure programming and break legitimate use-cases that it won't happen any time soon on conventional hardware. It would be cheaper for the media industry to just sell streaming boxes or exclusively target more locked-down platforms (iOS, Android) than try to make it work on generic Windows PCs.
But as you say, that's a much, much smaller attack surface than trying to validate the OS.
Why don't you think that can work? Windows already limits drivers to ones signed by Microsoft - or else you have to be in "test mode" where - among other things - DRM-protected video playback is disabled!
And Windows already contains a "protected media path" component which protects encrypted DRMed video data.
Sure, there will probably be bugs in a drivers sometimes allowing for a signing bypass and then a DRM bypass if the DRM is done in software. Once they're discovered, those drivers will be blacklisted, and yes, that will mean you can't use that hardware. And the masses will blame the pirates.
I don't believe driver signature enforcement restricts what the driver can do, intentionally or as a result of a vulnerability. Maybe your driver intentionally allows user access to privileged kernel memory, or has a vulnerability that allows the same? Also, signing keys leak every so often.
A TPM is useless for DRM on a general purpose computing platform because it is significantly inferior to existing widely deployed solutions.
DRM is already a software thing - 720p video is protected by software Widevine. Has been for years.
Widevine's highest security level, L1, does not rely on security by obscurity. But it doesn't rely on a TPM either; rather, it relies on a trusted execution environment, like ARM TrustZone or Intel CSE[1], that is more highly privileged than the OS itself. Microsoft PlayReady is similar.
Apple FairPlay, in contrast, is worse: it's disabled if you turn off Secure Boot on Macs.
[1] https://www.intel.com/content/www/us/en/developer/articles/n...
In practice places that want "attestation-like" functionality, like Riot do for anti-cheat, just load mandatory kernel modules instead and require e.g. Type 1 hypervisor-based security in Windows to be enabled. Or they just obfuscate everything and run blobs. These can still be bypassed but it's still difficult and in contrast fully controlled by their software stack, which is more usable for them for more players. It's good enough, in other words.
Linux will never be approved, unless it's heavily locked down, by the way.
You can also look at how any other DRM works. It's all based on hardware and software locks very similar to what TPMs do.
But services still use that rather than a TPM, because a TPM is useless.
NOTE: This proposal is no longer pursued.
Thank you for all the constructive feedback and engagement on the topic. An Android-specific API that does not target the open web is being considered here.