Beware that this post is related to an SDK in maintenance mode
More Info: Consider nRF Connect SDK for new designs
This post is older than 2 years and might not be relevant anymore
More Info: Consider searching for newer posts

Signature on BL updated by DFU

There doesn't seem to be any validation of the image when updating the bootloader by secure DFU. nrfutil has no switch to generate any crc or ecdsa_signature. The code uses VALIDATE_CRC, but the expected value is calculated on the received image in boot_validate_extract, so when this is later verified in nrf_dfu_validation_boot_validate the result is always success.

There is also a bug in postvalidate_sd_bl causing the boot validation of BL to always fail for a combined SD+BL image. The second call to boot_validation_extract should have index=1 if there was also a SD in the image.

I'm using nRf52832 with SDK 15.3.0.

Best Regards

Sven

  • Please don't close this issue yet.

    I ran into this same exact problem, where if I try to update the SD + BL at the same time the call to "boot_validation_extract" passes for SD but fails for BL. This is because as pointed out, the code is looking at the wrong index (always looking at index zero).

    The only way I was able to get past this was to implement the fix he suggested where index starts at zero and is incremented.

    Here is what my init packet looks like, index = 0 is for SD, and index = 1 is for BL:

    boot_validation_count = 2,
    boot_validation = {
        {
          type = DFU_VALIDATION_TYPE_VALIDATE_ECDSA_P256_SHA256,
          bytes = {
            size = 64, 
            bytes = "<some bytes>",
          },
        },
        {
          type = DFU_VALIDATION_TYPE_VALIDATE_GENERATED_CRC,
          bytes = {
            size = 0,
            bytes = '\000' <repeats 63 times>
          },
        },
    }

    I think this bug would be hidden unless "VALIDATE_ECDSA_P256_SHA256" is used for SD, otherwise the SD and BL would end up using the same validation. Can you elaborate on how you determined it "works as expected"? Did you try the same configuration?

  • By the way I am using nRF52 SDK v15.3.0, but I checked and the firmware bug mentioned above is still present in v16.0.0.

    I tried updating the SD+BL using nRF Connect on both iOS and Android, all failed due to this firmware bug.

    I believe the only option to workaround this bug is to not use nrfutil pkg generate --sd-boot-validation VALIDATE_ECDSA_P256_SHA256 until the bug is fixed in an update version of the bootloader.

  • Hi,

    Thank you for updating this thread. You are right, this is a bug. I have created an internal ticket and discussed it with the SDK team so that it can be fixed in a future release.

Related