[ak217]

> You can also use the TPM + PIN as a sort of Yubikey

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.

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.

[osy]

This is not the way TPMs are used by most of the industry. For example, Microsoft and now Canonical are advertising it as a way to do FDE which Microsoft has known to be broken since 2006. They are requiring it for Windows 11 because of "security" and have provided no software feature on Windows for this kind of use case. It is only done by the OSS community.

> The other useful application is to prevent block device data extraction without knowing the passkey.

Nope, read the appendix. Since 2006, BitLocker without PIN is vulnerable to physical extraction with $80 worth of equipment. And to enable enhanced PIN for BitLocker you have to jump to a lot of hoops that most people don't even know about.

[lxgr]

> This is not the way TPMs are used by most of the industry. [...] It is only done by the OSS community.

So some industry stakeholders are doing bad things with an inherently neutral technology. Does that mean we need to get rid of the entire thing, thereby also killing the OSS use cases?

Yes, trusted computing can be used in user-hostile ways, but the solution here seems to be to not use OSes and applications using it in that way, rather than throwing out the technology as a whole.

[AnthonyMouse]

The trouble is we keep conflating two different things.

Something that works like a hardware security module, where it stores your keys and tries to restrict who can access them, has some potential uses. The keys are only in your own device, so someone can't break an entirely different device or a centralized single point of failure to get access. And this can't be used against the user because both the device and the key itself are still fully in their control -- they could put a key in the HSM and still have a copy of it somewhere else to use however they like.

Whereas anything that comes with a vendor's keys installed in it from the factory is both malicious and snake oil. Malicious because it causes the user's device to defect against them and some users aren't sophisticated enough to understand this or bypass it even if malicious attackers can, and snake oil because you can't rely on something for actual security if a break of any device by anyone anywhere could forge attestations, since that is extremely likely to happen and has a long history of doing so.

[lxgr]

> Anything that comes with a vendor's keys installed in it from the factory is both malicious and snake oil.

I don't agree that all trusted computing use cases are inherently user-hostile. DRM is a well-known example, but e.g. Signal used to do interesting things server-side using (now no-longer trusted, ironically) Intel SGX/TXT, like secure contact matching or short PIN/password security stretching for account recovery.

Android Protected Confirmation [1] is also trusted computing at its core, but can be used to increase security for users (although I could also see that usage encourage a device vendor monoculture, since every app vendor needs to select a set of trusted device manufacturers).

> snake oil because you can't rely on something for actual security if a break of any device by anyone anywhere could forge attestations

Attestation keys are usually per-device, so if indeed only one device gets compromised at great attacker expense, it's usually possible for a scheme to recover. If all devices just systematically leak their keys as has certainly happened in the past, that won't help, of course.

[1] https://android-developers.googleblog.com/2018/10/android-pr...

[AnthonyMouse]

> e.g. Signal used to do interesting things server-side using (now no-longer trusted, ironically) Intel SGX/TXT

Because this is the "snake oil" prong of its failure -- and why it's no longer trusted.

> Android Protected Confirmation

This could be implemented without any vendor keys. You associate the user's own key with the user's account.

> Attestation keys are usually per-device, so if indeed only one device gets compromised at great attacker expense, it's usually possible for a scheme to recover.

That's assuming it matters at that point. The attacker doesn't care if you revoke the keys after they steal your money.

And once they extract a key from one device, they have a known working procedure to get more. For non-software extraction most of the expense is the equipment which they'd still have from the first one.

> If all devices just systematically leak their keys as has certainly happened in the past, that won't help, of course.

And is likely to happen in the future, so any design that makes the assumption that it will not happen is clearly flawed.

[lxgr]

> This could be implemented without any vendor keys. You associate the user's own key with the user's account.

But how would you bootstrap this? How do you make sure the initial key was actually created in the secure exceution environment and not created by MITM malware running on the main application processor?

If this was that easy, FIDO authenticators wouldn't need attestation either.

> That's assuming it matters at that point. The attacker doesn't care if you revoke the keys after they steal your money.

If attacking a single device costs a few millions, it definitely does matter, since you'd need to expend that effort every single time (and you'd be racing against time, since the legitimate owner of the device can always report it as stolen and have it revoked for transaction confirmation, transfer their funds to another wallet etc.)

> And is likely to happen in the future, so any design that makes the assumption that it will not happen is clearly flawed.

How does some implementations falling apart imply all possible implementations being insecure? Smartcards are an application of trusted computing too, and there have been no successful breaches there to my knowledge. The fact that the manufacturers specialize in security, not in general-purpose computing like Intel and only occasionally dabble in security, probably helps.

[michaelt]

> In my mind that's the main thing a TPM is really useful for.

Unfortunately, it's not much good for that either.

A yubikey has a button to confirm the user's presence - so even if a remote attacker has completely compromised the machine, because they can't press the button, they can't get anything out of the key.

The TPM has no button, so it has to rely on the OS to keep your pin safe from keyloggers. If your OS is that trustworthy, you might as well just store your secrets in the OS keyring.

The TPM is also about 50x more complicated than a yubikey, to support things like multi-user systems. This means there's a much bigger attack surface.

[lxgr]

The button of a Yubikey doesn't add as much security as you might think: Since you don't know what you are actually confirming (due to the lack of a display), what prevents an attacker with control over your OS to just wait until you want to confirm something legitimate and then front-run that request?