BLE Secure boot validation option on the App/bootloader zip file

[Dominik Eugster]

Hi

I have a running DFU code and can update the bootloader as generated zip file and the app with the zip file. Now I saw, that there is the option "VALIDATE_ECDSA_P256_SHA256" to generate the packages.

See also : https://devzone.nordicsemi.com/guides/short-range-guides/b/software-development-kit/posts/getting-started-with-nordics-secure-dfu-bootloader#h12sk6tbb3hw1qnwn7q4hvp5tvthcli

Now I got 2 questions:

1. I made a test and got the Info from the packages with nrfutil pkg display and saw that to zip file for the bootloader is still with CRC validation, why?

the app is with the correct validation:

2. If I download the zip package of the APP with the --app-boot-validation VALIDATE_ECDSA_P256_SHA256, its working. But I can still download an App zip file with CRC validation. The same for the bootloader zip file. Why this? Do I have to use the nrfutil settings generate with the option --app-boot-validation and --sd-boot-validation with VALIDATE_ECDSA_P256_SHA256 aswell?

I expected that a zip file without the VALIDATE_ECDSA_P256_SHA256 is not valid and the update would be impossible, which is not the case.

Thanks for a feedback

[Edvin]

Hello,

Please see my colleague, Amanda's reply in this ticket:

 Secure DFU (APP, SD, BL) from SDK 15.3.0 to SDK 17.0.2 with VALIDATE_ECDSA_P256_SHA256 

Basically, you need to set NRF_BL_APP_SIGNATURE_CHECK_REQUIRED in your bootloader's sdk_config.h file if you want to use the VALIDATE_ECDSA_P256_SHA256 option.

Best regards,

Edvin

[Dominik Eugster]

Hi Edvin 

I changed NRF_BL_APP_SIGNATURE_CHECK_REQUIRED in the bootloader's sdk_config.h. Then I generated all files, combined the HEX files, flashed my device and code is running. But it's still posiible to do a OTA with a Bootloader or APP zip file which is NOT generated with the line --app-boot-validation VALIDATE_ECDSA_P256_SHA256 --sd-boot-validation VALIDATE_ECDSA_P256_SHA256.

What do I don't understand? And why is this possible?

[Edvin]

I tested this with an image using the serial (!) bootloader from SDK17.1.0 just now, and a DFU image consisting of an application, without the --app-boot-validation set just now, and I was not able to transfer the image, due to an "Invalid object" return. 

Can you please try an unmodified SDK?

Are you replicating this on an nRF52840 DK? If so, can you please send the bootloader project you are using? (remember to remove the keys you are using. I can generate my own key pair). 

Best regards,

Edvin

[Dominik Eugster]

I will try an unmodified, but I didn't changed something about reading the keys.

I use the SeggerEmbeed Code, added you all files whith a new generated key, just for debug.

Thanks for your time

1207.secure_bootloader.rar

The only difference between the 2 zip files is the boot validation type, the signature of the file is ECDSA_P256_SHA256 o both zip files, even if I don't use the command:

--app-boot-validation VALIDATE_ECDSA_P256_SHA256 --sd-boot-validation VALIDATE_ECDSA_P256_SHA256

[Dominik Eugster]

Checking again, is it possible that the complete DFU OTA is working until 100%, but the check of the validation key is done after rebooting the bootloader? Because now I can do the OTA with a unsigned zip file until 100%, the bootloader restarts, is checking again and the Nordic nRF Connect App restarts automatically to download again and again, maybe because of an unsigned APP? Is this the logic?

I expected that the check of the signed APP is done BEFORE starting the DFU. I use the single image bootloader and therefore I can "kill" the application with the Nordic App (only with an APP which was generated with the correct key, but which is unsigned)

Is this the correct handling of the bootloader?

[Edvin]

I struggle to reproduce this on a DK. Is it intended to run on custom HW? It keeps disconnecting from nRF Connect. 

You are using SDK17.0.2, right?