TLS client authentication with a TPM-held private key (Mbed TLS 4.2): is our approach right, and how do we create the key ID?
Hello Mbed TLS team,
we would like to ask for your advice on a TLS client use case where the private key must stay in an external TPM. We have read the relevant issues and the roadmap, and would like to confirm our understanding and ask for tips.
== 1. Our goal ==
Our device is a TLS client with mutual authentication (device certificate / LDevID). The system is split over several processors (see the attached diagram):
* The "stack processor" runs eCos with Mbed TLS (we are targeting Mbed TLS 4.2 / TF-PSA-Crypto 1.2). * The private LDevID key is stored in a TPM 2.0. The TPM is only reachable from the "application processor" (via the TSS). The two processors communicate through shared memory.
Desired handshake flow (as in the diagram): 1) The server sends its hello and a certificate request. 2) Mbed TLS needs to sign the hash of all previous handshake messages (CertificateVerify). 3) Instead of signing locally, the hash is passed via shared memory to the application processor. 4) The application processor has the TPM sign the hash with the private LDevID key and returns the signature. 5) The signature is handed back to Mbed TLS, which sends the CertificateVerify and continues the handshake. Mbed TLS currently expects the private key to be available locally. We want to delegate only the signature operation, without patching the TLS handshake code. Blocking while waiting for the TPM is acceptable for us, so asynchronous operation is not a requirement.
== 2. What we found so far ==
* MBEDTLS_SSL_ASYNC_PRIVATE is server-side only (and not supported with TLS 1.3), so it does not help for a client. * Issues #7889 and #10643 were both closed with the same answer: no client-side async feature; use a PSA opaque (secure element) driver and point the TLS stack at the key in the external element. #10643 also says the driver dispatch layer has to be edited manually. * The roadmap lists "PSA driver - Handle Opaque Persistent Key in Secure Element - Implementation" (2026 CQ2) and "PSA Secure Element, Crypto Accelerator Support Enhancements" (Future).
== 3. Our approach ==
1) Write a PSA opaque driver with our own key location, with a sign_hash function that sends the hash to the TPM and waits for the signature. 2) Create a PSA key ID that refers to the key in the TPM, so that TLS calls psa_sign_hash() with it and the call reaches our driver. 3) Wrap the key ID with mbedtls_pk_wrap_psa() and pass it with the device certificate to mbedtls_ssl_conf_own_cert(). 4) Add our location to the driver dispatch code so that sign_hash calls our function.
== 4. Where we have difficulties ==
We have difficulties creating a suitable key ID that actually works the way we imagine. The key already exists in the TPM, and we only want PSA to hold a reference to it, so that the handshake signature ends up in our driver function. We do not know how to do this correctly.
== 5. Our questions ==
1) Is our approach a good one for TLS client authentication with a TPM-held key in Mbed TLS 4.2? Do you have tips or pitfalls to share? 2) How should we create the key ID for a key that already exists in an external device? Are there examples, tests or documentation you would point us to? 3) What exactly is covered by the roadmap item "PSA driver - Handle Opaque Persistent Key in Secure Element - Implementation", and what has been done so far? Is it part of TF-PSA-Crypto 1.2 / Mbed TLS 4.2, and does it address our key-ID problem? 4) Is anything planned to make this easier, so that we do not have to edit the dispatch layer and build so much ourselves?
Thank you very much for your help. Best regards,
Beste Grüße / Best regards,
Ruien Karimi
Software Developer
Phone: +49 89 45 656 - 307
E-Mail: ruien.karimi@softing.commailto:ruien.karimi@softing.com
[Softing_Logo_signature]
Softing Industrial Automation (SIA)
Richard-Reitzner-Allee 6 - 85540 Haar - Deutschland
Fax +49 89 45656-492 - www.softing.comhttp://www.softing.com/
Sitz: Haar bei München, Amtsgericht München, HRB 127 604
Softing Aktiengesellschaft: Vorsitzender des Aufsichtsrates: Dr. Horst Schiessl; Vorstand: Dr. Wolfgang Trier (Vorsitzender), Ernst Homolk
Geschäftsführer: Johann Gschwendtner, Thomas Rummel, Dr. Wolfgang Trier
Damn, some new work to do...
Our implementation of QUIC, https://github.com/private-octopus/picoquic/, uses MbedTLS for running on ESP32 class devices. It is very nice to have a "close to the hardware" implementation of crypto functions for small devices. We do not rely on the TLS implementation, we use a common TLS code (https://github.com/h2o/picotls/) which enables us to switch between MbedTLS or OpenSSL depending on the hardware platform. But we do rely on the X.509 functions in the library for parsing X.509 messages, an specifically for verifying certificate chains. Do I understand correctly that we need to build an alternative for that before April 2027?
-- Christian Huitema
On 10/7/2026 5:35 AM, Karimi, Ruien via mbed-tls wrote:
Hello Mbed TLS team,
we would like to ask for your advice on a TLS client use case where the private key must stay in an external TPM. We have read the relevant issues and the roadmap, and would like to confirm our understanding and ask for tips.
== 1. Our goal ==
Our device is a TLS client with mutual authentication (device certificate / LDevID). The system is split over several processors (see the attached diagram):
- The "stack processor" runs eCos with Mbed TLS (we are targeting Mbed TLS 4.2 / TF-PSA-Crypto 1.2).
- The private LDevID key is stored in a TPM 2.0. The TPM is only reachable from the "application processor" (via the TSS). The two processors communicate through shared memory.
Desired handshake flow (as in the diagram):
- The server sends its hello and a certificate request.
- Mbed TLS needs to sign the hash of all previous handshake messages
(CertificateVerify). 3) Instead of signing locally, the hash is passed via shared memory to the application processor. 4) The application processor has the TPM sign the hash with the private LDevID key and returns the signature. 5) The signature is handed back to Mbed TLS, which sends the CertificateVerify and continues the handshake. Mbed TLS currently expects the private key to be available locally. We want to delegate only the signature operation, without patching the TLS handshake code. Blocking while waiting for the TPM is acceptable for us, so asynchronous operation is not a requirement.
== 2. What we found so far ==
- MBEDTLS_SSL_ASYNC_PRIVATE is server-side only (and not supported with TLS 1.3), so it does not help for a client.
- Issues #7889 and #10643 were both closed with the same answer: no client-side async feature; use a PSA opaque (secure element) driver and point the TLS stack at the key in the external element. #10643 also says the driver dispatch layer has to be edited manually.
- The roadmap lists "PSA driver - Handle Opaque Persistent Key in Secure Element - Implementation" (2026 CQ2) and "PSA Secure Element, Crypto Accelerator Support Enhancements" (Future).
== 3. Our approach ==
- Write a PSA opaque driver with our own key location, with a
sign_hash function that sends the hash to the TPM and waits for the signature. 2) Create a PSA key ID that refers to the key in the TPM, so that TLS calls psa_sign_hash() with it and the call reaches our driver. 3) Wrap the key ID with mbedtls_pk_wrap_psa() and pass it with the device certificate to mbedtls_ssl_conf_own_cert(). 4) Add our location to the driver dispatch code so that sign_hash calls our function.
== 4. Where we have difficulties ==
We have difficulties creating a suitable key ID that actually works the way we imagine. The key already exists in the TPM, and we only want PSA to hold a reference to it, so that the handshake signature ends up in our driver function. We do not know how to do this correctly.
== 5. Our questions ==
- Is our approach a good one for TLS client authentication with a
TPM-held key in Mbed TLS 4.2? Do you have tips or pitfalls to share? 2) How should we create the key ID for a key that already exists in an external device? Are there examples, tests or documentation you would point us to? 3) What exactly is covered by the roadmap item "PSA driver - Handle Opaque Persistent Key in Secure Element - Implementation", and what has been done so far? Is it part of TF-PSA-Crypto 1.2 / Mbed TLS 4.2, and does it address our key-ID problem? 4) Is anything planned to make this easier, so that we do not have to edit the dispatch layer and build so much ourselves?
Thank you very much for your help. Best regards,
Beste Grüße / Best regards,
Ruien Karimi
Software Developer
Phone: +49 89 45 656 - 307
E-Mail: _ruien.karimi@softing.com_ mailto:ruien.karimi@softing.com
Softing_Logo_signature
Softing Industrial Automation (SIA)
Richard-Reitzner-Allee 6 - 85540 Haar - Deutschland
Fax +49 89 45656-492 - _www.softing.com_ http://www.softing.com/
Sitz: Haar bei München, Amtsgericht München, HRB 127 604
Softing Aktiengesellschaft: Vorsitzender des Aufsichtsrates: Dr. Horst Schiessl; Vorstand: Dr. Wolfgang Trier (Vorsitzender), Ernst Homolk
Geschäftsführer: Johann Gschwendtner, Thomas Rummel, Dr. Wolfgang Trier
Hi Christian,
This doesn’t necessarily mean that you need to build an alternative for X.509 certificate verification before April 2027:
We are seeking support from the community and hoping that the continued maintenance of the project can be secured. If our efforts are successful you won’t need to do anything.
If our efforts are not successful you still have several options:
* Look for an alternative * Take the bits from Mbed TLS and maintain those as part of your project (which you would need to do with the self-developed variant as well) * Develop your own version
I wish I could give you some assurances, but the future of the project is very uncertain now.
Best regards, Janos
From: Christian Huitema via mbed-tls mbed-tls@lists.trustedfirmware.org Date: Saturday, 10 October 2026 at 00:43 To: Karimi, Ruien ruien.karimi@softing.com; mbed-tls@lists.trustedfirmware.org mbed-tls@lists.trustedfirmware.org Subject: [mbed-tls] Re: TLS client authentication with a TPM-held private key (Mbed TLS 4.2): is our approach right, and how do we create the key ID?
Damn, some new work to do...
Our implementation of QUIC, https://github.com/private-octopus/picoquic/, uses MbedTLS for running on ESP32 class devices. It is very nice to have a "close to the hardware" implementation of crypto functions for small devices. We do not rely on the TLS implementation, we use a common TLS code (https://github.com/h2o/picotls/) which enables us to switch between MbedTLS or OpenSSL depending on the hardware platform. But we do rely on the X.509 functions in the library for parsing X.509 messages, an specifically for verifying certificate chains. Do I understand correctly that we need to build an alternative for that before April 2027?
-- Christian Huitema
On 10/7/2026 5:35 AM, Karimi, Ruien via mbed-tls wrote:
Hello Mbed TLS team,
we would like to ask for your advice on a TLS client use case where the private key must stay in an external TPM. We have read the relevant issues and the roadmap, and would like to confirm our understanding and ask for tips.
== 1. Our goal ==
Our device is a TLS client with mutual authentication (device certificate / LDevID). The system is split over several processors (see the attached diagram):
- The "stack processor" runs eCos with Mbed TLS (we are targeting Mbed TLS 4.2 / TF-PSA-Crypto 1.2).
- The private LDevID key is stored in a TPM 2.0. The TPM is only reachable from the "application processor" (via the TSS). The two processors communicate through shared memory.
Desired handshake flow (as in the diagram):
- The server sends its hello and a certificate request.
- Mbed TLS needs to sign the hash of all previous handshake messages
(CertificateVerify). 3) Instead of signing locally, the hash is passed via shared memory to the application processor. 4) The application processor has the TPM sign the hash with the private LDevID key and returns the signature. 5) The signature is handed back to Mbed TLS, which sends the CertificateVerify and continues the handshake. Mbed TLS currently expects the private key to be available locally. We want to delegate only the signature operation, without patching the TLS handshake code. Blocking while waiting for the TPM is acceptable for us, so asynchronous operation is not a requirement.
== 2. What we found so far ==
- MBEDTLS_SSL_ASYNC_PRIVATE is server-side only (and not supported with TLS 1.3), so it does not help for a client.
- Issues #7889 and #10643 were both closed with the same answer: no client-side async feature; use a PSA opaque (secure element) driver and point the TLS stack at the key in the external element. #10643 also says the driver dispatch layer has to be edited manually.
- The roadmap lists "PSA driver - Handle Opaque Persistent Key in Secure Element - Implementation" (2026 CQ2) and "PSA Secure Element, Crypto Accelerator Support Enhancements" (Future).
== 3. Our approach ==
- Write a PSA opaque driver with our own key location, with a
sign_hash function that sends the hash to the TPM and waits for the signature. 2) Create a PSA key ID that refers to the key in the TPM, so that TLS calls psa_sign_hash() with it and the call reaches our driver. 3) Wrap the key ID with mbedtls_pk_wrap_psa() and pass it with the device certificate to mbedtls_ssl_conf_own_cert(). 4) Add our location to the driver dispatch code so that sign_hash calls our function.
== 4. Where we have difficulties ==
We have difficulties creating a suitable key ID that actually works the way we imagine. The key already exists in the TPM, and we only want PSA to hold a reference to it, so that the handshake signature ends up in our driver function. We do not know how to do this correctly.
== 5. Our questions ==
- Is our approach a good one for TLS client authentication with a
TPM-held key in Mbed TLS 4.2? Do you have tips or pitfalls to share? 2) How should we create the key ID for a key that already exists in an external device? Are there examples, tests or documentation you would point us to? 3) What exactly is covered by the roadmap item "PSA driver - Handle Opaque Persistent Key in Secure Element - Implementation", and what has been done so far? Is it part of TF-PSA-Crypto 1.2 / Mbed TLS 4.2, and does it address our key-ID problem? 4) Is anything planned to make this easier, so that we do not have to edit the dispatch layer and build so much ourselves?
Thank you very much for your help. Best regards,
Beste Grüße / Best regards,
Ruien Karimi
Software Developer
Phone: +49 89 45 656 - 307
E-Mail: _ruien.karimi@softing.com_ mailto:ruien.karimi@softing.com
Softing_Logo_signature
Softing Industrial Automation (SIA)
Richard-Reitzner-Allee 6 - 85540 Haar - Deutschland
Fax +49 89 45656-492 - _www.softing.com_ http://www.softing.com/
Sitz: Haar bei München, Amtsgericht München, HRB 127 604
Softing Aktiengesellschaft: Vorsitzender des Aufsichtsrates: Dr. Horst Schiessl; Vorstand: Dr. Wolfgang Trier (Vorsitzender), Ernst Homolk
Geschäftsführer: Johann Gschwendtner, Thomas Rummel, Dr. Wolfgang Trier
-- mbed-tls mailing list -- mbed-tls@lists.trustedfirmware.org To unsubscribe send an email to mbed-tls-leave@lists.trustedfirmware.org
mbed-tls@lists.trustedfirmware.org
-
Christian Huitema -
Janos Follath -
Karimi, Ruien