0

I have seen some implementation of TLS using TPM 2.0 like the tpm2-tss-engine engine which can be used to protect the server private key associated with the certificate and sign with it inside the TPM. The same thing can be done with the client if client optional client authentication is enabled.

My question is whether the TPM would have the ability to protect the entire TLS 1.3 handshake. It will required to perform the ECDH key exchange with the TPM and keep the computed shared secrets in the TPM, then the HKDF should also be performed inside the TPM to protect all the derived secrets and keys. The TPM doesn’t support AEAD mode of operation but GCM for example could be implemented using ECB mode : the counter is incremented outside the TPM but each time it is encrypted in the TPM with ECB. The XOR with the plaintext and the computation of the authentication tag are also done outside. This way the symmetric keys never leave the TPM.

An interest of such an implementation would be to prevent an attacker to have access to the resumption master secret of a client even though this client is compromised. Thus the attacker would not be able to steal simultaneously the resumption master secret and the session ticket to later resume a session and spoof client identity if client authentication has been used in the handshake (the session ticket would then contain information about the client identity to avoid having to resend the certificate)

Does the TPM have the necessary functions to carry out this scenario and to protect all the secrets without revealing any outside ?

runnenolleb
  • 1
  • 1
  • 3
    Check the TCG docs (https://trustedcomputinggroup.org/resource/tpm-library-specification/) for all commands TPM2 can do. I see no support for GCM, and I doubt you want to do TLS CBC. Your TLS implementation, if feasible, would be extremely slow and frankly useless. – Z.T. Jun 07 '19 at 17:05
  • Thank you for your answer. Indeed I don’t want to use CBC since I’m using TLS 1.3 which only support GCM or CCM but I tought it was possible to implement GCM using ECB. However the TPM specification you linked indicates that the ECDH command output the X and Y coordinates of the computed point outside of the TPM. So I think it is not possible to protect the handshake secrets inside the TPM. – runnenolleb Jun 11 '19 at 16:16
  • 1
    No idea how you would implement GHASH for GCM, but I think you can implement CCM using just AES. But the TPM2 API is not designed to keep intermediate values in TPM memory, chain call to TPM2_ECDH_ZGen to call to KDF to call to AES etc. – Z.T. Jun 11 '19 at 17:34

2 Answers2

1

You might not be able to make all the TLS secrets protected by the TPM but you could make some of them. You might also not want to store all the secrets. The TPM is much more inefficient than the average processor specially with accelerated cryptographic instruction sets.

The TPM 2.0 specification provides support for AES encryption with certain modes of operation (CBC, ECB, OFB, CTR and OCB. It's worth mentioning that not all TPMs have symmetric encryption/decryption capabilities due to import export regulations.

The TPM does provide great support for ECDH with secp256r1 (P-256). Which makes it an interesting candidate to store TLS long term secrets. It's a great candidate for mTLS where you have the certificate key protected by the TPM

You could generate a CSR and get it signed with the TPM, then during each handshake use the TPM to sign the parameters used for DH key exchange.

lobato
  • 11
  • 1
-1

We at WolfSSL have a full TLS v1.3 client and server example using TPM 2.0 on the backend with wolfSSL and wolfTPM here: https://github.com/wolfSSL/wolfTPM/tree/master/examples/tls

schroeder
  • 123,438
  • 55
  • 284
  • 319
David Garske
  • 1