- mbed-tls - lists.trustedfirmware.org

[Mbed-tls-announce] Announcement: Future Maintenance of Mbed TLS

by Janos Follath via Mbed-tls-announce

Dear Mbed TLS Users, We are preparing for a transition in the maintenance of TLS and X.509 libraries (both contained in the Mbed TLS project). The existing maintainers will continue to develop and maintain TF-PSA-Crypto, which remains an actively maintained part of the project. The existing maintainers will cease their involvement in their development and maintenance of Mbed TLS from April 2027. Unless new maintainers have joined the project and ramped up by that time, security incident response, security fixes, and releases will cease from April 2027. The future maintenance arrangements for the TLS and X.509 libraries have not yet been determined. We welcome contributions from organisations and individuals interested in helping sustain Mbed TLS, whether through engineering resources, funding, or other forms of support. The existing maintainers are committed to supporting new maintainers as they ramp up and take on responsibility for the libraries. If you or your organisation are interested in contributing to the future maintenance of Mbed TLS, please contact mbed-tls-owner(a)lists.trustedfirmware.org. We recognise the importance of these libraries to their users and the wider ecosystem, and hope that, with community involvement, a sustainable path forward can be established. Kind regards, The Mbed TLS Team IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you. -- Mbed-tls-announce mailing list -- mbed-tls-announce(a)lists.trustedfirmware.org To unsubscribe send an email to mbed-tls-announce-leave(a)lists.trustedfirmware.org

11 hours, 35 minutes

6
7
0 0

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?

by Karimi, Ruien

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(a)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

13 hours, 6 minutes

3
2
0 0

Re: MbedTLS X.509 Basic Constraints Extension Issue (was: Re: Security Contact for mbedtls?)

by Gilles Peskine

Hello again, Looking at the content of the issue, it is one of the two bugs in basicConstraints parsing covered by CVE-2026-49300, which we fixed in our July release. https://mbed-tls.readthedocs.io/en/latest/security-advisories/mbedtls-secur… I can add you as an independent reporter to the credits list. Let me know how you'd like to be acknowledged. -- Best regards, Gilles Peskine On 19/08/2026 10:15, Maximilian Radoy wrote: > > Dear Gilles Peskine, > > we are trying to get in contact with > mbed-tls-security(a)lists.trustedfirmware.org for almost three months > now regarding a security-relevant finding in mbedtls, but we do not > get any response at all. > > As you seem to be (according to github) actively involved in that > project, we'd like to ask you whether there are any alternative ways > to deliver our security report? Otherwise, we may post it as regular > github issue. > > Thank you in advance for your help! > > Best regards, > Maximilian Radoy > > -- > > *Maximilian Radoy* > Research Assistant > System Security Group > Paderborn University > Universität Paderborn <https://www.uni-paderborn.de/en> > Fürstenallee 11 > 33102 Paderborn > Germany > *Office* F2.308 > *Telephone* +49 5251 60-6724 > *E-Mail* maximilian.radoy(a)uni-paderborn.de > > > Instagram <https://www.instagram.com/uni_paderborn/> Facebook > <https://www.facebook.com/unipaderborn> LinkedIn > <https://de.linkedin.com/school/uni-paderborn/> YouTube > <https://www.youtube.com/user/upbvideo> >

1 month, 3 weeks

1
0
0 0

DTLS 1.3 contribution

by Yaron Sheffer

[Apologies, resending as text] Hi, I've been working on an implementation of DTLS 1.3 in Mbed TLS, basically as a side project. For transparency, I have used AI heavily in this work, but I am fully accountable for the code. Obviously, this is a large quantity of code. I would appreciate your feedback on the following plan [1]: I could break the contribution into 7-8 PRs (first PR about 1k LOC, largest PR 5-6K). I would ensure from day one that the new functionality remains off by default and avoid any changes to existing TLS and DTLS 1.2 behavior. Then we could have users try it out for a while as opt-in, and only then the project team can decide to enable it by default. The code base is available as a branch [2] and is accompanied by copious documentation [3]. Recently I updated the code in line with both 4.2.0 of this library and the new version -02 of the rfc9147bis Internet Draft. The code includes unit tests, integration tests and interoperability testing with wolfSSL. I have also run multiple security reviews of the code and reviewed it manually, and I'm ready to iterate as needed to follow the project's processes. If you are open to this plan, I will open a tracking issue right away and follow with smallish PR1. Looking forward to contributing to this community! Thanks, Yaron [1] https://github.com/yaronf/mbedtls/blob/dtls13/local-docs/upstream-dtls13-pr… [2] https://github.com/yaronf/mbedtls/tree/dtls13 [3] https://github.com/yaronf/mbedtls/tree/dtls13/local-docs

