DFU: ECDSA accepts wrong keys, while CRC/SHA256 fails to boot valid app (SDK 17.1.0)

RE: DFU: ECDSA accepts wrong keys, while CRC/SHA256 fails to boot valid app (SDK 17.1.0)

Edvin — Wed, 18 Feb 2026 07:26:48 GMT

I am glad you found the issue, and that it was not actually a bug in the bootloader. Thank you for letting us know what you found!

Have a nice day 🙂

Best regards,

Edvin

RE: DFU: ECDSA accepts wrong keys, while CRC/SHA256 fails to boot valid app (SDK 17.1.0)

Anthony-P — Tue, 17 Feb 2026 15:11:45 GMT

[quote userid="26071" url="~/f/nordic-q-a/127046/dfu-ecdsa-accepts-wrong-keys-while-crc-sha256-fails-to-boot-valid-app-sdk-17-1-0/561370"]You use --app-boot-validation every time you generate your bootloader settings, right?[/quote]

Yes.

[quote userid="26071" url="~/f/nordic-q-a/127046/dfu-ecdsa-accepts-wrong-keys-while-crc-sha256-fails-to-boot-valid-app-sdk-17-1-0/561370"]But it looks like you don't perform the DFU in this case, right? You just program the application using the debugger? [/quote]

Yes again.

[quote userid="26071" url="~/f/nordic-q-a/127046/dfu-ecdsa-accepts-wrong-keys-while-crc-sha256-fails-to-boot-valid-app-sdk-17-1-0/561370"]Not sure what is the issue here. Is the issue that you are not able to correctly reject the image? Or that the image is incorrectly accepted?[/quote]

The problem was that when I signed the bootloader with the correct private.key, it would then accept a wrong key when updating through DFU.

However I found the problem, I had a bad case of not enough coffee. To test I correctly generated a wrong.key file. However when I was performing DFU I grabbed the wrong.key from a different folder… and, of course, that one contained the correct key. (-: Sorry for the inconvenience and thanks for the quick support.

RE: DFU: ECDSA accepts wrong keys, while CRC/SHA256 fails to boot valid app (SDK 17.1.0)

Edvin — Tue, 17 Feb 2026 14:33:22 GMT

It is still a bit unclear to me what you are actually doing.

You use --app-boot-validation every time you generate your bootloader settings, right?

Remember that these bootloader settings are only used if you program the application using a debugger, and not if you actually preform the DFU:

[quote user="Anthony0"]The sdk_config.h was modified because we don't have a button to enter dfu mode so our goal is to have the app trigger the DFU using GPREGRET.[/quote]

But it looks like you don't perform the DFU in this case, right? You just program the application using the debugger?

[quote user="Anthony0"]Since NRF_BL_APP_SIGNATURE_CHECK_REQUIRED was set to 1 in my sdk_config.h it always rejected the app.

EDIT: I also did some further testing and if I modify the key dfu_public_key.c the bootloader correctly complains and reject the update. However if I leave the public key untouched it stills accepts the wrong private key[/quote]

Not sure what is the issue here. Is the issue that you are not able to correctly reject the image? Or that the image is incorrectly accepted?

RE: DFU: ECDSA accepts wrong keys, while CRC/SHA256 fails to boot valid app (SDK 17.1.0)

Anthony-P — Tue, 17 Feb 2026 13:38:59 GMT

I managed to fix the CRC/SHA256 failure, it came from this part of the code.

else if (NRF_BL_APP_SIGNATURE_CHECK_REQUIRED &&
    (s_dfu_settings.boot_validation_app.type != VALIDATE_ECDSA_P256_SHA256))
{
    NRF_LOG_WARNING("Boot validation failed. The boot validation of the app must be a signature check.");
    return false;
}

Since NRF_BL_APP_SIGNATURE_CHECK_REQUIRED was set to 1 in my sdk_config.h it always rejected the app.

EDIT: I also did some further testing and if I modify the key dfu_public_key.c the bootloader correctly complains and reject the update. However if I leave the public key untouched it stills accepts the wrong private key.

00> <info> nrf_dfu_validation: Verify signature
00> <error> nrf_dfu_validation: Signature failed (err_code: 0x8542)

RE: DFU: ECDSA accepts wrong keys, while CRC/SHA256 fails to boot valid app (SDK 17.1.0)

Anthony-P — Tue, 17 Feb 2026 12:57:13 GMT

Hi Edvin, thanks a lot for your fast answer !

Unfortunately I don't have a DK. I did some minor modifications turning on some LEDs inside dfu_observer() using the nrf_gpio_pin_set and clear to have a visual feedback. I also modified sdk_config.h and pca10056.h (to match our IO). I used the example "secure_bootloader_uart_mbr_pca10056". The sdk_config.h was modified because we don't have a button to enter dfu mode so our goal is to have the app trigger the DFU using GPREGRET.

Here is the bash script I use to build the final.hex file.

mergehex -m nRF5_SDK_17.1.0_ddde560/components/softdevice/mbr/hex/mbr_nrf52_2.4.1_mbr.hex secure_bootloader_uart_mbr_pca10056.hex -o system.hex 

nrfutil settings generate --app-boot-validation VALIDATE_ECDSA_P256_SHA256 --key-file private.key  --family NRF52840 --application app.hex --application-version 1 --bootloader-version 1 --bl-settings-version 2 settings.hex

mergehex -m app.hex settings.hex -o package.hex
mergehex -m package.hex system.hex -o final.hex

nrfjprog --eraseall
nrfjprog --program final.hex --verify
nrfjprog --reset

RE: DFU: ECDSA accepts wrong keys, while CRC/SHA256 fails to boot valid app (SDK 17.1.0)

Edvin — Tue, 17 Feb 2026 12:36:44 GMT

Hello,

Did you do any modifications to the bootloader, other than the sdk_config.h file? Are you able to reproduce what you are seeing on an nRF52840 DK? If you are, can you please zip and upload the bootloader project that you are using, so that I can try to reproduce it using an nRF52840 DK on my end.

Best regards,

Edvin