How to integrate MBEDTLS for nrf9160 and native simulation on sdk 2.6?

[Cla]

Dear Support Team

My goal is to build an application for two targets. The targets are an nrf9160 and a simulation target for running it natively on Linux (currently trying native_sim).

The application makes use of the mbedtls-API. For example the `mbedtls_x509...`, `mbedtls_ecp` etc...

To build it for the nrf9160 it works fine now with the following config:

```
CONFIG_MBEDTLS_TLS_LIBRARY=y
CONFIG_MBEDTLS_PK_WRITE_C=y
CONFIG_MBEDTLS_ECP_C=y
CONFIG_MBEDTLS_DHM_C=y
CONFIG_MBEDTLS_X509_CREATE_C=y
CONFIG_MBEDTLS_X509_CSR_WRITE_C=y
CONFIG_MBEDTLS_X509_CRT_PARSE_C=y
CONFIG_MBEDTLS_X509_LIBRARY=y
CONFIG_MBEDTLS_X509_USE_C=y
CONFIG_MBEDTLS_ENABLE_HEAP=y
CONFIG_MBEDTLS_HEAP_SIZE=59000
CONFIG_MBEDTLS_SSL_SERVER_NAME_INDICATION=y
CONFIG_MBEDTLS_PKCS1_V15=y
CONFIG_MBEDTLS_RSA_C=y
CONFIG_MBEDTLS_CMAC_C=n
CONFIG_MBEDTLS_PSA_CRYPTO_C=y
CONFIG_MBEDTLS_GCM_C=y
CONFIG_MBEDTLS_SSL_OUT_CONTENT_LEN=16384
CONFIG_MBEDTLS_SSL_IN_CONTENT_LEN=16384
CONFIG_MBEDTLS_SHA384_C=n
CONFIG_MBEDTLS_SHA512_C=n
CONFIG_MBEDTLS_CIPHER_MODE_XTS=n
CONFIG_MBEDTLS_CIPHER_MODE_CBC=n
CONFIG_MBEDTLS_CIPHER_MODE_CTR=y
CONFIG_MBEDTLS_CHACHA20_C=n
CONFIG_MBEDTLS_ECDSA_DETERMINISTIC=n
CONFIG_MBEDTLS_SSL_SRV_C=n
CONFIG_MBEDTLS_ECDH_C=n
CONFIG_MBEDTLS_PKCS1_V21=n
CONFIG_MBEDTLS_CCM_C=n
CONFIG_MBEDTLS_POLY1305_C=n
CONFIG_MBEDTLS_HKDF_C=n

```

Furthermore, we had to modify the `modules/mbedtls/configs/config-tls-generic.h`-file slightly with some hardcoded `defines`.

But I am struggling to build it for native_sim. The problem is, that I can not enable the respective Kconfigs. For example:

```

warning: MBEDTLS_X509_LIBRARY (defined at /opt/zephyrproject/nrf/modules/trusted-
firmware-m/Kconfig.mbedtls_minimal.defconfig:32,
/opt/zephyrproject/nrf/subsys/nrf_security/Kconfig.tls:7) was assigned the value 'y' but got the
value 'n'. Check these unsatisfied dependencies: (TFM_PROFILE_TYPE_MINIMAL || NRF_SECURITY) (=n).

```

Furthermore, I have observed the following:

The library can be included via the `nrf-sdk`-west.yml or via `sdk-zephyr`-west.yml. Both of those will pull in a different state it seems:

• https://github.com/nrfconnect/sdk-nrf/blob/v2.6-branch/west.yml#L138 pulls in mbedtls at revision v3.5.2-ncs1 and zephyr at v3.5.99-ncs1
• zephyr at v3.5.99-ncs1 https://github.com/nrfconnect/sdk-zephyr/blob/v3.5.99-ncs1-branch/west.yml#L279 pulls again in mbedtls at revision 66ed2279d6222056af172c188eaf4dcfed481032
• They will overwrite each other at path `modules/crypto/mbedtls` if both are included?

Both refer to the mbedtls fork here: https://github.com/nrfconnect/sdk-mbedtls

But then there is also upstream mbedtls, that is pulled in by upstream zephyr, that seems to offer different options then the `sdk-mbedtls`-fork, like `CONFIG_MBEDTLS_BUILTIN`: https://github.com/zephyrproject-rtos/mbedtls

This confuses me a bit. And I can summarize my questions this way:

• Which mbedtls-version to use with `sdk-2.6` (sdk vs upsteam, revision v3.5.2-ncs1 vs revision 66ed2279d6222056af172c188eaf4dcfed481032) ?
• Which way do you recommend to configure MBEDTLS to achieve the goal described above? Could we use `CONFIG_MBEDTLS_CFG_FILE` instead?
• How can we do all this, while ensuring, that hardware-crypto-acceleration is used when building for the nrf9160?

Thanks in advance and let me know, if you need additional information.

[Sigurd Hellesvik]

Right.

Then the next question is:  Why would NRF_SECURITY not work on native_sim?
The easy answer is likely "Because we have not put effort into supporting this".

But maybe before that: Do you use the cryptocell hardware for your crypto on the nRF9160? If so, I also doubt that the native_sim supports that. Using software implementations of  cypto on the other hand in theory should not be an issue I guess.

This was not very coherent, but  I hope that it made some sense?

[Cla]

It did, thanks. Just to be clear, we do not use NRF_SECURITY for the nrf9160 either.

My thinking was to use MBEDTLS-APIs.

Then when building for nrf9160 it would be forwarded to PSA_CRYPTO (which my understanding is, that is currently happending via the `_ALT` implementations), PSA_CRYPTO then uses the cryptocell hardware internally.

Then when building for native_sim it would use software implementations for the same functions of MBEDTLS.

This would have been my thinking. I do not know, if this is possible or, whether there is a better solution to achieve my goal. I try to also communicate my goal (X = build for nrf9160 and native_sim) and not just my current approach (Y = build MBEDTLS for native_sim) as not to cause the XY-communication problem.

I hope I could clearify my thinking.

[Sigurd Hellesvik]

I am missing one part:

Cla said:

Just to be clear, we do not use NRF_SECURITY for the nrf9160 either.

What are you doing on the nRF9160 from before?

[Cla]

We use `BUILD_WITH_TFM` (Not profile minimal though).

[Sigurd Hellesvik]

I am honestly a bit new to the whole testing stuff.

So to learn, I have talked with a colleguea who knows more than me, and I think the first question to ask is:

What exactly do you want to test?
Is this a unit test or an integration test?