The only secure implementation is called D-RTM which requires a level of chip, OEM, and OS support that's not done in practice.
The only secure implementation is called D-RTM which requires a level of chip, OEM, and OS support that's not done in practice.
This! If security is your prime directive in your line of work(government, highly sensitive data, etc), then as long as your device has been outside your physical possession and in the hands of an untrusted third party, then it's automatically considered compromised and gets wiped or discarded by your IT department.
Because no amount of marketing security fluff from Microsoft, Apple, Google can stand against targeted attacks of state actors or knowledgeable motivated well funded actors with freshly acquired zero days.
The security they provide is only good enough against the average thief off the street, which I guess covers 98% of Average Joe's threats.
Even CC security certifications never judge a device whether it's hackable or not, but only on how long it takes for it to be hacked by an accredited lab, because nothing with outside physical access is ever unbackable. With enough time and six figure equipment off the publicly available commercial market, everything reveals its secrets eventually. And that's without zero days off the black market.
Even there, only Apple has effective protection against street-thieves. Nearly all other models of phones/laptops can have their anti-theft features reset by a guy in a dark alley with a flash programmer...
So far, most thieves aren't interested in your info, they just want to reset the hardware and give it a new serial number.
Consider how different a wireless hacking attack is from one where somebody has to sneak up and stab your device with an RJ-45 plug.
If you want secure Bitlocker, use a password.
It's _also_ insecure by design because in every deployed implementation (including with PIN), it is S-RTM meaning that _any_ UEFI driver vuln will compromise your TPM key. Yes, any UEFI vulnerability in its countless vendor drivers, USB stack, network stack, etc.
To be precise, both Windows (according to the article) and Linux+systemd (since systemd v251) support letting the user specify a TPM PIN and then use parameter encryption. But yes, both make it optional.
TPM could be used for DRM in the sense that DRM software could refuse to run on system that isn't approved, but it's not going to stop you from enjoying a DRM free system - in fact it can help by explicitly supporting clearing of TPM state by owner.