Add new Zephyr module for Mbed TLS 4.0 + TF-PSA-Crypto 1.0 releases

[valeriosetti]

Problem Description

On October 15th 2025 the joint release of Mbed TLS 4.0 and TF-PSA-Crypto 1.0 has been announced.

Many changes are included in it, some of which are of course breaking stuff with previous LTS release which is the one we currently use in Zephyr. The 2 main important ones are:

• a repo split: it won't be just Mbed TLS, but Mbed TLS (v4.0) + TF-PSA-Crypto (v1.0). The former only includes TLS and X.509 while the latter, which is a git sub-repo of the former, all the low level crypto support and they are both necessary.
  • I don't recommend flattening TF-PSA-Crypto sub-repo inside Mbed TLS because then porting patches from upstream would become harder in some cases.
• PSA API become the de-facto standard way to have access to crypto support. This allows vendor to more easily get support for their custom crypto libraries and/or support TF-M.

The standard update process for Zephyr would be:

• deprecating all the legacy crypto support that's being removed from 4.0/1.0;
• wait for the deprecation period to expire (2 releases)
• remove legacy crypto usage
• upgrade Mbed TLS.

However if we consider that in TSC it's currently being discussed to move to 2 release per year, this means that we'll have to wait for roughly a year to transition to this new Mbed TLS release. This also doesn't account for the fact that Mbed TLS is not only used in Zephyr codebase, but also in some external modules (ex: hostap, openthread) which might need some time to transition to PSA API. This would add extra delay in the adoption of the new solution.
On the other hand vendors might be interested in adopting this new release as soon as possible in order to benefit from the wider usage of PSA API.

Proposed Change (Summary)

Introduce new Mbed TLS 4.0 + TF-PSA-Crypto 1.0 as new modules in parallel with the existing 3.6 LTS.

Proposed Change (Detailed)

What if we add a couple of new modules to Zephyr, one for Mbed TLS 4.0 and one for TF-PSA-Crypto 1.0, which live in parallel with the current LTS support. Of course the two (LTS vs 4.0) should be mutually exclusive from a build point of view, with LTS one being the default choice for backward compatibility.
This way we'll give more time to end users and various subsystems and modules to transition to this new solution, and meanwhile the ones who would like to start benefiting from this new release can do so.

Dependencies

Assuming the new release is added in parallel to the current one and the latter is kept as default choice for the time being, nothing should break ideally.

Concerns and Unresolved Questions

No response

Alternatives Considered

Go through normal Zephyr's deprecation + update path, but this would require much longer.

[tomi-font]

Big +1 to this approach. It will also make the integration of the new version easier which will likely result in a better approach.

[dleach02]

I approve this approach but we should clarify the roadmap to PSA/mbedtls 4.0 and when that will become the default. Given Zephyr's next LTS will likely be spring 2027 we should target a transition to PSA/mbedtls as default for next fall's release.

[mbolivar]

What if we add a couple of new modules to Zephyr, one for Mbed TLS 4.0 and one for TF-PSA-Crypto 1.0, which live in parallel with the current LTS support.

Can you please provide more details here from an integration perspective?

Are you going to have 3 west projects (old mbedTLS, new mbedTLS, new crypto library), or 2 west projects (old mbedTLS plus new mbedTLS plus git submodule via west)?

[valeriosetti]

Are you going to have 3 west projects (old mbedTLS, new mbedTLS, new crypto library), or 2 west projects (old mbedTLS plus new mbedTLS plus git submodule via west)?

@mbolivar
I was thinking about 3 different west projects. I think this way it would be easier for anyone, in case of issues related to some source, to follow along and find where it's located. Having the same repo that can be built in more than 1 "version" looks a bit messy. I know it takes more disk space though.

The problem with this approach that was raised today (October 20th) during the Security WG Meeting was what would happen if I have a subsystem that still uses the legacy version and another one that instead use the new one? Assuming there's no conflict in building the library twice (ex: functions' names collisions) then we would still build the library twice.
I think this somehow relates to the question made earlier by @dleach02, but I don't have any good answer to this right now unfortunately. Any idea is welcome!

[tomi-font]

I was thinking about 3 different west projects. I think this way it would be easier for anyone, in case of issues related to some source, to follow along and find where it's located. Having the same repo that can be built in more than 1 "version" looks a bit messy. I know it takes more disk space though.

I think @mbolivar's point was just that you can actually specify submodules in West so for Mbed TLS 4.0 you could have TF-PSA-Crypto defined as a submodule of it in west.yml.
In any case we'll want TF-PSA-Crypto to be usable independently of Mbed TLS; I don't know if defining the former as a submodule of the former for West would hinder that?

The problem with this approach that was raised today (October 20th) during the Security WG Meeting was what would happen if I have a subsystem that still uses the legacy version and another one that instead use the new one?

The thing here is, what do you mean by "still uses the legacy version"? Using legacy Mbed TLS APIs?
Mbed TLS 3.6 already has the PSA Crypto API fully available, so I don't see how that would be a problem. If a component in your system requires legacy Mbed TLS, then you would have to use the older version of Mbed TLS.

Assuming there's no conflict in building the library twice (ex: functions' names collisions) then we would still build the library twice.
I think this somehow relates to the question made earlier by @dleach02, but I don't have any good answer to this right now unfortunately. Any idea is welcome!

Don't know if I'm missing the point but I don't see how you could build both Mbed TLS versions, you would get a lot of conflicts and I don't see why you would wanna do that in the first place.

[valeriosetti]

In any case we'll want TF-PSA-Crypto to be usable independently of Mbed TLS; I don't know if defining the former as a submodule of the former for West would hinder that?

As for this point I don't know because I'm not that expert of West tool. However I confirm that it should be possible to have TF-PSA-Crypto as standalone in case the application only needs crypto support, but not the opposite (i.e. Mbed TLS without TF-PSA-Crypto).

Mbed TLS 3.6 already has the PSA Crypto API fully available, so I don't see how that would be a problem. If a component in your system requires legacy Mbed TLS, then you would have to use the older version of Mbed TLS.

I was thinking of a scenario like this: let's say there is a module (ex: hostap) that needs legacy ECP module to manually do EC curves computations, but on the same build you are also enabling some other subsystem that already transitioned to PSA Crypto API. It's true that you can still use the 3.6 LTS release of Mbed TLS and so having both legacy crypto and PSA Crypto API, but this fallback would be determined by the enablement of hostap. Isn't this a bit tricky?

Don't know if I'm missing the point but I don't see how you could build both Mbed TLS versions, you would get a lot of conflicts and I don't see why you would wanna do that in the first place.

Indeed I'm pretty sure you cannot do that and I agree it would make no sense. That was my point as well.