Hi Hippolyte,
The TLS stack only supports consuming keys in a secure element, allowing
long-term secrets to be kept at the highest security level on your
platform. The session keys that are created internally during the key
exchange are always transparent keys. Since the premaster secret is
stored in the session data, it is not possible to keep the per-session
secrets entirely within the PSA secure world or a secure element anyway.
Even if there is no security advantage in terms of direct exposure of
secrets, you may want to benefit from the improved performance or
side-channel resistance of the secure element. For that, you'll need to
use an accelerator driver, not a secure element driver. This is not
supported for key agreement in Mbed TLS 2.x, you would need to upgrade
to 3.5 (soon 3.6).
In any case, I strongly recommend upgrading to the latest 2.28.x or 3.x
release since we have fixed several security issues, some of which might
affect you. Drivers should work without changes in 2.28. Dynamic secure
element drivers (MBEDTLS_PSA_CRYPTO_SE_C) are deprecated in 3.x but
should still work without changes.
Best regards,
--
Gilles Peskine
Mbed TLS developer
On 01/03/2024 11:16, hippolyte.einfalt--- via mbed-tls wrote:
> Greetings,
>
> ## The Setup
>
> Greetings,
>
> ## The Setup
>
> I have a RENESAS board that has an integrated crypto processor and uses MbedTLS 2.25.0.
> I have a SE (secure element) connected to it.
>
> I am allowing hardware acceleration and PSA crypto API inside mbedtls_config.h
>
> I registered my SE driver before calling psa_crypto_init().
>
> The board connects to a web server and performs TLS handshake with the forced cipher `MBEDTLS_TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256`.
>
> ## The issue
>
> The handshake fails during the step 8 when generating EC private key for ECDHE exchange.
> I have tracked the issue through debug and it unfolded as follows inside `ssl_write_client_key_exchange()`:
>
> - We enter the PSA crypto code from the pre-processor directives.
> - We set the key attributes after initializing them to 0. (here usage_flags, algorithm, type and bits field are set but lifetime is still 0 from init at this point, this will count later on)
> - The next function `psa_generate_key()` fails.
>
> ## In depth
>
> When inside the `psa_generate_key()` function, we start the key creation inside `psa_start_key_creation()`.
> But here, when validating the attributes of the key in `psa_validate_key_attributes()`, we are not able to rely on the SE to store the key due to it being volatile (lifetime is still 0), the driver is never called.
>
> From there the program keeps going until trying to generate the key with the crypto processor from the board which does not support this type of key and returns unsupported error.
>
> ## Main question
>
> Since the lifetime is forced to be representing a volatile key and since the driver for the SE is not called except for persistent ones, i cannot do this cryptographic step using the SE. Is the generation of the volatile key at this step meant to be handled by the MbedTLS library (software or hardware alt) and not by the PSA Crypto API (SE) due to the key being volatile ? If not, how is the Se supposed to be called in the handshake and what am i missing ?
>
> ## Discussion
>
> I can pass the handshake when disabling hardware acceleration and using the software for cryptographic steps, but in this case i am not using the SE for them. Should the SE only be used to store the client certificate for mTLS case ?
>
> ## Note
>
> I must use the MbedTLS version 2.25.0 since the SE driver I am using relies on this version.
