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

[Anthony-P]

Hello,

Setup

• MCU : nRF52840
• SDK : nRF5 17.1.0
• Transport : Secure Bootloader (UART)
• No SoftDevice
• Custom HW

The Problem:
I am experiencing two conflicting behaviors regarding App Boot Validation during the initial factory flash (using merged HEX files) and subsequent DFU updates.

1. The ECDSA Security Issue:
When I set --app-boot-validation VALIDATE_ECDSA_P256_SHA256 in nrfutil settings generate, the bootloader successfully boots the application. However, it also accepts and installs an update.zip signed with the wrong private key.

NRF_BL_APP_SIGNATURE_CHECK_REQUIRED is set to 1 in sdk_config.h.

The public key in dfu_public_key.c is verified to match my production private key.

2. The CRC/SHA256 Boot Failure:
If I change the validation to --app-boot-validation VALIDATE_GENERATED_CRC or VALIDATE_GENERATED_SHA256 using the exact same app hex, the bootloader refuses to start the application (stays in DFU mode).

To generate the factory flash I do the following steps :

1. Use mergehex to combine MBR + Bootloader into "system.hex"
2. Use nrfutil to generate the settings from the app using my private key and a --app-boot-validation option
3. Merge the app.hex + settings.hex into "package.hex"
4. Merge package.hex + system.hex into final.hex
5. Use nrfjprog to program final.hex

Here is my sdk_config.h 70624.sdk_config.h

Question

Why would ECDSA validation permit an app to boot and be updated with a mismatched key when signature check is required and why does the 2 other option just straight up don't work ?

[Edvin]

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

[Anthony-P]

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

[Anthony-P]

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) 

[Edvin]

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:

Anthony-P said:

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.

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

Anthony-P said:

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

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?

[Anthony-P]

Edvin said:

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

Yes.

Edvin said:

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

Yes again.

Edvin said:

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?

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.

[Edvin]

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