This post is older than 2 years and might not be relevant anymore
More Info: Consider searching for newer posts

NRF_CRYPTO_BACKEND_CC310_BL breaks Thread Joiner

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

Parents
  • 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

  • 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

  • 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

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

  • I'm facing similar problem atm. After adding DFU support to my project (thus microecc which is apparently required to build DFU) joining started to fail with [Security] as the reason.

    I understand this is not strictly related to the main problem signaled in this thread, but I'm curious whether you were able to get to the bottom of this?

  • Found the problem. Memory manager config from thread DFU sdk_config.h defines too small block counts. Once I adapted MEMORY_MANAGER_*_BLOCK_COUNT and MEMORY_MANAGER_*_BLOCK_SIZE settings from my other thread projects it started to work as expected - joiner works like a charm.

Reply Children
No Data
Related