Secure connection to AWS IoT over WiFi

[Johannes Hutter]

We are using nRF5340 and nRF7002 to build a WiFi connected device that integrates into our backend via AWS IoT Core. We are evaluating what the best way is to secure the private key for the TLS client authentication and whether we need an external Hardware Security Module for that or can support everything with the nRF5340 itself.

In general I see two possibilities to do the handshake:

1. Store the private key in a secure storage and have the TLS handshake executed in a secure environment

2. Generate a symmetric key in a secure environment and store it in a secure storage. Encrypt the private key with the symmetric key in the secure environment and store the encrypted private key on flash. Get the private key decrypted before connection and keep it only in memory, but never on flash in plain text.

The first one would obviously be desirable, because the key would never leave the secure environment after provisioning.

According to the docs, the nRF5340 is equipped with a KMU that could be used for securely storing keys and Cryptocell that could be used to perform the secure operations of signing, decrypting and encrypting and with TFM it should be possible to set up a secure environment.

So my questions are mainly:

* How secure is the usage of the functionality provided in the nRF5340 compared to an external dedicated Hardware Security Module?

* Is there a way (or even a sample) for the nRF5340+nRF7002 to transparently set up a client-authenticated TLS tunnel using a private key stored in the KMU?

* How does the Nordic Security Module relate to TFM?

Thanks already for the support!

[Einar Thorsrud]

Hi,

* How secure is the usage of the functionality provided in the nRF5340 compared to an external dedicated Hardware Security Module?

That depends on the module you are comparing with. The nRF5340 has a number of security features, like the KMU that can protect keys from being accessible from the CPU or debugger, and it has features that prevents code/data readout via a debugger etc. There are however security features you may find in other products that are not on the nRF5340, but what you need here is very application specific so it is up to you to specify your requirements / features you need, and then we can help to describe which of these exists and how they work in the nRF5340.

* Is there a way (or even a sample) for the nRF5340+nRF7002 to transparently set up a client-authenticated TLS tunnel using a private key stored in the KMU?

We do not have any solution for that at this point. (WiFi support is currently in an early stage and more features and examples will be added in the future).

* How does the Nordic Security Module relate to TFM?

The Nordic security module is a SW component that handles integration with various crypto libraries and APIs. An important point here is that regardless of the backends, the future proof API to use with regards to crypto is PSA Crytpo, which is what is used in the crypto examples in the SDK. TF-M implements a secure processing environment. Typically, secrets will be handled by TF-M, and other parts of the application will then be non-secure and not have access to certain data (liek keys) and hardware. See An Introduction to Trusted Firmware-M (TF-M). You can also see more in the Security chapter in the SDK documentation.

[Johannes Hutter]

Hi Einar,

thanks for the response! I think I start to get an understanding of the separation and capabilities. For us it would then make sense to use the TF-M to protect the bootchain, securely de- and encrypt the private key for the client authentication certificate and protect the WiFi credentials.

To get the TF-M image included and get familiar with the functionality, I want to combine the samples under wifi/provisioning and crypto/aes_cbc. For that I added following configs to the prj.conf in wifi/provisioning: 

CONFIG_BUILD_WITH_TFM=y
CONFIG_TFM_PROFILE_TYPE_NOT_SET=y

CONFIG_NRF_SECURITY=y
CONFIG_MBEDTLS_PSA_CRYPTO_C=y

CONFIG_MBEDTLS_ENABLE_HEAP=y
CONFIG_MBEDTLS_HEAP_SIZE=8192
CONFIG_PSA_CRYPTO_DRIVER_OBERON=n
CONFIG_PSA_CRYPTO_DRIVER_CC3XX=y

and changed following configs (due to RAM limitations):

CONFIG_NET_BUF_RX_COUNT=8
CONFIG_NET_BUF_TX_COUNT=8
CONFIG_HEAP_MEM_POOL_SIZE=76800

Unfortunately, the build doesn't work because of undefined references to those two functions:

mbedtls_entropy_init()

mbedtls_hardware_poll()

It seems to me that wpa_supplicant needs the entropy source which is provided by mbedtls, but including the nrf security backend does not provide an implementation when enabled I played around a lot with the various entropy configs, but can't figure out how to include the correct combination. Can you help there?

board target is nrf7002dk_nrf5340_cpuapp_ns, NCS version is v2.3.0

On the main branch it also doesn't work. There the Kconfig resolution already fails.

[Einar Thorsrud]

Hi,

It turns out that TF-M and Wi-Fi is unfortunately not supported at the moment. I have discussed with the team and we have a ticket for it, so this will come, but I do not have a time-frame for it.

[Johannes Hutter]

Ouh, that's a pity! Just to be clear: It is also not possible to let WiFi use the "non-secure" crypto and have the TF-M for other crypto operations? It is simply not possible to use TF-M and WiFi in the same build currently?

[Einar Thorsrud]

I cannot say it is not possible, it is just that we have not worked on it yet and I am not able to say what is needed in order to support it.

[Johannes Hutter]

Sorry that I keep being persistent here, but it is unfortunately quite frustrating to make progress on this topic and probably I am just missing something...

What is the expected way to get a basic level of securing secrets with a product based on nRF7002 + nRF5340?

I understand that TF-M is not supported (and the necessary image size seems to limit everything but toy samples anyway). It is also not possible to use the PSA APIs, since the WPA supplicant depends on the legacy security backend being enabled, which prevents for example importing keys to the CC312 via PSA APIs ( RE: PSA crypto features not enabled when CONFIG_MBEDTLS_LEGACY_CRYPTO_C is enabled).

So I am left with using the legacy APIs and the lower-level mbedTLS integration (https://developer.nordicsemi.com/nRF_Connect_SDK/doc/latest/nrfxlib/crypto/README.html)

My plan was then to provision a hardware unique key via the library, derive an AES key from there and store it in the KMU. Secrets would then be stored on flash after being encrypted in the CC and decrypted and loaded into RAM when needed. Something similar to this sample implementation: https://github.com/einarthorsrud/kmu_sample. However, it seems like the inclusion of the alternative implementations does not work as expected, since the mbedtls_aes_encrypt and mbedtls_aes_decrypt functions are not available.

Is there any recommended way on how to manage secrets like private keys or WiFi credentials?

kmu_sample.zip

[Einar Thorsrud]

Hi,

I don't think you can say TF-M is limited to toy samples. It is large yes, but we are working on optimizing the size. And it is the only method we support for isolation / security by separation, implementing a Secure Processing Environment (SPE) (see An Introduction to Trusted Firmware-M (TF-M)). I will be what we support going forward, together with the PSA crypto API's. And when it comes to key management etc that you ask about, we do not have any other future proof solutions than TF-M to suggest.

Regarding the unofficial KMU sample you found, that is a simple unofficial sample that I wrote a long time ago (for nRF Connect SDK 1.4) to show basic KMU functionality, but it is not something I would recommend today.

Our Wi-Fi support is still not mature, and not all features are in place yet, but I have discussed this with the relevant teams internally and they are working on it. So unless this is something you need to handle early and you need something fast, I would wait. As you have seen, there is some work needed to get the crypto library dependencies sorted out, and we are working on it, but we do not have anything yet. If you need this urgently, I will update here when we have something so that you don't necessarily have to wait for a new SDK release.