[osy]

What’s the threat model of TPM? They claim it’s for “physical attacks” but they can only enforce it when there is no software vulnerability or unauthorized privileged access anywhere so it’s a very small area of the Venn diagram where you have an attacker whose capability is “physical access” but also “does not possess any exploit or one-touch-access”. This narrows down the list to:

• Malicious coworkers, family members, and house keepers against a computer who is NEVER left unattended (i.e. screen locked when you leave 100% of the time)

• Local government agents (i.e. the local police) who can confiscate your powered on device but cannot afford to buy 3rd party cracking services that utilize exploits or more advanced extraction techniques (external RAM dumping)

• A device that is completely powered off and confiscated by a powerful nation state agent but not later on returned to the original owner and they forgot to wipe the device in case of implants.

In any case the design of TPM is completely flawed and suffers from “astronaut architects”. If you grep the three volume 1000+ pages of the TPM 2.0 architecture documents, you’ll not find a single mention of “threat model”.

Specifically TPM is a multi-million dollar industry signed on by many tech companies (including Microsoft who uses it as an excuse to get you to buy a new PC because TPM == more secure right, but also because older computers don’t support it) because places like governments and banks require it because they also don’t understand threat models.

TPM protection is fundamentally flawed because:

• It cannot protect against a compromise in the boot chain (e.g. a UEFI driver is exploited, and it lies to TPM about the subsequent stage of code that is loaded while running a malware implant)

• It cannot protect against RCE (remote code execution). This means if Windows ever has a vulnerability that can be exploited remotely, they can keylog -> steal your PIN -> replay it later to dump the key. Or just dump the key in memory if they have a PE (privilege escalation) as well.

• It cannot protect against a user volunteerly installing malware (Bonzi buddy?)

• It cannot protect against an attacker who installs something on your unattended computer (USB Rubber Ducky, Flipper Zero, etc)

Basically the most common ways people get compromised sees no protection from TPM while esoteric attack situations that no attacker will realistic attempt are protected.

TPM can never protect against these cases because it is logically (fTPM) and/or physically (dTPM) separate from the CPU. That means it cannot perform any policy enforcement against a CPU whose execution is under control of the attacker.

[alex7734]

TPM is not designed to prevent intrusion from hackers, it's designed to turn your general purpose computer into an appliance by preventing you, the owner, from modifying the OS in your computer as you see fit (and interact with third party services at the same time, thanks to remote attestation).

It means that instead of _just patching_ the software in your computer to customize it now you have to resort to using 0days to do it like a criminal which makes it considerably harder.

It does help against hackers, of course, and the same restrictions do secure you against some attacks (evil maid attacks) but that's not the intent.

The threat model TPM protects against is:

- You log in into Netflix (or whatever)

- Netflix sends your PC the movie so you can watch it.

- Your PC now has the movie in memory.

- You extract the movie from your PC's memory and you can now watch it forever without Netflix's permission.

What the "trusted" in Trusted Platform Module means is that with TPM they can trust your PC to not let you do that.

[jrockway]

It's a double-edged sword, right? On the one hand, Windows 12 can be completely iOS-like and you can't do anything about it. On the other hand, someone with physical access to your machine can't replace your OS that sends them your disk encryption password as soon as you get a DHCP lease.

Chrome OS really got this one right. You can disable all the security, but there is hardware that tells you that happened. It can also tell your employer so you don't download their IP to a laptop running malware. That's all it's ever been used for; no matter how much people try to make DRM a thing, it's never once worked. Every Netflix-exclusive show is easily downloadable on Usenet.

[KennyBlanken]

The sword analogy is getting a bit awkward here, but the people making the sword only care about how well it protects media and software - because they want their marketplaces (app/music/movie/game stores) to be as attractive as possible to media conglomerates.

They don't give a damn how well it protects you.

[jrockway]

I'm uncertain. Microsoft isn't making any real money off of media. They sell licenses to use Outlook and rent you some computers, and there's their income.

[sudosysgen]

Of course they make money that way, because Netflix and co want DRM and they don't want you to stop watching Netflix on Windows and have to do it on your phone. So they'll go and make TPMs happen.

Also, Microsoft makes a lot of money from videogames, and TPMs help enforce microtransactions in single player games if nothing else.

[jrockway]

That's just a game of chicken neither player wants to admit. "Netflix drops Windows 11, Microsoft launches new subscription service," ain't gonna be good for Netflix.

[cyberax]

This is BS.

The TPM on x86-based computers, as it exists right now, is _not_ suitable at all for any of the above.

[lathiat]

It means malware can’t exfiltrate the SSH key from your machine and keep using it. But yes they can potentially use it while still on your machine depending on if presence confirmation or re-inputting a credential is required. But that still closes a big gap.

On a Mac secretive can also pop a notification making it more likely to passively observe such usage (not fool proof though) and the key can’t (easily, maybe with some complex exploit) be used from an app not signed by the original developer. It can also require re input of your password. That specific security probably isn’t possible on Linux though.

