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

[Jørgen Holmefjord]

Hi,

Sorry about the slow response on this. I have some issues with following your instructions. I get the error "Join failed [Security]" from CLI when trying to perform the commissioning.

The OpenThread libraries use the cryptographic functions through mbedtls, see the documentation in Mandatory Mbed TLS library.

I will check with our developers if there is any way to use the CC310 by the application, while it is also used by the protocol stack.

Best regards,
Jørgen

[Rob C]

Jorgen,

Please clarify:  In what step of my instructions did you encounter "Join failed [Security]" -- Step 5 (unmodified examples) or Step 8 (CC310 used by application)?  As I currently understand it, you were able to reproduce the problem -- please confirm.

Yes, I understand that OT used the CC310 through mbedtls.  It is my understanding that the crypto needed for Thread commissioning is pretty intense, and may not work within a reasonable delay unless the CC310 is used.  As I recall this is a key strength of the nRF52840 compared to, say, TI's chips, which may only have software-based crypto.  

Thanks,
Rob

[Jørgen Holmefjord]

I encountered the error in Step 5, so I was not able to proceed and reproduce the problem with the nrf_crypto CC310_BL backend enabled. Is this the same error you encountered in Step 8?

You are correct that the cryptographic procedures will take significantly longer without the cryptocell. We did have some benchmark numbers for this in some previous SDK version documentation.