RSA certificates can't be parsed when CONFIG_MBEDTLS_USE_PSA_CRYPTO is enabled.

Dear Nordic-Team,

we are currently trying to add CSR creation to our project which worked quite fine by implementing it similar to the psa_crypto sample.

Unfortunately, this is now breaking our TLS communication, because after enabling MBEDTLS_USE_PSA_CRYPTO, the parsing of the CA certificate does no longer work.

It fails with error code -0x262e (MBEDTLS_ERR_X509_UNKNOWN_SIG_ALG):


The problem seems obvious, because during the build we even get warned, that MBEDTLS_RSA_C is being de-selected due to the dependency on !MBEDTLS_USE_PSA_CRYPTO


I've checked several other threads, but this issue seems not to be solved by those.
psa-tls-sample-rsa-certificates-not-supported is suggesting enabling the sample specific CONFIG_PSA_TLS_CERTIFICATE_TYPE_RSA which eventually uses CONFIG_MBEDTLS_RSA_C

nrf5340-ncs-2-8-cannot-get-tls-socket-to-load-ca-certif-due-to-net_sock_tls-mbedtls-error--0x262e is also reverting back to using CONFIG_MBEDTLS_RSA_C. The original poster is fine in the end, but another user is still complaining about the dependency issue between MBEDTLS_USE_PSA_CRYPTO and MBEDTLS_RSA_C. Eventually he refers to the next issue

nrf9160-offloaded-sockets-can-t-use-mbedtls_use_psa_crypto-with-rsa-certificates where basically the exact same problem is stated and here Susheel Nuguru explains that there are still dependencies between  CONFIG_MBEDTLS_RSA_C and CONFIG_MBEDTLS_LEGACY_CRYPTO_C. His suggestion is to use ECC signes certificates, but this is not always possible. He also teases that those dependencies might get resolved with future releases, which kind of indicates, that you are aware of this issue and currently working on it.

At this point my investigations did not yield any new insights, thats why I'm opening this ticket.

So to prevent an XY problem, here the key points that we want to achieve:

- We want to be able to have TLS communication with RSA signed certificates (pure ECC is not an option)

- We want to be able to be able to use cryptographic operations like generating keys and creating CSRs

- Wish: We do not want to rely on deprecated legacy APIs (like MBEDTLS_LEGACY_CRYPTO_C)

Questions:

1) Is there a way to configure our project to meet the expectations above?

2) Is there any ongoing work aiming to resolve all configuration dependencies related to the legacy APIs? Is there an expected release date for those changes?

To make the problem more accessible, I've create a sample based on the azure_iot_hub sample for the 7002DK.I added websockets, since those are also used within out project, aswell as a little more debug logs.
azure_iot_hub_crypto.zip

The sample.yml file supports two builds:

1) One without the crypto operations, where the CA cert parsing is working fine. 

west build -b nrf7002dk/nrf5340/cpuapp/ns . -T sample.net.azure_iot_hub_crypto.without_crypto

2) One with the crypto operations.

west build -b nrf7002dk/nrf5340/cpuapp/ns . -T sample.net.azure_iot_hub_crypto.with_crypto

Output 1)

Output 2)


Somehow MBEDTLS_SHA1_C is also not configured, thats why I patched the websocket.c file with this patch to use `psa_hash_compute()` instead of `mbedtls_sha1()`
Maybe you manage to enable SHA1, else you can try the patch.

websocket_sha1.patch


We are currently on NCS version 3.0.2.


I hope I could describe the problem detailed enough so that you can adequately provide some help.

If not, please feel free to ask for anything that could help.

Thank you very much in advance and have a great day!

Best regards

Jaro 

Parents
  • Hi, 

    RSA is, unfortunately, in a bit of flux in the Mbed TLS project. It is one of the last features to be added in PK and X.509 scope (ECDSA and ECDH were prioritized). 

    It seems like full RSA support using PSA crypto for PK and X.509 is only available with tf-psa-crypto which is currently in beta stage, waiting for an integration in Zephyr and NCS further down the line.

    I wonder if you need to rely on legacy crypto configurations for now (CONFIG_NORDIC_SECURITY_BACKEND instead of CONFIG_NRF_SECURITY). This would give the ability to enable legacy configurations like MBEDTLS_RSA_C. To enable MBEDTLS_RSA_C, the MBEDTLS_USE_PSA_CRYPTO dependency likely needs to be removed here https://github.com/nrfconnect/sdk-nrf/blob/9f562fbf9bd3052679c6a4f69aaee06c60199b12/subsys/nrf_security/Kconfig.legacy#L740

    -Amanda H.

  • I find this a bit weird since both active TLS standards (1.2 and 1.3) as well as HTTP/2 when used with TLS 1.2 require that, in order to claim compatibility/compliance, RSA is mandatory to support (i.e. a "MUST"), in the absence of an application profile standard specifying otherwise.

  • TLS 1.2 support with RSA certificates works with legacy crypto in Mbed TLS 3.6.x (MBEDTLS_USE_PSA_CRYPTO unset)

    TLS 1.3 support is only available with PSA crypto (MBEDTLS_USE_PSA_CRYPTO set)

     

    We unintentionally broke support for using both TLS 1.2 and TLS 1.3 with RSA certificates by requiring that MBEDTLS_RSA_C cannot be enabled when MBEDTLS_USE_PSA_CRYPTO is set.

  • Hi Amanda, 

    is there a possibility to make the known issues and the roadmap regarding the PSA_CRYPTO reworks that you are doing right now a bit more transparent ?


    For our specific issue, if it helps giving us specifically a (more optimistic) timeline, we intend to use ts-psa-crypto when it is all put together on our end. 

    We are working on this topic with like 6 engineers, multiple of them with 5+ years in the Nordic ecosystem and none of us feel comfortable navigating the crypto part of the sdk or its documentation for that matter.

    It is very frustrating to invest the time to learn the source sdks like mbed or psa only to find out that nordics vendor specific implementation breaks essential stuff, further compounded by the fact that a lot has to be cobbled together with samples of varying vintage.

    I will contact our sales rep for the possibility of a more in-depth response to our specific set of issues but I feel like similar topics have been brought up the dev zone multiple times recently, so I believe this deserves some publicly available clarity.

Reply
  • Hi Amanda, 

    is there a possibility to make the known issues and the roadmap regarding the PSA_CRYPTO reworks that you are doing right now a bit more transparent ?


    For our specific issue, if it helps giving us specifically a (more optimistic) timeline, we intend to use ts-psa-crypto when it is all put together on our end. 

    We are working on this topic with like 6 engineers, multiple of them with 5+ years in the Nordic ecosystem and none of us feel comfortable navigating the crypto part of the sdk or its documentation for that matter.

    It is very frustrating to invest the time to learn the source sdks like mbed or psa only to find out that nordics vendor specific implementation breaks essential stuff, further compounded by the fact that a lot has to be cobbled together with samples of varying vintage.

    I will contact our sales rep for the possibility of a more in-depth response to our specific set of issues but I feel like similar topics have been brought up the dev zone multiple times recently, so I believe this deserves some publicly available clarity.

Children
Related