It's a bit of a chicken-egg problem when the TPM is the root of trust for the entire system. Sure you can encrypt the data on the bus, but where do you store that key?
You use a Diffie-Hellman key exchange, signed by a cert stored in the CPU on one side and verified by the TPM on the other. CPUs already have such secret certs inside of them, for example for Intels' SGX.
But as you can read in the article linked by /u/osy, the TPM ecosystem is a victim of design by committee where such things as a threat model are not a thing. They were focused on building a "generic security solution" or some other nonsense, instead of making a threat model, then a protocol, then a verification of the protocol under the threat model - like people did for example with TLS 1.3.
Exactly. An attacker that has full access to the device can get past encrypted TPM parameters, it would just slow them down. The best method is pre-boot auth where the TPM itself requires a PIN to release the keys. Windows doesn't use that by default, but it can be enabled.
It could be burned into the CPU die by blowing fuses, or stored in a tiny bit of on-die flash, or stored encrypted in SPI flash, encrypted with a factory secret key burned into the CPU at manufacture.
But more generally, you don’t need a long term key to prevent sniffing attacks like this; Diffie-Hellman is a thing. Doing an unauthenticated DH would make this attack harder and slower (active MitM probably requires removing the TPM chip from
the board) but would not prevent it.
Maybe it would be more practical MITMing near the CPU. Some plastic "extender" routing the relevant pins through an external device but still allowing for cooling?
But could the communication be authenticated? Like in CPU having a public cert, self signed. TPM then can authenticate the CPU that generates the key and later sends it only over an authenticated TLS session to the same CPU.
But as you can read in the article linked by /u/osy, the TPM ecosystem is a victim of design by committee where such things as a threat model are not a thing. They were focused on building a "generic security solution" or some other nonsense, instead of making a threat model, then a protocol, then a verification of the protocol under the threat model - like people did for example with TLS 1.3.