[candiddevmike]

> It means malware can’t exfiltrate the SSH key from your machine and keep using it

Are you sure about that? Presumably the secret parts of the SSH key are being read into memory at some point, or a RCE could dump the key the same way ssh-tpm-agent does.

Don't rely on a TPM to store secrets. Use a secrets store that can be audited for use and have it generate dynamic, short lived credentials. For SSH, use SSH CAs.

[Foxboron]

>Are you sure about that? Presumably the secret parts of the SSH key are being read into memory at some point, or a RCE could dump the key the same way ssh-tpm-agent does.

This is not how ssh-tpm-agent works. It does the key signing inside the TPM so you do not have access to the key on the machine itself.

The private key never hits memory or the machine itself.

[awesomeMilou]

> that can be exploited remotely, they can keylog -> steal your PIN -> replay it later to dump the key. Or just dump the key in memory if they have a PE (privilege escalation) as well.

That can't happen if a TPM is used correctly. If the TPM is coupled with an OPAL enabled SSD for example, the actualy key used for data encryption is never loaded into main memory. Sure, disk content can be read by a malicious OS, but you do not gain access to any encryption keys. Additionally, you prevent MITM attacks by using challenge response authentication which some TPM's support, so again, your key is never revealed.

> It cannot protect against an attacker who installs something on your unattended computer

This is a strawhat since you won't ever be able to protect from user space malware. Apart from that, TPM's can enforce mandatory access control if supported (I know the T2 on Macs does exactly that). So no, you cannot easily install a root kit and expect it to work.

> It cannot protect against a compromise in the boot chain (e.g. a UEFI driver is exploited, and it lies to TPM about the subsequent stage of code that is loaded while running a malware implant)

At this point we are in the realm of an attacker stealing your device, desoldering a chip and rewriting the firmware on that chip. Were talking about _considerable_ ressources spent, just to trick you into thinking your device hasn't been compromised.

I know that on non-Apple devices vendors will likely use some insecure off the shelf solution, but if done correctly these things are as close to unbreakable as possible.

> Basically the most common ways people get compromised

The TPM spec was written by NIST and it's purpose is not to protect the common user, but to offer advanced security features for business clients and governments. And there, a device that get's stolen is a common occurence.

The reason you see it integrated in consumer devices for cost reduction. It getting abused for DRM purposes is entirely the media industries fault.

[sudosysgen]

You can edit UEFI drivers from the operating system's bootloader, and you can even flash the UEFI itself from the OS in most computers. While secure boot. Failing that, you can shim a preloader between the bootloader and the UEFI and load arbitrary drivers despite secure boot, like is done here : https://github.com/ValdikSS/Super-UEFIinSecureBoot-Disk

Any sufficiently motivated attacker can make a UEFI rootkit happen, and it's in the wild right now. TPM really do offer no protection to users, either against userspace malware, or rootkits. It's purely about DRM.

[Foxboron]

No, this isn't true nor correct.

Secure Boot and TPM do offer tangible security benefits and is security features you can take ownership of.

Secure Boot allows your own key hierarchy, and TPM allows you to take ownership.

The linked boot disk isn't really proof that Secure Boot is useless. If you don't set a MOKManager password (as you should), and you change the security state of the machine while present at the keyboard. Yes you can boot things.

This is intended to make sure people can actually decide to trust things. And having insecure defaults makes this less useful. Not very surprising.

EDIT: The bootdisk won't work with a recent shim nor a recent grub. The old shim it was using should be revoked if you have any remotely updated machine as well.

TPMs could also prevent attacks like this on your machine.

Incidentally I've invested quite a bit of time in making user-friendly Secure Boot tooling as well. https://github.com/Foxboron/sbctl

[patrakov]

In the TPM threat model, the attacker is you, and the defender is your employer who wants to make sure that you don't exfiltrate keys from your work laptop to any other (i.e. unauthorized) device.

[jrockway]

I mean, your complaints are that it doesn't make software more secure. That's true but that's an orthogonal effort. Imagine there was a world where software was secure (they rewrote Windows in Rust or whatever); now what tools do you need to ensure that someone didn't replace your secure software with their own compromised version? (For example, how do you know that LUKS is asking for your full-disk decryption key, and not some piece of malware that some random package maintainer added to /etc/systemd?) That's the gap that the TPM is designed to fill.

Meanwhile, sure, it's not going to prevent you from clicking a link in your email to fakebank.com and typing in your SSN.

I'm surprised that people are surprised that a $0.20 chip doesn't eliminate software bugs.

[KirillPanov]

> If you grep the three volume 1000+ pages of the TPM 2.0 architecture documents, you’ll not find a single mention of “threat model”.

Because they're embarrassed to state it.

The TPM threat model is: "the machine's owner is the threat".