MbedTLS (2.25.0) TLS handshake on FreeRTOS - PSA Crypto enabled (SE) but not used during client step 8
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.
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,
Hi Gilles,
Thanks a lot for the detailed response !
Best Regards, Hippolyte.
Gilles Peskine wrote:
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).
So even if i write an accelerator driver it wont be used inside the handshake for my current version of MbedTLS ? Sorry if i do not directly get it, but if it is true, does it mean I cannot currently fully use the SE capabilities with my version ?
I know that my SE manufacturer is upgrading their driver to latest MBedTLS version, should I wait for them to release it ?
Thanks again,
Hippolyte.
On 04/03/2024 11:06, hippolyte.einfalt--- via mbed-tls wrote:
Gilles Peskine wrote:
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).
So even if i write an accelerator driver it wont be used inside the handshake for my current version of MbedTLS ? Sorry if i do not directly get it, but if it is true, does it mean I cannot currently fully use the SE capabilities with my version ?
I'm afraid so. In Mbed TLS 2.25 and even in 2.28, for the key agreement, the TLS code can only call mbedtls_ecdh_xxx() or mbedtls_dhm_xxx() or psa_raw_key_agreement(), and psa_raw_key_agreement can only call mbedtls_ecdh_xxx(). I don't think the TLS layer has a way to offload the key agreement (it can offload the signature, but PSA supports drivers for that), and we only added driver support for PSA key agreement in 3.something.
Best regards,
mbed-tls@lists.trustedfirmware.org
-
Gilles Peskine -
hippolyte.einfalt＠viveris.fr