[cryptonector]

> A dTPM uses an unencrypted protocol to communicate with the CPU

While that is strictly speaking true, the TPM command set allows you to set up an encrypted session to the TPM using an ECDH or RSA key for key exchange that authenticates the TPM.

The problem is that the BMCs and BIOSes out there don't record a public key for a primary key on the TPM and then don't bother using encrypted sessions (not even opportunistically getting that public key from the TPM, which would defeat passive attacks).

That's a software problem, not a TPM problem!

I know that TPM 2.0 is a huge topic, so it's quite forgivable that people don't know these things. I've written a tutorial that might help: https://github.com/tpm2dev/tpm.dev.tutorials/tree/master/Int...

[wkat4242]

Thanks, I didn't know that, I thought indeed that it was simply not possible with TPM 2.0.

I do think it's time for a TPM 3.0 though. What apple does with their T2 security chip, and later with the M1/M2, is having the secure element not only handle the key material but the actual encryption as well. They have hardware acceleration that can handle encryption at full disk speeds. This is still a much better option than a TPM especially with symmetric encryption where the key would inevitably end up in the main CPU. In Apple's scenario this no longer happens.

[cryptonector]

There isn't that much that I'd do in a TPM 3.0:

- encrypt all command and response parameters instead of up to just one

- add a version of TPM2_Quote() that encrypts and signs so one can have ciphertext that one can demonstrate were made by a TPM encrypting to a restricted, shielded key

- add a small secure enclave facility

- add more EC algorithms, EdDSA, etc.

- add more cipher modes for AES

- increase RAM and NVRAM requirements

All of this can be done incrementally in 2.x, so calling it 3.0 would be just marketing (perhaps pretty good marketing).