Bootloader build with ECDSA256 (nRF52832, SDK 16.0.0, S132 v7.0.1)

[RVM]

I want to bring up a secure bootloader with support for ECDSA and SHA-256.

I am having a hard time coming up with a combination of SDK components (frontend, backend), external libraries, and preprocessor symbol definitions in the sdk_config.h file.

I am a novice when it comes to security and am somewhat clueless as to what is needed to create such a firmware design.

I have been able to 'compile' the uECC source code with the GCC ARM compiler of my choice.

The first issue I ran into was that I need to set up a 'frontend' and a 'backend'.

1. In this regard I am not sure what role is played by the external uECC library that I built with GCC ARM.

2.I was able to recreate the build used by the secure_bootloader example but over time I am beginning to get the feeling that the configuration out of the box does not support ECDSA-256 (?)

3. I found out, after navigating through many web pages and spending quite a few hours, that the 310 backend is NOT supported on the nRF52832. Now I don't know what is ACTUALLY supported on the nRF52832 -- should Iuse uECC or should I use OBERON or 'nrf sw implementation/?

I have been playing with the various options and some builds do complete with no errors but there are warnings that I am not comfortable about ignoring.
An example is when I tried to enable the OBERON backend --
  If I enable all the same flags in the basic crypto example I get this warning (even though the build succeeds)
        #warning "NRF_CRYPTO_CURVE25519_BIG_ENDIAN_ENABLED not defined. Please define it to choose the endianness of Curve25519 parameters."

If I do not define the Curve25519 specific parameters then I get this warning:
        #warning NRF_CRYPTO_BACKEND_CC310_BL_HASH_SHA256_ENABLED define not found in sdk_config.h (Is the sdk_config.h valid?)

Basically I think I am just going through a lot of trial and error without any clear idea of how to approach this problem.

Any input would be appreciated.

Cheers

RMV

[RVM]

Thanks Einar.

As for

Einar Thorsrud said:

If I do not define the Curve25519 specific parameters then I get this warning:
        #warning NRF_CRYPTO_BACKEND_CC310_BL_HASH_SHA256_ENABLED define not found in sdk_config.h (Is the sdk_config.h valid?)

Again, I suspect you have a problem with your sdk_config.h. You should copy the whole nrf_crypto section of a valid sdk_config.h and adapt to your needs. That means not deleting anything, but just toggling features off or on by settings the definitions to 0 or 1 as explained here. That way you should not get any of these warnings.

I think that 'not defining' a variable should be treated as setting it to '0'.
I did get this warning to go away by explicitly setting it to '0' without setting ANY OTHER RELATED macros explicitly -- and that was my issue.
I think this should be changed -- I never wanted to use the 310 so I did not expect to define ANY 310 macros.

Cheers
RMV

[Einar Thorsrud]

Hi RMV,

RVM said:

I think that 'not defining' a variable should be treated as setting it to '0'.

yes, and that is generally the case. But for some special cases there are checks in the code to make sure this is something you have considered properly. Like here, and also  in case of NRF_CRYPTO_CURVE25519_BIG_ENDIAN_ENABLED as that configuration macro was added after SDK 15.0.0, and the intention in that case was to help users handle the API change instead of risking they suddenly getting unexpected behavior (due to endianness change between SDK versions).

RVM said:

I did get this warning to go away by explicitly setting it to '0' without setting ANY OTHER RELATED macros explicitly -- and that was my issue.

Yes, of course.

RVM said:

I think this should be changed -- I never wanted to use the 310 so I did not expect to define ANY 310 macros.

This will not be changed. The nrf_crypto API has had this way of configuring everything via sdk_config.h since it was introduced, and while I agree it gives a long sdk_config.h and a lot of macros, the end result seems to be working well. A lot of flexibility and no additional complexity runtime (saving CPU time and power).

Einar