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

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

RVM — Tue, 26 Jan 2021 17:25:36 GMT

Hi Einar,

I don't think I quite agree with all the arrangements but I will mark this as answered so this ticket can be closed.

Cheers

RMV

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

Einar Thorsrud — Tue, 26 Jan 2021 09:10:41 GMT

Hi RMV,

[quote user="RMV"]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?[/quote]

micro-ecc will do the elliptic curve cryptography, but no the hashing. I recommend you just refer to a example bootloader project for the nRF52832. Then you will see that in addition to the micro-ecc backend, NRF_CRYPTO_BACKEND_NRF_SW_ENABLED is set to 1 and NRF_CRYPTO_BACKEND_NRF_SW_HASH_SHA256_ENABLED is set to 1. That provides the SHA256 support that you are currently missing.

Einar

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

Einar Thorsrud — Tue, 26 Jan 2021 09:06:03 GMT

Hi RMV,

[quote user="RMV"]The problem is that I never seem to get a clean build with NO WARNINGS in the build output.[/quote]

I am not sure why that causes (if you need assistance on that please provide more information or code). But as explained before, the SDK bootloader example works with ECDSA_P256_SHA256 boot validation out of the box, and the example bootloader builds without any warnings or errors. So you need to look into your changes.

[quote user="RMV"]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[/quote]

Not sure about that, I would say you should always make your code warning free. If not, you risk tuning your mind to ignoring warnings that actually matter, and then you will regret going down that path in the first place 🙂

Einar

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

Einar Thorsrud — Tue, 26 Jan 2021 09:00:18 GMT

Hi RMV,

[quote user="RMV"]I think that 'not defining' a variable should be treated as setting it to '0'.[/quote]

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

[quote user="RMV"]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.[/quote]

Yes, of course.

[quote user="RMV"]I think this should be changed -- I never wanted to use the 310 so I did not expect to define ANY 310 macros.[/quote]

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

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

RVM — Mon, 25 Jan 2021 18:10:28 GMT

[quote userid="7377" url="~/f/nordic-q-a/70847/bootloader-build-with-ecdsa256-nrf52832-sdk-16-0-0-s132-v7-0-1/291038#291038"]

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.

[/quote]

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

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

RVM — Mon, 25 Jan 2021 17:39:46 GMT

[quote userid="7377" url="~/f/nordic-q-a/70847/bootloader-build-with-ecdsa256-nrf52832-sdk-16-0-0-s132-v7-0-1/291038#291038"]

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.

[/quote]

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

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

RVM — Mon, 25 Jan 2021 17:35:49 GMT

Thanks Einar.

As for

[quote userid="7377" url="~/f/nordic-q-a/70847/bootloader-build-with-ecdsa256-nrf52832-sdk-16-0-0-s132-v7-0-1/291038#291038"]

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.

[/quote]

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

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

Einar Thorsrud — Mon, 25 Jan 2021 13:13:51 GMT

Hi RMV,

[quote user=""]The first issue I ran into was that I need to set up a 'frontend' and a 'backend'.[/quote]

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.

[quote user=""]1. In this regard I am not sure what role is played by the external uECC library that I built with GCC ARM.[/quote]

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.

[quote user=""]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 (?)[/quote]

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.

[quote user=""]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/?[/quote]

[quote user=""]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."[/quote]

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

[quote user=""]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?)[/quote]