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!

[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.

[erichotterbeefcurry]

Hi Johannes, I am working on integrating nrf7002 to my team's backend via AWS IoT Core too. I'm using a nRF7002DK and it's been hard to setup the net/aws_iot library because all examples I can find are nrf9160s using modems. Can I ask if the aws_iot library is what you used to set up the connection with AWS, and if it not, could you please give some guidance on how I should get the nrf7002 connected to AWS? Thank you so much, and I hope you have found a great solution for the problem you described in this post!

[Johannes Hutter]

Hey!

Yes, I used the net/aws_iot library for the connection. Some of the pitfalls I had to debug the most probably are:

• Disable CONFIG_POSIX_API, but enable CONFIG_NET_SOCKETS_POSIX_NAMES
• Enable CONFIG_NET_SOCKETS_SOCKOPT_TLS and CONFIG_TLS_CREDENTIALS and set your credentials with tls_credential_add(CONFIG_AWS_IOT_SEC_TAG, TLS_CREDENTIAL_CA_CERTIFICATE, AWS_CA_CERT, sizeof(AWS_CA_CERT)) etc.
• Make sure your certificates and keys are in the right format (single null-terminated string, in PEM format with line feeds at the end of a line).
• Enable CONFIG_MQTT_CLEAN_SESSION to get the subscriptions enabled
• You cannot dynamically subscribe after connection with the library, so you have to set the number of subscriptions you want to have exactly and make sure you have the policy permissions to subscribe to them.
• I had to increase the number of posix file descriptors (CONFIG_POSIX_MAX_FDS) and disable the send timeout (CONFIG_AWS_IOT_SEND_TIMEOUT)

I went with storing the secrets encrypted on the flash and accepting them being plain text while in memory.

If you have any specific question, let me know, maybe I can help

[erichotterbeefcurry]

Hi Johannes, thank you so much for replying! I followed your suggestions and the library is building&flashing to the board now! The only part I didn't do was the TLS credentials, I wasn't how the secrets (do you mean the aws private key here?) can be flashed, could you elaborate a bit more on how you provision the certificates onto nrf7002? It seems if I use the CONFIG_AWS_IOT_PROVISION_CERTIFICATES option, it will make the function calls to tls_add_credentials too... Other than that, things look great and I am moving forward with the aws_iot library in our program. Thanks so much again for replying, your answer really helped!

-Eric