[michaelt]

The goalposts haven't moved in my mind, but I suppose I didn't make them clear in my first post.

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.

[Foxboron]

> 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.

[michaelt]

> TPMs give you fine and adequate protections in many scenarios [...] my `ssh-tpm-agent` project

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.

[Foxboron]

> 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.

It protects against extraction, not usage on the machine itself. Of course they can use the secret on the compromised machine.

> 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.

Assuming they can edit the file.

> That's why Yubikeys and U2F keys and suchlike have a physical button.

The TPM spec has a policy setup to account for some fingerprint reader that can be used to authenticate. I haven't been able to figure out how/what/whys of the implementation here but this is very much a thing.

[michaelt]

> It protects against extraction, not usage on the machine itself. Of course they can use the secret on the compromised machine.

Yes, this is why I was careful to say that the benefits are obscure, rather than saying they're entirely nonexistent.

I'll admit that's a benefit, but it seems very small benefit considering the far-reaching changes it's needed like kernel lockdown mode, the microsoft-signed shim, distro-signed initrd, the difficulties it creates with DKMS, and so on.

Whereas people who need to bind their SSH key to hardware can get a higher degree of security with a far smaller attack surface by simply spending an hour's wages on a Yubikey.

[Foxboron]

> I'll admit that's a benefit, but it seems very small benefit considering the far-reaching changes it's needed like kernel lockdown mode, the microsoft-signed shim, distro-signed initrd, the difficulties it creates with DKMS, and so on

None of this is needed to take advantage of TPMs.

> Whereas people who need to bind their SSH key to hardware can get a higher degree of security with a far smaller attack surface by simply spending an hour's wages on a Yubikey.

Yubikeys are expensive devices, and TPMs are ubiquitous. Better tooling solves this problem.

[michaelt]

> None of this is needed to take advantage of TPMs.

You're not binding the secret to PCR values? I thought TPM fans loved those things?

I don't blame you - they look like a design-by-committee house of cards to me, with far too many parties involved and far too much attack surface. Just like the rest of the TPM spec.

[AnthonyMouse]

> 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.

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.

[vel0city]

What happens when I try and login offline or unable to reach a directory server?

FWIW, Bitlocker already can store recovery keys in AD. It has been a feature for a long time.

[AnthonyMouse]

If the machine is already on but asleep, the keys are in memory, they only have to be downloaded from the server on first login. If the machine has been off and you have no network connection then you need the long password to unlock it instead of the short one, but for most users that is already irrelevant because everything else requires a network connection too.

[vel0city]

Ah ok, so I'll need to memorize the super long password whenever I'm out and about and want to just check something real quick. I guess I'll just put that on the sticky note on the bottom of the computer.

[AnthonyMouse]

You want to check something real quick on what... the internet? Then you have internet access. You also have access to the local data on the machine as long as it was asleep rather than off, which will be the case the vast majority of the time.

Keeping the key stored on the machine, TPM or no, is also less secure than keeping it somewhere else. If someone steals your laptop, you deny all access to the key on the server and they can't get it even if they could guess the pin (or the user wrote that on the bottom of the computer), and there is no way to use an offline method to extract the key from the TPM because it isn't there.

[vel0city]

> You want to check something real quick on what

Computers have these neat things called "local filesystems". They're a real hoot. Maybe you can get one on your computer.