Hello,

Using the X.509 and TLS code in Mbed TLS with a completely independent implementation of the PSA Crypto API is not officially supported, and is not something we plan for the 3.6 long-term support branch. It will require some patches to the source code and come with limitations.

We do support builds without linking Mbed TLS's own cryptography implementation into the same executable as the X.509/TLS code in two ways. First, you can enable PSA drivers and disable the corresponding legacy cryptography. In our documentation, we call this “driver-only builds”. This is documented in https://github.com/Mbed-TLS/mbedtls/blob/mbedtls-3.6.0/docs/driver-only-builds.md . In a nutshell, it works for most of TLS, excluding RSA (where TLS code still needs legacy crypto functions).

Second, you can link X.509/TLS with a client-server implementation of the PSA crypto API that is based on Mbed TLS. This is not something we officially support mainly because we don't yet have the tooling to support it properly. However, it is used in production on some platforms using TF-M, and we generally expect it to work in most configurations where driver-only builds work.

Your use case is a third step in this progression, where the PSA Crypto API implementation is not based on Mbed TLS at all. This should be doable, again, by leveraging driver-only builds. You'll likely need to define a number of compilation options, and possibly change a few #if checks in places (at least I expect some complaints in check_config.h that would be spurious in this scenario). In addition to what's mentioned in the driver-only build document, some things that come to mind:

Enable MBEDTLS_USE_PSA_CRYPTO and MBEDTLS_PSA_CRYPTO_CONFIG.
Define PSA_WANT_xxx macros corresponding to cryptographic mechanisms that your implementation provides.
You may need to manually define some of the internal symbols that are auto-enabled by driver-only builds, such as MBEDTLS_MD_LIGHT and MBEDTLS_ECP_LIGHT. You do need a few functions from ecp.c, but with MBEDTLS_ECP_LIGHT enabled and MBEDTLS_ECP_C disabled, that should keep ecp.o small. If you only use ECC and not RSA or DHM, then I think you can get away without bignum.o.
You should not need entropy.o or a DRBG module. Pass mbedtls_psa_get_random and MBEDTLS_PSA_RANDOM_STATE to mbedtls_ssl_conf_rng() and other functions to use the PSA RNG.

For the most part, if the compiler is happy, it should work at runtime. However, do be careful to have the right values for buffer size macros (PSA_xxx_SIZE): if they are too small, there is a risk of buffer overflows. We normally validate those through unit tests which probably wouldn't work against an alternative implementation.

For gradually ramping up, I would suggest starting with a PSK-only TLS build, then X.509 with ECC only, then TLS with ECDH-ECDSA.

Hope this helps,

--
Gilles Peskine
Mbed TLS developer

On 29/01/2025 23:47, Zak, Kevin via mbed-tls wrote:

Hello mbedtls mailing list,

I’m working to modify mbedTLS (3.6.2) to use our PSA Crypto Implementation in a separate library. Our solution does not make use of PSA ‘drivers’ that mbedTLS refers to. I’ve modified makefiles to not build PSA Crypto files, and have enabled MBEDTLS_PSA_CRYPTO_C & MBEDTLS_USE_PSA_CRYPTO. I’ve also defined MBEDTLS_PSA_ACCEL_ALG_XXX for our supported algorithms.

Is there a good way to determine whether a given TLS/X509 configuration would require a certain ‘legacy’ (maybe a better term is ‘non-PSA’) crypto file to be built into the mbedTLS library?

The goal is to build as few crypto source files into the mbedTLS source files as possible, maximizing usage of our separate PSA implementation

Example: My test application using mbedtls_x509_crt_parse() receives linking errors for mbedtls_ecp_(group/point)_xxx() and mbedtls_mpi_xxx() that are referenced in pkparse.c (which I am building into the library).

Ecp.c is currently excluded from the build (as is its define) – if I add it, I add significantly more linking errors for mbedtls_mpi APIs. I was under the impression that ECP and MPI APIs could be avoided with the correct configuration.

If ecp/mpi helper APIs are needed still for x509, this would be good to know. However, I’d like to avoid usage of MPI APIs that perform actual software calculations.

See the screenshot for a list of non-PSA crypto files I am currently building to test with. I imagine I may have to add more incrementally.

Any insights on this general use case or my ECP troubles with x509 would be appreciated. I plan to extend the strategy as these are the findings from an attempt to use just one x509 API.

Best,

Kevin Zak