The real question is
"What's your threat model?"
If it's people stealing your laptop and fear of identity theft, use the TPM.
If it's the NSA, ¯\_(ツ)_/¯
"What's your threat model?"
If it's people stealing your laptop and fear of identity theft, use the TPM.
If it's the NSA, ¯\_(ツ)_/¯
Netflix playing at lower resolution for example.
Widespread TPM is actively harmful for most people, and the biggest blow to general purpose computing in recent years.
Nobody is forcing you to use Netflix. If you don't like it, leave for a better DRM-free service. That's the free market at work.
Or maybe they will all move to TikTok and live from advertising and you'll get a chance to complain about how you hate ads then.
Which one?
Is it a free market if 99.9% of companies copy the single most profitable approach to stay afloat (see smartphones), or the entire market is dominated by content rights holders that would make you pay license fees to use the toilet if they could?
That doesn't entitle you to a specific video unprotected. But the video market is pretty unquestionably not dominated by content right holders (if by that we mean major studios).
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.
And this is a supposedly tech focused platform where the tech literacy is at its highest. I wouldn't be surprised to read comments that TPM is used by Bill Gates to give you Covid.
> I wouldn't be surprised to read comments that TPM is used by Bill Gates to give you Covid.
One time on here, someone linked an academic paper describing an HTTP PCIe accelerator. One of the (eight) authors was from Tsinghua, and so naturally someone in the comments started freaking out about how this was a plan by the Chinese Deep State to fund this for mass surveillance. When I asked him how this would work and what threat he expected, he described an elaborate Tom Clancy plotline where these PCIe cards will actually be snooping every key exchange, keeping them in memory, and they would be secretly equipped and manufactured with short wave radio devices that would allow Chinese agents to "exfiltrate private keys" (whatever that means) by posing as janitors and technicians in the datacenter and beaming those radio messages to them.
That was his threat model for "thing you literally plug into your fucking server and put on a shared memory bus."
Now, how this is expected to work when most HTTP accelerators don't do key exchange (and never ever see long term keys), or how these keys would benefit them when presumably many encrypted comms do not go through cables controlled and spliced by the nefarious, evil-loving CCP -- well, that's left as an exercise for you!
No one would be the wiser.
https://www.ebay.com/itm/186136320010?chn=ps&mkevt=1&mkcid=2...
MS already has TPM and secure boot requirements. What's stopping them from colluding with the Copyright Cartel and embedding keys in the firmware that, if removed, disable functionality on the device or on property networks?
You are giving FAR too much trust to entities proven to have an interest in limiting computing freedoms.
That Nvidia, Intel and AMD already put a better black box with a smaller attack surface in the GPU years ago for them to use.
There's a poster below that provides a more reasonable use case for TPM. Headless server where asking for password on boot is undesirable (eg after a power failure)
A TPM provides hardware-backed bruteforce protection which means even an easy passphrase can be made secure as the number of attempts is rate-limited by the TPM (to a level much slower than even the hardest hashes).
People tend to trust them more because they belong to them, not Microsoft, or Hollywood, or the board manufacturer.
A YubiKey/external TPM in comparison has no way to know whether it's being fed true PCR readings from the host or fakes from a malicious attacker, so at this point it will be no different (in the context of full-disk-encryption) from just having a dumb USB storage device with your LUKS keyfile on it.
Why take unnecessary risks when you can just use GRUB+LUKS and type the passphrase at boot?
TPM is the same - any known vulnerabilities would generally get patched as part of firmware updates released by your vendor.
If the TPM is known vulnerable and a patch doesn't exist then fair enough you can stop using it depending on your threat model, but the same can be said for software implementations.
> when you can just use GRUB+LUKS and type the passphrase at boot?
This is a user experience drawback and opens you to other avenues of attack like passphrase bruteforce if you don't choose a strong (and inconvenient/slow to type) one. It's also impossible for servers or embedded devices which you want to be able to boot unattended.
It's not really: LUKS is an open standard and GRUB is a free software that implements it. With a TPM you're likely to get a chip that is 100% a black box, with the exception of a few people who signed NDAs and researches that have knowledge and tools to poke into it.
> generally get patched as part of firmware updates released by your vendor
If it can even be fixed with a softwar update. Also, you're very lucky to get maybe a couple of years of firmware updates, then your're on your own.
This is good enough for the 90% of people who currently operate without full-disk-encryption at all. It would be a huge improvement.
Obviously, it's up to each individual user to evaluate their threat model and proceed accordingly. Nobody is forcing you to use a TPM, you can still use LUKS/etc and completely ignore the TPM.
From my memory it was every zen module up to and including zen3.
It's possible that zen4 has been fixed but I'm not certain about that.
There is a "requirements" section of the PDF that talks a little bit more about which CPUs were effected but that isn't distilled!
In my experience, tpms are worse than worthless since they prevent rescuing garddrives from bricked systems. Nontpm luks can be unlocked on any system.
It'll only prevent you from recovering a hard drive if you configured it that way - ie it's doing its job as designed.
I understand that I will be protected from removing the HDD/SSD and putting it into another machine to read the data, but does it really protect me from anything else?
Being unable to retrieve the data on protected drives (which could include cookies, passwords, ID, photos/videos, etc.) is the value.