[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.