2 months

2
1
0 0

DTLS 1.3 contribution

by Yaron Sheffer

2 months, 1 week

1
0
0 0

MBEDTLS_PLATFORM_TIME_TYPE_MACRO for custom mbedtls_time_t

by Huber, Ralf

Dear Mbed TLS contributors, We are using mbedtls v4 for X.509 certificate verification on a 32 bit microcontroller. The device has an RTC chip and we use its time for mbedtls by defining MBEDTLS_PLATFORM_TIME_ALT. This is working so far. The compiler provides <time.h>, with time_t being a signed 32 bit type. I would like to stop mbedtls from using the date and time functions of <time.h> and change mbedtls_time_t to unsigned 32 bit to avoid the year 2038 problem (when signed 32 bit time_t will overflow). To do this, I defined #define MBEDTLS_PLATFORM_TIME_TYPE_MACRO unsigned long I also changed the custom time function (MBEDTLS_PLATFORM_TIME_ALT) to return unsigned values and I defined MBEDTLS_PLATFORM_GMTIME_R_ALT and provided a custom mbedtls_platform_gmtime_r() that accepts unsigned values. When I build mbedtls with these settings, I get an error from tf_psa_crypto_check_config.h: #if defined(MBEDTLS_PLATFORM_TIME_TYPE_MACRO) &&\ ( defined(MBEDTLS_PLATFORM_STD_TIME) ||\ defined(MBEDTLS_PLATFORM_TIME_ALT) ) #error "MBEDTLS_PLATFORM_TIME_TYPE_MACRO and MBEDTLS_PLATFORM_STD_TIME/MBEDTLS_PLATFORM_TIME_ALT cannot be defined simultaneously" #endif I wonder if this check is actually necessary or maybe a mistake? Actually, I expected the opposite, i.e. #if defined(MBEDTLS_PLATFORM_TIME_TYPE_MACRO) &&\ !( defined(MBEDTLS_PLATFORM_STD_TIME) ||\ defined(MBEDTLS_PLATFORM_TIME_ALT) ) #error "Must provide alternate time() function compatible with type defined by MBEDTLS_PLATFORM_TIME_TYPE_MACRO" #endif Could somebody please explain why MBEDTLS_PLATFORM_TIME_TYPE_MACRO can't be used with MBEDTLS_PLATFORM_TIME_ALT? Can/Should I comment out the #error? I tried that and the library compiles without errors, and the software using the library also compiles without errors, but I have not yet checked, if it actually works. Best regards, Ralf Huber KION Supply Chain Solutions Linde Material Handling GmbH, Sitz der Gesellschaft: Aschaffenburg, Registergericht: Aschaffenburg HRB9963, Ust-IdNr. DE814809128, Gesch?ftsf?hrung: Andreas Krinninger (Vorsitzender), Dr. Karoline Jung-Senssfelder, Ulrike Just, Dr. Frank Schepp, Vorsitzende des Aufsichtsrats: Valeria Gargiulo

2 months, 2 weeks

2
3
0 0

Post quantum support, x25519mlkem768

by Christian Huitema

Do we have support for x25519mlkem768 in Mbed TLS? -- Christian Huitema

2 months, 2 weeks

2
1
0 0

Publish Mbed TLS security advisories in machine-readable format for SBOM scanners

by Schlegelmilch, Nils

