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

[Einar Thorsrud]

Hi RMV,

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

The nrf_crypto library provide a unified API for a number of different crypto libraries. If you use an SDK example you generally have all libraries included in the project and just need to select the desired backend in sdk_config.h See Configuring nrf_crypto frontend and backends.

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

micro-ecc is one of the supported backend for nrf_crypto. If you enable the micro-ecc backend for the specific algorithm you use, then this backend will be used for that algorithm.

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 (?)

Why do you get that feeling? The SDK bootloader support using ECDSA_P256_SHA256 boot validation of the application out of the box as explained in this thread.

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/?

CC310 / CryptoCell is a HW peripheral in the nRF52840. It is not available in any other nRF52 series devices. However, all the other nrf_crypto backends are SW libraries that can be used on any nRF52 device. In the bootloader it makes most sense to use micro-ecc as it seems you are allready doing, as that has a small footprint.

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

Have you migrated from an earlier SDK version, or is there another reason your sdk_config.h is not valid out of the box? In any case, you can fix this by defining NRF_CRYPTO_CURVE25519_BIG_ENDIAN_ENABLED to 0 or 1 as you can see done in many example sdk_config.h files in the SDK. Note that it will not have any practical implications though, unless you actually use that curve (though I fully agree that you should make your code build without any warnings).

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.

[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

[RVM]

Einar Thorsrud said:

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 (?)

Why do you get that feeling? The SDK bootloader support using ECDSA_P256_SHA256 boot validation of the application out of the box as explained in this thread.

Hi Einar

That thread is also something that I created based on shared experiences with the same project I am trying to bring up.
The problem is that I never seem to get a clean build with NO WARNINGS in the build output.
I have now been made aware that one of the warnings I see can  and should be ignored so maybe I should not be so paranoic about it

Cheers
RMV

[RVM]

Einar Thorsrud said:

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/?

CC310 / CryptoCell is a HW peripheral in the nRF52840. It is not available in any other nRF52 series devices. However, all the other nrf_crypto backends are SW libraries that can be used on any nRF52 device. In the bootloader it makes most sense to use micro-ecc as it seems you are allready doing, as that has a small footprint.

If I try to stick with just the micro-ecc I get this linker error: "nrf_dfu_validation.c:(.text.nrf_dfu_validation_signature_check+0x3e): undefined reference to `nrf_crypto_hash_calculate'"

I see that it is defined in the file nrf_crypto_hash.c but the code is not compiled because this macro is evaluting to a '0'
#if NRF_MODULE_ENABLED(NRF_CRYPTO_HASH)

It looks like this symbol is defined in one of these backends (cc310, cc310_bl, mbedtls, nrf_sw, oberon) but I do not see this symbol being defined in the micro-ecc. How then does one use the micro-ecc for the backend?

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