Widevine L1 requires a trusted execution environment for decrypting video and only showing it on HDCP monitors. It's built on top of Intel PAVP, AMD secure display, or ARM TrustZone in the case of ARM chromebooks and Android devices. TPM is not involved, except in the ARM case where I believe it is used for antirollback counters (on x86, the security coprocessor would probably have that responsibility).
> Does TPM support/requirements actually have any meaningful impact on a home user?
Disk encryption, Windows Hello and PIN bruteforce prevention. I have no love Microsoft and avoid using Windows whenever I can, but I think making those features accessible to more people is a good thing.
I was under the impression that Bitlocker wasn't available on Windows Home?
If you have an older computer, without TPM 1.2/2.0, then you already don't things like Windows Hello, but you might have secure boot and some brute force prevention, so you wouldn't be worse of as a home user if Microsoft allowed you to run Windows 11.
For new computers I can completely understand that Microsoft would demand that vendors ship systems with TPM 2.0. For upgrades I just struggle to see any really compelling reason, it's not like Apple where Microsoft is trying to also sell hardware, that's mostly on the OEMs.
As of Windows 11, you can use Bitlocker on Windows Home.
(Personally I think you probably shouldn't bother with it unless you set a boot PIN, which still requires Pro to be allowed to change the right group policy settings.)
There are none. It's so immensely frustrating to me that so many people believe that a TPM is a DRM device. I'm sure Richard Stallman's Treacherous Computing article played a big part in this.
A TPM is useless for DRM, and there are way more suited solutions like Intel's PAVP that takes an encrypted video stream and puts it on the screen directly, yet I don't see nearly as much uproar about that.
In a sense, graphics cards are the root-of-trust for PC-based DRMs (as they implement the necessary components such as HDCP authentication), not the TPM (which is useless for this task). In fact, PlayReady (which is Microsoft's DRM solution) does this exact thing: https://learn.microsoft.com/en-us/windows/uwp/audio-video-ca...
(...or use things such as the already-dead Intel SGX, which never touched TPMs at all)
It goes TPM → OS Integrity (dm-/fs-verity) → Browser Attestation (Web Integrity) → Your banking website no longer working on Linux because of "security". It’s Play Integrity for the PC.
Encrypted video is a red herring. The real long game is to also get your "secure" video player to refuse playback if it detects watermark in the pirated video. This patches the analog hole.
If you have attested Windows it can just refuse to download "freeworld" VLC because it can be used for piracy and/or even watching child pornography. Imagine that!
Of course you can use Linux instead but now you have to use the approved distro that also won’t let you run "dangerous" apps.
This is of course slippery slope argument and Microsoft would not be able to force all that right now, but better get started on the foundations. Some future government can then just force them to implement the rest, but by then it will be just a flip of a switch.
"TPM is not DRM" argument seriously lacks imagination.
Google SafetyNet is basically swiss cheese with lots of bypass solutions for custom ROMs.
A TPM may only attest that it has received an expected set of measurements (hashes). As long as discrete TPMs or PCs with unlocked CPUs exist (w/o Boot Guard), one may simply take a TPM and replay "golden" measurements to it. Bypassing this would be trivially easy.
A TPM does not have control over execution on the CPU. It only receives data from the CPU. If you have control over execution on the CPU from the reset vector, you can just replay whatever you want to a TPM and extract secrets that way. That's why TPM backed disk encryption without configuring a PIN is insecure.
Microsoft does not have the same level of control over the entire PC ecosystem as Google has over Android. That's why it's important to support open source alternatives.
And that’s why Play Integrity is based on hardware attestation and it is no longer a swiss cheese? And Win11 requires specifically TPM 2.0 (usually fTPM) not just any TPM.
You’re also entirely missing the point. Yes, you can bypass TPM based DRM to extract the unencrypted video (or just analog hole it) that’s why the game is to lock down the OS so you just can’t play it.
If all DVD players came with watermark detection instead of copy protection you wouldn’t have bootlegs because now every single client device needs to do the bypass instead of just once to extract unencrypted stream.
How many people have bypassed or hardware modded Playstations or Switches? This is what you’re talking about. Almost everyone will just accept it.
> If all DVD players came with watermark detection instead of copy protection
That is an enormous "if". Do you think Microsoft is going to or is able to enforce this on every single software provider? Even in your Android example that's just not happening, and you can happily sideload apps. You can still develop your own apps on the same Android phone that you use for banking.
> And sorry but how many people have bypassed Playstations or Switches. This is what you’re talking about. Most people will just accept it.
People accept this with consoles because a console is a device exclusively for consuming media, and all developers apply for a devkit. I just don't see that happening in the PC space. You think Microsoft is suddenly going to dump this on third party software developers and force everyone to go through certification and to buy devkits? Without a mass exodus to Linux?
How would you do it if this was the goal? First you introduce TPM to every device under the sun until it’s everywhere, then you just have to flip a switch. You write Patriot Act then stash in the drawer until it’s time...
> you can happily sideload apps.
This is extremely weak argument when the other major platform does not let you do that, right? Sideloading could go away at any moment just like that. That’s my point. There’s nothing technical stopping it.
> People accept this with consoles because a console is a device exclusively for consuming media, and all developers apply for a devkit.
Already Windows has: Smart screen (which requires code signing) and app store. Locking down the OS and Apps is hardly unprecedented. Both Windows and MacOS now have developer modes which is a software devkit equivalent.
> Without a mass exodus to Linux?
That’s why you wait until mass adoption (win11) only then start boiling the frog.
Look, I acknowledge this is slippery slope argument. But the slope is very slippery. Something is clearly going on.
>And Win11 requires specifically TPM 2.0 (usually fTPM) not just any TPM.
There are TPM 2.0 dTPMs. If the conspiracy is that they want to push people towards "hardware attestation", then they're doing a pretty bad job.
>You’re also entirely missing the point. Yes, you can bypass TPM based DRM to extract the unencrypted video (or just analog hole it) that’s why the game is to lock down the OS so you just can’t play it.
There's no need to "lock down the OS" when there's already a locked down OS on the CPU itself (intel SGX), is way more secure (because it doesn't have a bazillion userspace programs and third party drivers loaded), but for whatever reason gets way less flak than TPM.
Intel SGX was never pushed on anyone and it's also Intel only Skylake to Ice lake and requires vendors to provide consistent firmware updates to stay secure. You can’t run the entire OS in SGX enclave because it can’t do I/O on its own.
> There are TPM 2.0 dTPMs. If the conspiracy is that they want to push people towards "hardware attestation", then they're doing a pretty bad job.
No "normies" are doing TPM bypasses. That’s the point. Majority will eventually be on unbypassable TPM.
Considering that's the only way to play most DRM protected 4K videos, it's probably more of a "push" than requiring TPM. It didn't even have the fig leaf of being usable for FDE or webauthn.
>No "normies" are doing TPM bypasses. That’s the point. Majority will eventually be on unbypassable TPM.
If the bar is "normies", then you don't even need TPM. You can just slap denuvo or whatever and call it a day.
You can just not buy blurays, they were never popular on PCs anyway. TPM is being pushed on everyone upgrading to Win11. One is opt in, the other is maybe opt out if you jump through hoops, for now. Very different. Also you can do other things with SGX though admittedly it’s mostly useful on servers, but you would still use SGX indirectly via remote attestation. E.g. it’s what Signal uses for some of its core functionality.
> If the bar is "normies", then you don't even need TPM. You can just slap denuvo or whatever and call it a day.
Again, missing the point. Denuvo, Widevine, whatever, it’s all weak to crack once & enjoy but only if you control the OS. The Great TPM Conspiracy Theory is about limiting what you can do with your mainstream Windows/Linux/Macos installation, in the ways I’ve laid out earlier. Taking the ‘P’ out of PC.
I firmly believe that permanent key fusing to lock bootloaders should be outlawed. At the very least the keys (and schematics) should be released once the device reaches EOL.
Agreed. We really need some sort of regulation that prevents companies from bricking devices they sold. It's just so unethical, and wasteful, to put these devices out there and then just turn them into trash.
It should be required from day one. This tying of specific user-environment software to hardware is a straightforward antitrust issue, and frankly should never have been allowed to fester as long as it has.
The industry should be made to move to security models that don't revolve around baking in manufacturer-privileged keys (verification or attestation). Internal groups developing any default user-environment software should have to stay at an arms length from the hardware team, and only be using published documentation.
Any connected device NEEDS continual updates in order to continue to be secure.
This is particularly true of internet connected devices, but is also true for IOT devices that only connect to the internet indirectly. Security holes get found, if you can't patch and update devices in the field then you are leaving your customers unprotected.
> Any connected device NEEDS continual updates in order to continue to be secure.
And I feel that updates are being abused too much by device makers now:
-allows making devices worse, say "optimizing" the UI e.g. to make you spend more time in the parts they (not necessarily the user) want you to see
-allows releasing half-finished games since they can just be updated later anyway
-allows breaking old functionality for whatever reason
-allows the device makers to choose when to do the update rather than the user, say just when you want to start playing a game
It's a shame there's no less invasive way to ensure devices are secure. It sure is convenient for the device makers that the solution to security also gives them continuous control over your device's features and when you can actually use it
There is security and there is cargo cult. "unprotected" really depends on what the user is using the device for, what the vulnerabilities are, and what's the worst thing someone with total root level access to the device can actually do.
If the device is using a read-only firmware, has a secure boot chain of trust, lives behind a firewall and only makes outgoing connections, the risk is very limited. You can't directly connect to it, so your only option is to tamper with traffic in transit and exploit some buffer overflow in how it parses replies to its requests - that's already a very targeted attack that's really hard to scale, and with an intact secure/trusted boot chain it still means you can't persist so you'd need to redo this every time the device is rebooted.
And finally, assuming you manage to do all the above, what't the payoff? For a "Car Thing", the payoff is quite limited. I guess you can blast obnoxious music at full volume against the user's wishes?
It's not just security, but simple functionality too. Connected devices rely on remote services, by definition. Those services' APIs will change and get deprecated over time. At the very least, you need to keep clients up-to-date to conform to those API changes.
"Your services" aren't entirely yours. Practically speaking, no one builds systems entirely from scratch. A service likely has remote dependencies too, some of which will trickle down to the clients of your service. For Spotify specifically, they rely on SSO providers and third-party payments services; if those APIs change, then the client will likely require updates even though Spotify didn't change anything in their own core functionality.
Doesn't sound like its an update that bricks them, thought the article is a bit confusing on that point. Sounds to me like they broke the API (or just blocked this particular User-Agent)
EU legislation on power chords gave us micro-USB phones, when USB-C could have been a better option, but a real solution would be let consumers decide inputs/outputs.
Micro-USB was legislated years ago when each phone had a different charger plug. Currently the standard is USB-C. I also suspect that the EU only mandates a charging & plug standard but it's up to the industry to choose one.
A regulation requiring companies to "let consumers decide inputs/outputs" would be much more burdensome than merely standardizing one specific connector per ~decade. With the compactness of modern devices, they'd basically have to spin a new board for every connector type a consumer might what. But you're right - it would be kind of neat if I could have Google make me a new Pixel 8 with the bespoke data connector from my old SPH-A580, so I'd finally once again have a use for that cable that's just sitting around in a box. This is what you meant, right?
Regular major and minor chords were unaffected though :)
(I actually started reading this comment as a pun, as in "The EU can regulate music streaming - they already regulated power chords", and that made me smile)
I thought the same thing and was going to reply before I saw your comment. I wonder if there’s a term for typos/mis-spellings that form an unintended word or phrase that still makes sense for that particular context.
This is a fascinating misunderstanding of history. Were you not around when phones all had unique, non USB charging cables? It was a nightmare trying to charge a phone or device if you forgot your charger.
> but a real solution would be let consumers decide inputs/outputs.
When trillion-dollar companies consider a serial connector to be a proprietary and DRM-enabled apparatus I think the "real solution" is precluded by entirely unnecessary corporate greed.
Realistically how many people are going to bother reflashing their devices? This case is exceptional because it was EOLed so early, but for the typical phone that reaches EOL in 2 years I doubt more than 1% of people are going to make use of this ability.
It's a chicken and egg problem. There isn't much firmware being developed for these devices because there is no easy path for users to install them.
If installing alternative/third-party firmware becomes easy and normalized, there will also be more options to choose from, because it will actually become worthwhile for people/companies to develop said firmware.
I think if the process was made easy, it would save quite a bit more than 1% of these devices from the landfill, assuming you have enough power users to build a community. Plenty of people flash their chromebooks to MrChromebox UEFI to give them a new life, because it's easy enough for mere mortals, and because Google doesn't lock them down.
I believe if given the tools, people would gladly donate their time to make something fun with it. Heck, that's what I do in my spare time. But it's impossible if everything is completely locked down, as if a music streaming box contains nuclear launch codes that must be protected at all costs.
If you have an easy way to flash any phone and plenty of firmware available, it makes sense to turn flashing into a business. Buy used phones off people who don't need them any more, reflash them with a newer and debloated Android, and then sell them off for more than you got them for.
This would very quickly lead to abuses though. If PC OEMs are bad, imagine what a small mom-and-pop shop, subject to a lot less scrutiny and having much less respect for the law could do.
>You are saying you can reduce e waste by whole integer percent with a simple bit of legislation?
Well no, because not all e-waste are devices that you can conceivably reflash. For instance a monitor equals at least 10 phones in terms of e-waste volume, but I doubt legislation like this is going to make a dent in monitor e-waste. The proposal only realistically makes a difference for computing devices with short EOL periods and locked bootloaders, so basically phones and tablets.
Uber, Google Maps, VoLTE, VoWiFi, and eSIM work. You may need to install the sandboxed Google Play Services from the Apps app.
Android Auto is completely disabled as an opinionated security measure.
Google Pay and some banking apps (ones that require Google's Play Integrity API) will not run. GrapheneOS doesn't attempt to spoof these APIs because they are moving towards cryptographic verification [0]. Most apps don't require this check but if they do you are out of luck unless you can get the app developers to trust GrapheneOS's keys.
I think they work if you install Google Play Services (as a sandboxed app). What doesn't work for me is contactless payments with Google Pay however Google Wallet itself works. But I think that is actually intended and for security reasons.
I would like to be able to ensure that only boot loaders signed with my private key can be executed. Secure Boot serves that purpose well, can I do that with your approach?
Likewise, demand and use cases for network boot exist, otherwise it wouldn't be here. Same goes for every other feature most users would consider bloat.
Yes of course you can. Just run `signify -V` in userspace under the pre-kexec() kernel to check the signature on the post-kexec() kernel/initrd.
You can network boot too; just run `busybox udhcpc`.
I think you misread my comment. I never described signature-checking or network boot as bloat. I said it was stupid to have to implement these things twice (once in mainline Linux and then all over again in kooky UEFI-land with its bizzarre API, ABI, and wacky rules).
I still think it is stupid to do that, because it is. We have working, high-quality, battle-tested implementations of all this stuff. Use them.
