I feel like there's a large subset of people who don't understand what TPM does, so just assume the worst and hand wave about how it [somehow] causes [random bad thing].
Stallman[1] and others[2] wrote about TPMs nearly 15 years ago, and the former revisited the topic in 2015.
Trusted Platform Modules can be used enforce app DRM, ensuring that only "approved" apps are able to run on a system.
That's already the reality for iPhones and iPads. We see desktops converging on this reality with systems like Apple's M1 which won't run unsigned binaries at all, and makes it difficult to nearly impossible to run apps that weren't first approved by Apple through their notarization process.
Thanks for the link, I wasn't aware of Purism's work in this space.
Is an open and flashable TPM something rights holders would be comfortable with? Or would they treat it like SafetyNet treats an Android phone with an unlocked bootloader?
The main point (and only differential) of a TPM is protecting secrets against the person with physical possession of the device.
About every time something like this is placed on a consumers product, it is to exploit the consumer some way, so, no it's just bad.
There is the very rare exception of it being a product intended for the owner to lend it to other people, and the very common exception of it being disabled by default, but being cheaper to include on every product than just the business ones. But well, Windows 11 Home edition computers are neither of those.
A TPM is a chip on some motherboards that serves two purposes:
1. Using something not too dissimilar from blockchain/git repo hashes to attest to the the execution stack (BIOS, bootloader, kernel, userspace).
2. Providing cryptographic primitives that are only unlocked when the stack exactly matches a particular value.
It's a handy tool for avoiding spyware, as any change in the attestation chain gets immediately flagged. It is also, in principle, useful for tying DRM keys to a particular execution stack that's known to be trusted... although it's very worth noting that the TPM's threat model does not include an attacker having physical access to the hardware.
Right, for configurations where the tpm automatically releases keys, they can be sniffed. It can be configured to only release it's secret once a correct password is given. It also rate limits I believe.
It's been a while since I looked at the technology, but the basic premise is very simple. The TPM basically keeps around a stack of hashes. The BIOS pushes a hash of the bootloader onto the stack. The bootloader pushes a hash of the kernel onto the stack. Then there's a handful of ring 0 cpu instructions for pushing and popping all but the bottom-most entries of the stack that allow the kernel to do whatever it wants, including pushing hashes of application code, hashes of passwords (as in your example), or opening up a similar ability to push/pop upper levels of the stack to the application.
The only check the TPM does when deciding whether to allow the key in one of its registers to be used is whether the stack is in a particular configuration. The TPM doesn't (and in fact can't) directly require passwords (since it has no direct line of communication to the user). However, the BIOS, bootloader, kernel, etc... can all be configured to mix user-provided information like a password into the hash they push into the TPM.
TPM keys are protected by policies. A policy can be based on the system state (hashes), a password, or both. There are also complex policies using the Extended Authorization feature. If you don't care about platform state or configuration, then you can just set a key policy with just a password. The TPM will lock you out if you make too many incorrect guesses.
With a physical bus reset attack you can also set PCR values without any authentication, which essentially breaks attestation. Also only some TPMs have anti tamper features and security certification (best ignore the ones that don't).
TPM used for secure boot, (hypothetically) used to block installing non-windows OS, means the owner is forced to using an OS that has telemetry.
That is the argument I suppose OP was making. The secure boot locking is hypothetical, but it is often feared. I get why, because it seems like something Microsoft would love to do.
I figured the TPM was part of secure-boot validation. But given some extra thought, it is clear that verifying a signature does not require any secrets.
A TPM is just a bit of memory that is "hacker proof" so you can store a private key with a guarantee that it can't leak out. You can then sign, encrypt, or decrypt using the key.
They were controversial because it was originally thought they would be used to lock parts of your computer away from you, being used to do DRM and the like. At the end of the day the chips were hard to use, slow, and flaky enough that it didn't really pan out. A lot of the braindamage came from a secondary feature where you could theoretically create "secure enclaves" where the entire execution chain down to the bare metal was signed to prevent viruses and rootkits from executing. In theory this is neat, but in practice it's basically impossible on PC hardware and caused a lot of problems. This functionality is the reason BitLocker had the reputation for randomly locking you out of your machine, even though it doesn't use the feature directly. The configuration registers were maybe a mistake.
I know it's super easy for anyone to Google, but I feel like at least one reader will find this useful since I didn't see it mentioned anywhere in the discussion thread: TPM stands for Trusted Platform Module.
("TPM is an international standard for a secure cryptoprocessor, a dedicated microcontroller designed to secure hardware through integrated cryptographic keys." - https://en.wikipedia.org/wiki/Trusted_Platform_Module)
A TPM is much more than "just a bit of memory". It is a cryptographic coprocessor, with its own microcode and its own security domain.
And I don't think a fully-secured future for PC's is as impossible as you think. The primary reason this is impossible right now is because TPM's aren't ubiquitous (none of my machines came with one installed). That problem will be solved by Windows 11.
Secured for the benefit of Microsoft or DRM providers, not necessarily for the benefit of the end user.
Unless they're willing to allow the end user to override the wishes of the vendor (and without any diminished functionality), TPM is just another way to turn computers into appliances.
The fundamental problem with the secure enclave on PC is that to make it work you have to basically lock out all of the untrusted hardware on the box, which is pretty much all of it. So while you are doing your secure computation nobody is servicing the PCIe bus. The graphics card drivers aren't getting any CPU cycles. Ring buffers on your network cards aren't emptied. From the perspective of everything else on the machine the whole thing just crashed.
If your computation is quick you might be able to get away with this sometimes, but the potential for problems is almost unlimited. The fact that the TPM itself is pretty slow throws another monkeywrench into the plan.
In order for it to work the whole system needs to be designed from the bottom up to support it, which means you need to touch every layer of the PC stack. It's a lot of work. It is a lot easier on something like a cellphone where you can control the hardware from top to bottom and don't have to consider the case where someone installs additional hardware to suit their needs.
It's what Apple calls a "secure element", essentially a mini-HSM or multi-feature smartcard. "Put keys on it and it lets you use it with a PIN and rate limit" seems to be the main use case (they can implement FIDO2 with that too for instance).
These things are very useful for authentication and have been on business laptops for this very reason forever.
Trusted Platform Modules can be used enforce app DRM, ensuring that only "approved" apps are able to run on a system.
That's already the reality for iPhones and iPads. We see desktops converging on this reality with systems like Apple's M1 which won't run unsigned binaries at all, and makes it difficult to nearly impossible to run apps that weren't first approved by Apple through their notarization process.
[1] https://www.gnu.org/philosophy/can-you-trust.en.html
[2] https://www.cl.cam.ac.uk/~rja14/tcpa-faq.html