NRF_CRYPTO_BACKEND_CC310_BL breaks Thread Joiner

[Rob C]

Edited:  It appears any use of NRF_CRYPTO_BACKEND_CC310_BL breaks joining.

Environment:  nRF52840; SES; nRF5_SDK_for_Thread_and_Zigbee_v4.0.0_dc7186b

I am implementing Thread DFU on nRF52840 and would like to use CC310 hardware crypto wherever possible.  I understand the OpenThread stack for nRF52840 also uses the CC310 backend, especially for Joining.

I found that if I enable (in sdk_config.h):

NRF_CRYPTO_BACKEND_CC310_BL_ENABLED,

NRF_CRYPTO_BACKEND_CC310_BL_HASH_SHA256R1_ENABLED, and

NRF_CRYPTO_BACKEND_CC310_BL_ECC_SECP256R1_ENABLED

the device is unable to complete the Joiner (Commissioning) process successfully.  Join attempts timeout.

I notice that the example 'thread_secure_dfu_client_pca10056' uses micro_ecc for SECP256K1 and nrf_sw_hash for SHA-256.  I had previously assumed this was to be compatible with the devices that lack a CC310, but now I am starting to wonder.

Are there any restrictions on *application* use of the CC310_BL or CC310 backends for projects using the OpenThread library?

Thanks,
Rob

[Jørgen Holmefjord]

Hi,

I think this will depend on how you try to use the CC310 CRYPTOCELL HW. I'm assuming that the OpenThread stack assumes that it can access this peripheral at any time and that it is not used by other resources. If you use it in the application when the stack needs it, it may be in the wrong state or return errors. The CC310_BL backend is a minimal implementation of the backend, intended for the bootloader. The OpenThread stack uses the same libraries from the SDK, enabling other backends in your application, while the CC310 backend is used in the OpenThread stack, may cause it to misbehave or become wrongly configured.

The best option is probably to not use the cryptocell in the application, but if you post some more details on what you are doing, and code snippets, I can try to test it out or check with our developers about the feasibility of what you want to do.

Best regards,
Jørgen

[Rob C]

Hi Jorgen,

So my immediate application is for adding Thread DFU (ideally using CC310 for minimum code size, maximum speed).  So the test case is as follows:

1. Start with project:  Nordic_Dev\nRF5_SDK_for_Thread_and_Zigbee_v4.0.0_dc7186b\examples\thread\dfu\client
2. Build and run the DFU client on PCA10056 (Board 1)
3. Program a second PCA10056 with CLI (Board 2)
4. Form a network using Board 2 and start a wildcard commissioner using CLI commands
5. Join Board 1 to the network using CLI commands (Joining succeeds using micro_ecc for SECP256K1 and nrf_sw_hash for SHA-256)
6. Edit the DFU client project's sdk_config.h follows:
   1. #define NRF_CRYPTO_BACKEND_MICRO_ECC_ENABLED 0
   2. #define NRF_CRYPTO_BACKEND_NRF_SW_ENABLED 0

   3. #define NRF_CRYPTO_BACKEND_CC310_BL_ENABLED 1

   4. #define NRF_CRYPTO_BACKEND_CC310_BL_HASH_SHA256R1_ENABLED 1

   5. #define NRF_CRYPTO_BACKEND_CC310_BL_ECC_SECP256R1_ENABLED 1

7. Build and run the DFU client on Board 1
8. Attempt to join Board 1 to the network (Joining fails when CC310_BL is used instead)

With the code above, I don't think the Application should be *actively* using the CC310 during the joining process, but the crypto needed for DFU will be initialized at boot nonetheless.  The validation step (actively using the CC310) shouldn't occur until after Board 1 gets connected to the Thread Network and the Thread State change handler triggers it.

The reason I am interested is that I would like to use end-to-end application-level payload encryption and using the CC310. This would probably involve changing from the CC310_BL to a full CC310 backend, and I should be able to select a crypto backend that isn't being used by Thread, if that helps.  However, I'm not clear on which backends the OpenThread stack is actually using -- the file at https://github.com/openthread/openthread/blob/b4c5bd5044a5363eca382785e90fd894531c721b/third_party/NordicSemiconductor/config/nrf52840/config/sdk_config.h doesn't appear to enable any backends, so I must be missing something.

Thanks for any advice you're able to provide.

Rob