Secure connection to AWS IoT over WiFi

RE: Secure connection to AWS IoT over WiFi

erichotterbeefcurry — Wed, 31 May 2023 15:11:46 GMT

Hi Johannes,

Ahh ok, I see, we are not in production stage yet so I agree with you that when we reach the stage a more secure method should be used. The AWS IoT fleet provisioning looks like something we can utilize too. We are definitely interested to see and learn how you've implemented this... it'd be great if you can check to see if it can be made public, and thank you for the detailed answer!

-Eric

RE: Secure connection to AWS IoT over WiFi

Johannes Hutter — Wed, 31 May 2023 06:53:43 GMT

Hey Eric,

yes, with TLS credentials I mean the client certificate, private key and CA certificate. For developing and getting started it makes totally sense to just compile in the files with CONFIG_AWS_IOT_PROVISION_CERTIFICATES, but since you have to have a separate set of cert/key for each device and you don't want to have your key as part of the unencrypted program, I wouldn't use this config in production.

We went with the AWS IoT fleet provisioning by claim (https://docs.aws.amazon.com/iot/latest/developerguide/provision-wo-cert.html) and provide the bootstrap credentials over a custom BLE GATT service. So basically during production, a provisioning device (a Raspberry Pi) connects over BLE to the product, sends WiFi credentials and a signed payload containing the bootstrap credentials. With those credentials we connect to AWS IoT and request the certificate/key and the thing registration (see https://aws.github.io/Fleet-Provisioning-for-AWS-IoT-embedded-sdk/v1.1.0/fleet_provisioning_design.html).

You could also pre-generate the things and credentials and just push them on the device during production, but in the end you always re-implement the fleet provisioning process again... So I guess it is a bit of a trade-off where you want to have the complexity during production.

Implementing this is a bit involved, since I had to touch the aws_iot library as well, but if there is interest, I can check whether we can make the implementation public

RE: Secure connection to AWS IoT over WiFi

erichotterbeefcurry — Tue, 30 May 2023 21:51:23 GMT

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

RE: Secure connection to AWS IoT over WiFi

Johannes Hutter — Tue, 30 May 2023 05:49:00 GMT

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

RE: Secure connection to AWS IoT over WiFi

erichotterbeefcurry — Mon, 29 May 2023 22:03:43 GMT

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!

RE: Secure connection to AWS IoT over WiFi

Einar Thorsrud — Fri, 21 Apr 2023 13:17:34 GMT

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.

RE: Secure connection to AWS IoT over WiFi

Johannes Hutter — Thu, 20 Apr 2023 16:41:06 GMT

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?

devzone.nordicsemi.com/.../kmu_5F00_sample.zip

RE: Secure connection to AWS IoT over WiFi

Einar Thorsrud — Fri, 14 Apr 2023 13:45:25 GMT

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.

RE: Secure connection to AWS IoT over WiFi

Johannes Hutter — Fri, 14 Apr 2023 13:19:03 GMT

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?

RE: Secure connection to AWS IoT over WiFi

Einar Thorsrud — Fri, 14 Apr 2023 13:12:35 GMT

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.

RE: Secure connection to AWS IoT over WiFi

Johannes Hutter — Thu, 13 Apr 2023 11:16:56 GMT

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.

RE: Secure connection to AWS IoT over WiFi

Einar Thorsrud — Tue, 11 Apr 2023 12:46:09 GMT

Hi,

[quote user=""]* How secure is the usage of the functionality provided in the nRF5340 compared to an external dedicated Hardware Security Module?[/quote]

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.

[quote user=""]* 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?[/quote]

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

[quote user=""]* How does the Nordic Security Module relate to TFM?[/quote]

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.