[dane-pgp]

> Laptops and modern computers also contains a TPM

The root of trust for which extends to who knows where, and you're not allowed to look at the source code or learn how it works because that would threaten Hollywood's profit margins.

We're basically building a system of DRM for access to human beings, and making the whole world dependent on these unaccountable entities.

[jeroenhd]

TPMs allow for arbitrary key storage by the operating system. They're not necessary for DRM. In fact, I've wiped my TPM several times to upgrade the firmware and I've had no trouble playing DRM content whatsoever.

Technologies like Intel's management engine and SGX or their AMD/Qualcom/Apple counterparts are definitely problematic for user freedom in the way they're implemented. However, the TPM system itself is quite neutral: usually, you can clear it from the UEFI, lock it with a password (though that might need to be done from the OS) leaving whatever hostile OS you may run unable to exert any control on the device whatsoever.

I'm personally a big fan of technologies like TPMs and secure boot as long as they're user configurable. I want to be able to install my own keys and force the system to only boot operating systems of my choice. Secure boot with just the MS keys is quite silly and ever since that one version of Grub could be exploited it's basically useless; secure boot with user or enterprise keys can be an incredible tool for defence in depth, for example when visiting countries where border agents may try to gain access to your data without your permission or knowledge (China, USA, etc.).

If I had my way, I'd use Coreboot together with Secure Boot, with encryption keys stored in a TPM, the transfer of which goes through an encrypted channel (a feature of TPM 2.0 that nobody uses) after unlocking it with a password. Sadly, most Linux OS developers have a grudge against these technologies because they're used by companies such as Microsoft and Apple to reduce user freedom on some of their devices.

[nybble41]

The user-hostile part of the TPM is the built-in key signed by the manufacturer which shows that it's an "approved" TPM which won't—for example—release any of the keys stored inside to the device's owner. This is what allows the TPM to be used as part of a DRM scheme.

If it weren't for that small detail then I would agree that TPMs can be useful for secure key storage and the like, working for the device's owner and not against them. The actually useful (to the owner) parts of the TPM do not require the manufacturer's signature.

[judge2020]

It enables it, but that's just because both you, the device user, and M$ and the rest of the media industry, need to ensure the TPM inside the processor is genuinely from the manufacturer. You wouldn't want to use a TPM if an attack vector is one where China (who is a large part of the supply chain) can poison a large amount of TPM shipments with their own key that can be used to export or otherwise access internally-stored keys.

[dane-pgp]

If your threat model is "China has backdoored your TPM" then making the TPM more opaque and unauditable doesn't improve the situation. How would you know if your TPM is lying and pretending to still have the original key when actually it has a replacement Chinese one?

[judge2020]

The actual attestation process protects against this:

program generates random bytes->ask tpm to sign it->on signature return, program asks TPM for its public key->program verifies public key matches that of the signature->verify the public key is cross-signed by the manufacturer's certificate authority. The only attack here would be if Intel or AMD's PKI is compromised, which would certainly be leveraged against enterprise customers before any consumer customers got hit.

[nybble41]

With regard to supply-chain attacks, since the TPMs are manufactured in China, they can just make a perfectly "genuine" TPM with a valid, signed key which has their backdoor. The attestation process protects DRM users (media companies) from device owners. It doesn't protect device owners from TPM manufacturers.

[blibble]

> Secure boot with just the MS keys is quite silly and ever since that one version of Grub could be exploited it's basically useless

this isn't true: there's a hash blacklist which is (supposed) to be regularly updated by your OS update mechanism

windows update does it anyway

[jeroenhd]

Is there a way to list this blacklist? I have several computers which haven't received updates in years and I strongly doubt that the internal blacklist has been updated.

[blibble]

mokutil --dbx

official list is here: https://uefi.org/revocationlistfile

(I have my own root configured for all of my machines so only stuff I've signed can boot)

[raxxorraxor]

Which is a pretty big security threat that is constantly ignored. It just isn't acknowledged when people talk positively about TPM even if remote attestation is completely build-in by now. Security for whom becomes the question here.