Hi Mbed TLS team, I would like to ask whether Mbed TLS could publish security advisories in a machine-readable format, for example GitHub Security Advisories or OSV. Security fixes are currently visible in release notes and documentation before they appear in NVD/GHSA/OSV. This creates a detection gap for automated vulnerability scanners such as Dependency-Track, because they rely on structured advisory data with affected versions, fixed versions, and identifiers such as CPE, PURL, or Git ranges. For example, when a security release is available, Dependency-Track may not alert until the corresponding CVE or advisory appears in one of its vulnerability data sources. This can delay automated remediation even though a patched Mbed TLS version is already released. Would the project consider publishing machine-readable advisories at release time, or is there already a preferred process for this? Thanks! Nils Schlegelmilch Development Phone +49 7836 50-9883 E-Mail n.schlegelmilch(a)vega.com<mailto:n.schlegelmilch@vega.com> [cid:image001.png@01DD1042.23E9BE30] VEGA Grieshaber KG | Am Hohenstein 113 | 77761 Schiltach | Germany [cid:image002.png@01DD1042.23E9BE30]<https://de.linkedin.com/company/vega-grieshaber-kg>[cid:image003.png@01DD1042.23E9BE30]<https://www.vega.com/>[cid:image004.png@01DD1042.23E9BE30]<https://www.youtube.com/vegagrieshaberkg> Unsere Datenschutzhinweise und somit auch die Informationen gem. Art. 13 DSGVO finden Sie im Internet unter www.vega.com/datenschutz VEGA Grieshaber KG Kommanditgesellschaft mit Sitz in Wolfach Registergericht: Freiburg HRA 680 687 Persönlich haftende Gesellschafter: Isabel Grieshaber Grieshaber Holding GmbH Sitz: Wolfach Registergericht: Freiburg HRB 680 271 Geschäftsführer: Isabel Grieshaber, Markus Kniesel USt.-Id.-Nr.: DE143030199

3 months

2
1
0 0

Mbed TLS and TF-PSA-Crypto releases now available

by Minos Galanakis

Hi Mbed TLS users, We are pleased to announce the release of Mbed TLS 4.2.0, Mbed TLS 4.1.1, Mbed TLS 3.6.7, TF-PSA-Crypto 1.2.0, and TF-PSA-Crypto 1.1.1. These releases address several security issues, include bug fixes, and bring other improvements. Mbed TLS 4.1 and TF-PSA-Crypto 1.1 remain Long Term Support (LTS) releases and are supported until March 2029. Mbed TLS 3.6 remains supported until March 2027. We recommend all users review the changes, assess any impact, and upgrade as appropriate. Full details are available in the release notes: https://github.com/Mbed-TLS/mbedtls/releases/tag/mbedtls-4.2.0 https://github.com/Mbed-TLS/mbedtls/releases/tag/mbedtls-4.1.1 https://github.com/Mbed-TLS/mbedtls/releases/tag/mbedtls-3.6.7 https://github.com/Mbed-TLS/TF-PSA-Crypto/releases/tag/tf-psa-crypto-1.2.0 https://github.com/Mbed-TLS/TF-PSA-Crypto/releases/tag/tf-psa-crypto-1.1.1 Kind regards, The Mbed TLS Team

3 months, 1 week

1
0
0 0

[Mbed-tls-announce] Mbed TLS and TF-PSA-Crypto releases now available

by Minos Galanakis via Mbed-tls-announce

Hi Mbed TLS users, We are pleased to announce the release of Mbed TLS 4.2.0, Mbed TLS 4.1.1, Mbed TLS 3.6.7, TF-PSA-Crypto 1.2.0, and TF-PSA-Crypto 1.1.1. These releases address several security issues, include bug fixes, and bring other improvements. Mbed TLS 4.1 and TF-PSA-Crypto 1.1 remain Long Term Support (LTS) releases and are supported until March 2029. Mbed TLS 3.6 remains supported until March 2027. We recommend all users review the changes, assess any impact, and upgrade as appropriate. Full details are available in the release notes: https://github.com/Mbed-TLS/mbedtls/releases/tag/mbedtls-4.2.0 https://github.com/Mbed-TLS/mbedtls/releases/tag/mbedtls-4.1.1 https://github.com/Mbed-TLS/mbedtls/releases/tag/mbedtls-3.6.7 https://github.com/Mbed-TLS/TF-PSA-Crypto/releases/tag/tf-psa-crypto-1.2.0 https://github.com/Mbed-TLS/TF-PSA-Crypto/releases/tag/tf-psa-crypto-1.1.1 Kind regards, The Mbed TLS Team IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you. -- Mbed-tls-announce mailing list -- mbed-tls-announce(a)lists.trustedfirmware.org To unsubscribe send an email to mbed-tls-announce-leave(a)lists.trustedfirmware.org

3 months, 1 week

1
0
0 0

2026

2025

2024

2023

2022

2021

2020

mbed-tls