Unfortunately this sounds like a typical pro-Linux rant with the usual scare words such as "Microsoft", "UEFI", "secure boot", etc. To be clear, I am attacking the piece itself, not the author.<p>The reason there is no explicit threat model defined in the TPM specs is because it defines a general-purpose hardware security module. It is up to integrator to define the threat model (TPM's security properties also depend on the rest of the system) and the application.<p>Even if a TPM is not perfect and depends on other pieces of the puzzle to also be secure, it at least opens the possibility of making it secure in the future once those vulnerabilities are discovered & fixed. Furthermore, even in this vulnerable state, it still increases the effort required for a successful attack.<p>Support for TPM-backed full disk encryption means you can now have FDE on by default for everyone with no usability impact at all. Even if it's not secure and a dedicated attack will still break it, it means a casual attacker can't just pull a drive or reboot the machine and run chntpw or steal sensitive data from discarded drives that haven't been properly wiped.<p>I like TPMs. I like the fact that a rogue datacenter employee or intruder can't just pull one of my servers' drives out and get sensitive data. I like not having to worry about having sensitive keys on the filesystem somewhere because every secret is in memory and is ultimately derived from the TPM doing remote attestation at boot and handing ephemeral keys. I like not having to worry about unattended reboots or entering LUKS passphrases remotely.
> You can also use the TPM + PIN as a sort of Yubikey<p>That's not zero. In my mind that's the main thing a TPM is really useful for. It's a secure enclave for a private key used for U2F/WebAuthn style attestation. I agree that the threat model not being explicitly discussed is a huge miss. But to that point, a TPM is still useful because it prevents someone who has hacked into my computer from commanding the TPM's authentication factor.<p>The other useful application is to prevent block device data extraction without knowing the passkey. And the author's argument there hinges on the notion that Microsoft won't patch OS security vulnerabilities that enable key extraction from memory. Which, OK, third-party drivers suck, but Microsoft's effort to patch is also not zero, and the most common (OS+browser/sandbox) threat model requires a chain of vulnerabilities that are hard to come by.
I don't agree with this. Yes, any TPM is necessarily possible to bypass, but it's not easy. I know I could bypass normal password-based FDE with physical access to a machine without any special hardware or software, but not TPM-based. I assume, by the Pareto principle, that there are lots of people with my ability but exponentially fewer who <i>could</i> bypass a TPM. So it's definitely more secure than password-based FDE, and it's good enough for me.
Not a great take. The TPM provides the primitive of "non-extractable keys"; it's not supposed to magic up secure boot.<p>Even then, the argument that a TPM is worthless because it can't guarantee that software is free of vulnerabilities just belies an un-seriousness of the post. Like okay, that argument applies to every threat model ever.<p>A boot chain can be secure with or without a TPM. The TPM just says "I'll record what your boot chain told me and spit it back out with a signature that is verifiable by public key cryptography, so that you can tell it's what your boot chain told me. How much you trust your boot chain is up to you."
> the signature of the BIOS is checked against a public key whose hash is stored in fuses<p>> Each of dozens (up to hundreds) of UEFI drivers written by various OEMs with varying levels of competence and care are loaded<p>Doesn't the BIOS signature encompass those drivers? Put another way, isn't the BIOS vendor attesting those drivers are non-malicious with their signature?<p>I think the TPM will turn out to be a net negative for consumers since it's going to get used to get used for attestations users can't control (ie: against the will of the user),
but there are some benefits. Having a BitLocker key unlocked via a PIN where the TPM can protect against brute force attacks is useful for me. That alone covers most of my threat model which is having my data extracted from a lost or stolen PC.
Ask Google exactly how they enforce their zero trust, VPN-less remote work environment. Hint: it has to do with the TPM. DRTM + Device Certificates + TLS Token Binding is a huge deal for proving that the endpoint is trusted, and that the principal actually logging in is using an approved device. DRTM prevents boot time tampering by assuring that the measured boot state is consistent with what the network expects.
On the one usage scenario that benefits a PC user, the TPM makes for a really bad yubikey. You can't carry it between computers, you can't back it up, and you are certain to lose it at some point when the computer breaks of gets outdated.<p>That means it either requires a second protocol for authentication, or that you will lose your accounts with all kinds of services all the time.
So it boils down to "we shouldn't attempt to build new security stuff because what it's built on could have vulnerabilities"?<p>Time to go back to kernel mode everything I guess. Just run everything as root, get rid of sudo.
Should the title at least be "the trusted computing/measurement functionality of TPMs provide..." rather than "TPM provides..."?<p>TPMs can do other useful things besides performing attestation measurements for trusted computing, including acting as a secure element to safeguard and rate-limit keys used for SSH, disk encryption and much more.
> The Trusted Platform Module(TPM) requirement enables Windows 11 to be a true Passwordless operating system<p>Good luck trying to remote (RDP) into a Windows box with a passwordless account or to access a fileshare.<p>While passwordless Microsoft accounts are very convenient it is only according to MS Marketing department that windows can be a true passwordless system. In reality it is not. There any several components in Windows that does not work with a passwordless account. The RDP and network issues has been know for many years and is a PITA for home networking.
Been wondering if I should enable these things in the firmware for several years, so the discussion is welcomed.<p>I do have a travel laptop and recently installed LUKS to it. I like having my long password, but being able to tie unlocking to the hardware sounds like a good idea too. Is there a way to have both? A long password and require the local TPM?
Zero is a stretch. I think they have largely failed to serve their purpose in the consumer device realm, beyond decent integration with BitLocker.<p>Despite the shortcomings, I think they are very useful devices from the perspective of running data centers. I consider it useless against evil maid attacks though.
All the hardware based attacks require opening up the laptop and doing something with the motherboard.<p>I'd have to check if bottom cover tampering on my Lenovo actually requires me to put in the BitLocker keys again.
The absolute dumbest shit here gets up voted regarding Linux.<p>No dang, I don't care about the spirit of the site when absolute ludicrous mindrot garbage is up voted here constantly. You'll note on the Wayland thread that, despite being the 30th Wayland thread, the only substantive reply agreed with me. It's a joke.<p>Don't worry, I'm changing my password to a random guid, you'll be free of me in 45 seconds.
At this point I don't understand why hardware vendors can't just do it like Apple. Put a small ARM SoC with some firmware in ROM onto the mainboard that starts before the main CPU and initializes it, ensuring that the system is in a known state before any components boot.