[p_l]

Funnily enough, in TPM 2.0 there's way around MITM attacks like that - you can establish encrypted connection between TPM and CPU, which outside first-time configuration (which should happen in controlled environment anyway) should provide reasonable roadblock to successful MITM attack.

But CPU-side software needs to use it, and without default well-known keys...

[Vogtinator]

Doesn't work either: To establish the secure connection, you need some way to verify the other end (through public keys, certificates). That verification happens before any measurements can be done securely, so it can be bypassed.

[IshKebab]

I think he's saying you can verify the other end by manufacturing the PC yourself and making the initial connection in your factory.

[kukrimate]

Unfortunately encrypted sessions without an interactively provided secret like a PIN are no defence against attacker with physical access.

You either need an interactively provided PIN, or a TPM integrated into the CPU/SoC to be secure in such a scenario.

[wtallis]

Why doesn't a key exchange in a secure environment before any attacker has physical access give the same security benefits of "an interactively provided secret like a PIN"?

[kukrimate]

Because where do you store the CPU side private key after the exchange for future sessions?

The secure storage is the TPM, but here you cannot obviously store the secret in the TPM, it's a chicken and egg problem.

Thus your secret could only be on disk or in flash in and the attacker can just get it.

[oasisaimlessly]

> Because where do you store the CPU side private key after the exchange for future sessions?

eFuses, maybe? Or a bit of battery-backed SRAM. Lots of devices have a small amount of hardened storage for e.g. encryption keys. FPGAs supporting bitstream encryption and Atmel's ATSHA device line are examples.

> CryptoAuthentication devices have full metal shields over all of the internal circuitry, so that if an attacker cuts or short circuits any trace in the shield, the product stops functioning.

[kukrimate]

> eFuses, maybe? Or a bit of battery-backed SRAM. Lots of devices have a small amount of hardened storage for e.g. encryption keys. FPGAs supporting bitstream encryption and Atmel's ATSHA device line are examples.

To clarify, I was referring to the status quo of current discrete TPM implementations, from a bigger picture perspective, there is certainly room for improvement.

Also I am not sure the current TPM standard is compatible with that idea at all. Operating systems set up their own TPM sessions, so there would need to be secret storage only available to a specific operatings system, e.g. similar to what TPM provides, and we are back to the chicken and egg scenario.

[SSLy]

vast majority of fTPM 2.0's are chips placed on the CPU die anyway

[p_l]

it's a misnomer, a bit.

fTPM is a firmware-based TPM implemented, usually, by coprocessor (or trustzone style enclave) inside the CPU, yes. It's not related to what TPM standard it implements

You can also have external TPM 2.0 compliant devices (commonly referred to as dTPM, probably brought the naming from iGPU/dGPU), and in fact many options offered for making desktops fully compliant with windows 11 (which requires TPM 2.0) involve a dedicated TPM 2.0 chip.

Ultimately, TPM standard does not care where the chip is, it just provides mechanisms for their use, which do include encrypted tamper protected interface... if one wants to use it.

[SSLy]

You're correct, but also I'm reasonably certain that, as much bullshit the list of Win 11 supported CPUs is, all the CPUs on it have fTPM 2.0 available.

[p_l]

In practice it's a matter of how the motherboard firmware is set up, so there's a lot of possible breakage.