Hi Massimiliano,

First, please note that Mbed TLS 2.28 is no longer maintained and has known vulnerabilities. I strongly recommend that you use Mbed TLS 3.6 (the only long-time support branch we currently maintain) or TF-PSA-Crypto 1.0 (latest release).

Regarding ALT implementations, they don't support opaque keys. That was one of the problems that we set out to solve with the API changes from Mbed TLS legacy (mbedtls_xxx) to PSA (psa_xxx). PSA makes all keys opaque to the application except through explicit import/export, and can make keys opaque to the main processor through opaque drivers. The basic features are supported in Mbed TLS 2.28, but driver support significantly improved in later versions. Writing drivers is not very well documented and requires editing some files; we're working on improving that.

Some relevant documentation:

PSA driver tutorial: https://github.com/Mbed-TLS/mbedtls/blob/mbedtls-3.6/docs/psa-driver-example-and-guide.md
PSA driver developer's guide: https://github.com/Mbed-TLS/mbedtls/blob/mbedtls-3.6/docs/proposed/psa-driver-developer-guide.md
PSA transition guide, if you have code that's using legacy APIs: https://github.com/Mbed-TLS/mbedtls/blob/mbedtls-3.6/docs/psa-transition.md

For some very specific use cases, there are other ways to bypass the low-level crypto APIs: MBEDTLS_PK_RSA_ALT_SUPPORT lets you have opaque RSA keys through PK/X.509/TLS in Mbed TLS up to 3.6.x, and MBEDTLS_SSL_ASYNC_PRIVATE lets you use an opaque RSA or ECDSA key as a TLS server's signing key.

Best regards,

--
Gilles Peskine
TF-PSA-Crypto and Mbed TLS developer

On 19/11/2025 12:11, Massimiliano Cialdi via mbed-tls wrote:

Hi,
I’m working with Mbed TLS 2.28.x on a microcontroller that provides a built-in crypto engine.
The existing *_ALT support works fine for performance, and higher-level modules correctly route their block operations through the accelerated backend.

On this platform the crypto hardware can also use internal key material stored in dedicated slots. These values are not accessible as byte arrays and cannot be passed to the usual setkey_*() API.

Question

Is there a recommended way to configure an ALT implementation so that it can select an internal key slot instead of receiving a buffer?
Or, more generally, how should an ALT backend represent a key that is not exposed to software?

Any guidance on the intended design would be appreciated.

Thanks!

Massimiliano Cialdi

FIRMWARE ENGINEERING PROFESSIONAL LEADER

Powersoft S.p.A.

Via E. Conti, 5 - Scandicci (Fi) 50018 - Italy

OFFICE: +39 055 7350230