• State Suggested Answer
  • Replies 8 replies
  • Answers 1 answer
  • Subscribers 88 subscribers
  • Views 2332 views
  • Users 0 members are here
Attachments (0)
Nordic Case Info
  • Case ID: 263543
Options
This post is older than 2 years and might not be relevant anymore
More Info: Consider searching for newer posts

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

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

Reply
  • 0
    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

Children
  • 0 in reply to RVM

    Hi RMV, 

    RVM said:
    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?

    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

Related