The main problem is that you don't have a strong way of establishing that you're talking to the real TPM. It does raise the bar from passive interception to hardware MITM, but it doesn't absolutely solve the problem

It would if both the TPM and the chip talking to it use keys signed by the manufacturer. Then they could both verify the public signatures.

A public key for a fixedTPM+fixedParent primary on the TPM could be stored "securely" (i.e., read-only) on the host side, and then you can do key exchange with the TPM using RSA key transport or ECDH.

You can also use a shared secret, but storing a secret on the host side is even harder than storing a write-once (at factory), read-only PK.

On intel systems at least the "firmware" tpm is really implemented in the PCH. It'd probably still be possible to sniff the i/o lines between the cpu & pch but still way more complex than between the tpm and cpu.

Where does the key come from if the communication is encrypted?

The process for establishing an encrypted session goes like this:

0: Know the public key of a fixedTPM+fixedParent primary key (e.g., the "endorsement key") on the TPM ahead of time[0].

1: call TPM2_CreatePrimary() in the clear to "create" that key (this is deterministic given a public template and factory seed secret to the TPM) -- you need the "handle" for this key

2: call TPM2_StartAuthSession() with that handle as the bindKey, and various other parameters

3: use that session in all subsequent commands.

Note: only one parameter of every command can be encrypted: the first parameter (command or response parameter) of type TPM2B_PRIVATE. The rest can be authenticated but are otherwise exchanged in plaintext. This is mostly just fine.

[0] Well, you could validate the EK's certificate, and then you only need to know the trust anchors for the TPM's vendor. It's roughly the same thing, but with more steps, and it lets you replace the TPM w/o having to re-learn a public key for it (which might be important).

So who knows that key? The processor? Or the operating system?

What’s preventing an attacker from changing that key? Or is this just to change the attack from passive to active?

The public key has to be known by the BMC, BIOS, OS.

You can read the public key from the TPM. If you're using the endorsement key, it comes with a certificate issued by the vendor.

This is complete speculation, but it could be like TLS.

That would make it much harder as you'd have to MITM the communication, not just sniff it. Maybe impossible to decrypt if both the TPM and the chip it's communicating with use keys signed by the manufacturer.

I might ask "why speculate when you can go find out?", but in this case finding out is non-trivial. See above for an explanation though.

Your comment wasn't there when I speculated.

Sounds pretty similar to TLS to me, in my non-expert opinion.

I think the difference with TLS is that, in the attacks the TPM should protect you from, the attacker controls the client and the network.

I don’t really see how it is possible to defend against that. But I don’t quite understand how the TPM checks what the CPU is doing either.

Disclaimer: I'm not an expert. At all.

I don't think it checks what the CPU is doing at all. It just makes software able to check if the platform is signed by the manufacturer.

The way I understand it is that the keys are burned into the TPM at time of manufacture, and there is no way to extract those keys, software can only ask the TPM to encrypt/decrypt/sign/verify certain data using the keys.

The TPM can then be used to verify certain operations, eg to retrieve the key for an encrypted hard drive.

But it's all a trojan horse because the manufacturer is the one who controls the keys, not the user.

It's "trusted" in the sense that the platform is "trusted" by the manufacturer, not the user.

It's not Windows that's the problem. It's the BMCs and BIOSes. They don't use encrypted sessions. They should.