How to interface a TPM to store X509 device certificate with azure-iot-middleware-freertos and azure-sdk-for-c

Question

I have been looking through the provisioning samples in the azure-iot-middleware-freertos and iot-middleware-freertos-samples.
The sample loads the azure root cert, and also the device private and public keys in the prvSetupNetworkCredentials
We have a TPM on our device and would like to use that to generate and store the device key as suggested here. During manufacturing we will retrieve the public key from the device and provide that to the DPS during enrollment. The public and private keys are stored in the TPM. Only the public key is accessible.

Where does the azure-iot-middleware-freertos or azure-sdk-for-c get initialized with the public key for when the device registration object is published or what structure needs to be initialized with this key.

How and at what state in the registration is the private key used during the x509 attestation and where should we interface our TPM to use it for authentication?

Our platform uses mbedTLS and has an MQTT port that the middleware can interface to. So this is a nearly perfect solution except for being able to use the TPM for the X509 key stoarge.

Our device is a an M4 with mbedTLS, wolfTPM, and LWIP.

Updated the question with the below comments so that future readers are benefited from this thread! Thanks to @Geoff Shera .

Is the key exchange possession challenged in the TLS handshake?

Is this how the attestation and proof of possession works? I am finding the details of where the X509 proof of possession challenge occurs and where to tie in secret key storage in a TPM very difficult to locate.

1. The DPS is enrolled with the device public x509 leaf certificate.
2. The device X509 leaf secret key is used in the TLS handshake. It is the secret key provided to the server in the TLS client key exchange. (prvSetupNetworkCredentials)
3. Following completion of the TLS handshake the MQTT connect provides the registrationID (which is the leaf CN).
4. The MQTT publish contains the device public X509 key.
5. The DPS will send a RegistrationOperationStatus with the IOT hub parameters.

Answer 1

Hi @Geoff Shera

Might this thread helps? https://github.com/Mbed-TLS/mbedtls/issues/1858

It looks like you need to offload some of the TLS handshake to the TPM. The elements in the NetworkCredentials_t struct are only used to pass to the TLS stack port of your choice (for us, the main one is mbedTLS here). You can modify things like the tlsHandshake function to insert TPM functionality (maybe guided by the mbedtls issue linked above). Let me know if that helps at all. Unfortunately, we don't have concrete example usage at this time.