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]

Ah, I see. 

No, the image will be tranferred. Adding the app-boot-validation will require the bootloader to check the CRC on every reboot (unless otherwise specified). The image will be transferred (since it is signed with the correct key), but when the transfer is done, it will see that the CRC that it should compare against is not present, and hence it will be rejected. 

If you look at where in the bootloader project NRF_BL_APP_SIGNATURE_CHECK_REQUIRED is used, it is used two places:

1: in app_is_valid(), which is used in dfu_enter_check(), to check whether the application is valid during startup in the bootloader.

2: in postvalidate_app(). This is used a few places, but by default, it is mainly called in on_data_obj_execute_request_sched(), which is used when the transfer is complete, and the image is checked before the swap takes place. This check checks if the boot_validation.type is actually VALIDATE_ECDSA_P256_SHA256. 

Best regards,

Edvin

[RMV]

Hi

I have a follow up question.... Who (application or nrfutil) is responsible for creating and inserting the CRC into the new image being uploaded over DFU?

1. Does the application developer have to do some kind of post processing to inject this into a specific location in the generated output file
   OR
2. Does the nrfutil tool calculate and inject this value into the merged HEX or DFU outputs that it generates?

I also do not understand why the generated BL settings show two CRC fields/values e.g. below:

[Edvin]

Those are two different CRCs. By default, the bottom one is 0x00000000:

And this is only used if you use the flag app boot validation:

Note that this also requires some changes to the bootloader. You need to enable some settings in sdk_config.h (I don't remember which one from the top of my head).

But remember that settings are only generated with nrfutil if you intend to flash the application with the debugger. If you intend to do a DFU, the settings will be generated by the bootloader.

If you want to use Boot validation, you need to specify this when generating the application image using nrfutil using "nrfutil pkg generate ... --app-boot-validation <type> ..."

Please see "nrfutil pkg generate --help".

BR,
Edvin