It seems like these security discussions always devolve into rather funny moving of goalposts without actually considering how much work each exploit requires.
Basically the TPM provides a set of features that are really useful for corporate Windows deployments. No more forgotten passwords, because the self-unlocking disk encryption sends the user straight to the Windows login screen, and helpdesk can reset forgotten Windows passwords remotely.
And for casual home Windows users, it lets them log in with a 4-digit PIN or with biometrics, so it's got usability benefits for them too. If every OS now needs Microsoft's signature of approval, or a really fiddly setup process? Well they were running Windows anyway, so no problem.
These usability/support benefits rely on self-unlocking disk encryption, which is vulnerable to sniffing if someone gets a stolen laptop on ebay.
For the kind of technically sophisticated, security enthusiast users who comment on blog posts about TPMs? We're more than happy to key in a strong unique password at every boot, and if we forget the password and lose access to everything on that disk that's just the system working as it's supposed to.
For us, the benefits of TPMs and measured boot for personal use are a lot more obscure. You'll sometimes hear people claim it protects against 'evil maid attacks' where an attacker repeatedly gets physical access to your laptop. The truth is it provides no such protection.
TPMs give you fine and adequate protections in many scenarios, even physical ones.
They also provide you with better protection for private key material.
I'll even give you an example:
https://github.com/Foxboron.keys
The last key is a TPM key from my `ssh-tpm-agent` project: https://github.com/Foxboron/ssh-tpm-agent
Here is the private key: https://paste.xinu.at/9fc2YJQuUCbg1Sa/
I don't remember if the key has a PIN (it was for a presentation/demonstration), but if it has it's like 4 digits long.
I agree that's adequate, in the sense that keeping the an SSH key as a password-protected file on disk is adequate, and having it be a password-protected secret in the TPM is no less secure than that.
But the whole point of binding a key to hardware is to be secure even if a remote attacker has gotten root on your machine. An attacker with root can simply replace the software that reads your PIN with a modified version that also saves it somewhere. Then they can use the key whenever your computer is online, even if they can't copy the key off. And although that's a bit limiting, once they've SSHed to a host as me once they can add their own key to authorized_keys in many cases.
That's why Yubikeys and U2F keys and suchlike have a physical button.
TPMs would be a lot more useful if the spec had mandated a physical button for user presence.
Unclear why this requires a TPM. Boot the system from a static unencrypted partition containing no sensitive data, display the login screen, when the user authenticates the system uses their credentials to get the FDE decryption key from the directory server. Bonus: Now the FDE keys are stored in the directory server and if the system board fails in the laptop you can remove the drive and recover the data.
An attacker with physical access could modify the unencrypted partition to compromise the user's password the next time the user logs in, but they could do the same thing with a hardware keylogger.
> And for casual home Windows users, it lets them log in with a 4-digit PIN or with biometrics, so it's got usability benefits for them too.
This could be implemented the same way using Microsoft's servers, given that they seem to insist you create a Microsoft account these days anyway.
It's not clear that unsophisticated users actually benefit from default-FDE though. They're more likely to lose their data to it than have it protect them from theft, and losing your family photos is generally more of a harm than some third party getting access to your family photos.
FWIW, Bitlocker already can store recovery keys in AD. It has been a feature for a long time.
