SES / DFU / Dependency confusion

[krbvroc1]

I continue to be confused by the Nordic setup of projects. There are a bunch of different demos, but what if you want to compile features from different ones?

Specifically, I have an existing Thread application based on the thread CLI. I now want to add DFU to that application. How in the world do I know which files need to be added to the project to support this?

It seems like black magic.

The Thread DFU demo has a ton of files organized in virtual folders such as..

nRF_micro-ecc

nRF_Crypto

nRF_Crypto backend nRF sw

nRF_Oberon_Crypto

nRF_DFU

nRF_IoT

nRF_Crypto backend Oberon

And lots of different libraries like libmbedtls, etc. How do I know which are needed? What is the Oberon stuff? I thought micro-ecc was the library required?

[Hung Bui]

Hi,

I'm sorry that we have some lack of detailed documentation on how to implement DFU feature in a thread application. 

For now the only documentation we have for this is the Thread Secure DFU protocol documentation and the DFU example documentation. 

You would need to look into the code, study and port that into your current application. 

Regarding the files needed, if you use the backend micro-ecc (used by default), you don't need to include Oberon crypto backend files, including both nRF_Crypto backend Oberon and nRF_Oberon_Crypto.

If you use Oberon crypto instead of micro-ecc you need to follow this guide.

This crypto library is needed for secure DFU bootloader where we check the signature and hash to verify the integrity and the origin of the image. 

libmbedtls needed in any thread projects, it's not related to the DFU but to openthread itself. 

[krbvroc1]

Thank you for the response. The SES project for Thread Secure DFU appears to include both micro-ecc and Oberon.

From the SDK 4.1.0 documentation it makes it sound like the micro-ecc MUST be used and MUST be compiled with an old armgcc compiler. Is this still accurate? Can I ditch micro-ecc altogether and use this new Oberon crypto ... I was trying to follow the Thread Secure DFU example and there is no mention of this. See infocenter.nordicsemi.com/.../thread_example_dfu.html

Are far as figuring out which files are need, I guess it is just trial and error / comparing emProject XML files? Is there any other way? And I need to manually compare the thousands of lines of sdk_config.h between projects to merge those in too?

[Hung Bui]

I'm afraid trial and error may be needed. 
If you plan to use Oberon, you just need to to follow the guide that I pointed to, quoted here: 

Porting from µECC to nrf_oberon
In sdk_config.h, set the following defines:
NRF_CRYPTO_BACKEND_MICRO_ECC_ENABLED to 0
NRF_CRYPTO_BACKEND_NRF_SW_ENABLED to 0
NRF_CRYPTO_BACKEND_OBERON_ENABLED to 1
NRF_CRYPTO_BACKEND_OBERON_ECC_SECP256R1_ENABLED to 1
NRF_CRYPTO_BACKEND_OBERON_HASH_SHA256_ENABLED to 1
The rest of NRF_CRYPTO_BACKEND_OBERON_* to 0
Remove these files from the build:
nrf_sw_backend_hash.c
micro_ecc_backend_ecc.c
micro_ecc_backend_ecdh.c
micro_ecc_backend_ecdsa.c
sha256.c
micro_ecc_lib_nrf52.a
Add these files to the build:
external\nrf_oberon\lib\nrf52\liboberon_2.0.4.a or external\nrf_oberon\lib\nrf52\oberon_short_wchar_2.0.4.lib
components\libraries\crypto\backend\oberon\oberon_backend_ecc.c
components\libraries\crypto\backend\oberon\oberon_backend_ecdsa.c
components\libraries\crypto\backend\oberon\oberon_backend_hash.c
Add these paths to the include paths:
external\nrf_oberon\include
external\nrf_cc310\include
In dfu_public_key.c:
Remove 'const' from the declaration of 'pk'.
In nrf_dfu_validation.c:
Add #include "nrf_crypto_shared.h"
Remove 'const' from the extern declaration of 'pk'.
Add function calls to swap the endianness of the public key and signature.
nrf_crypto_internal_double_swap_endian_in_place(pk, sizeof(pk) / 2);
,immediately before the call to nrf_crypto_ecc_public_key_from_raw(),
nrf_crypto_internal_double_swap_endian_in_place(m_signature, sizeof(m_signature) / 2); , immediately before the call to nrf_crypto_ecdsa_verify().
If necessary, move the start address of the bootloader to accomodate the increase in size. Typically 1 or 2 extra pages are needed (pages are 0x1000 long).

The draw back is that you would need to have larger flash space. 

I haven't tried to test on the Thread DFU example, but as far as I know there shouldn't be an issue switch to Oberon on this example.