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 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?

[Dominik Eugster]

Yes, I run my code on a custom HW with the IO drive to a nRF21540 aswell included into the bootloader code.

And yes, I work with nRF5 Software Development Kit v17.0.2.

Again, I think its running like it should, I only expected an other feedback from the bootloader.

What I expected:

1) Wrong key on a Booloader or application zip DFU package -> bootloader will not accept the file and not start the flashing

-> reality: same behaviour

2) Bootloader or App zip DFU file with no validation option added with nrfutil (correct key added to pkg):

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

-> what I expected: -> bootloader will not accept the file and not start the flashing

-> reality: bootloader accept both zip files, flash them, restarts and do it again and agin and doesn't accept it to load. But the check that there is no validation added is recognized AFTER flash the complete zip file and not before like a wrong key. Is this how it shoulkd work or not?

Can you try this on your DK please? Does the bootloader on your DK check and block the flashing of a application zip file WITHOUT the validation added before flashing the complete file or can the bootloader check this only if the file was transferred 100% before? (I use nRF Connect App on a Android Phone)

Thanks a lot

[Edvin]

Dominik Eugster said:

Can you try this on your DK please? Does the bootloader on your DK check and block the flashing of a application zip file WITHOUT the validation added before flashing the complete file or can the bootloader check this only if the file was transferred 100% before? (I use nRF Connect App on a Android Phone)

That is what I did (in an otherwise unmodified SDK). 

Actually, I was testing on SDK17.1.0, but after realizing that your bootloader project was written for SDK17.0.2, I ran the test again now.

So the unmodified bootloader, pca10056_s140_ble, together with the ble_app_buttonless_dfu example for simplicity. 

First, without any modifications, just checking that everything was OK, and normal DFU was working. Then I changed:

#define NRF_BL_APP_SIGNATURE_CHECK_REQUIRED 0

to

#define NRF_BL_APP_SIGNATURE_CHECK_REQUIRED 1

In order to get the ble_app_buttonless_dfu example to still run, I changed the command to generate the bootloader settings from:

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

Then the ble_app_buttonless_dfu example would still run. However, the dfu image created with the command:

nrfutil pkg generate --application files\buttonless2.hex --application-version 3 --hw-version 52 --sd-req 0x0100 --key-file ..\..\..\private.key files\dfu_test.zip

Does not work. It transfers the image, but the image will be rejected when the CRC is validated. To confirm that it will not run, you can monitor the nrfutil output, or you can make a change in the application that you are trying to upload (I turned on LED4 in the updated application, just to see whether it was running or not). 

Then I added the app validation in the nrfutil pkg generate command:

nrfutil pkg generate --application files\buttonless2.hex --application-version 3 --hw-version 52 --sd-req 0x0100 --app-boot-validation VALIDATE_ECDSA_P256_SHA256 --key-file ..\..\..\private.key files\dfu_test.zip

And then the image was accepted again.

If you want to test yourself, unzip an unmodified DK, and add the following test.bat file to your SDK\examples\dfu\secure_bootloader\pca10056_s140_ble\armgcc folder:

Fullscreen 2308.test.bat Download

make -j9
make -j9 -C ..\..\..\..\ble_peripheral\ble_app_buttonless_dfu\pca10056\s140\armgcc

mkdir files

del files\buttonless.hex
copy ..\..\..\..\ble_peripheral\ble_app_buttonless_dfu\pca10056\s140\armgcc\_build\nrf52840_xxaa.hex files\buttonless.hex

del files\settings.hex
::nrfutil settings generate --family NRF52840 --application files\buttonless.hex --application-version 2 --bootloader-version 2 --bl-settings-version 2 --key-file ..\..\..\private.key files\settings.hex
nrfutil settings generate --family NRF52840 --application files\buttonless.hex --application-version 2 --bootloader-version 2 --bl-settings-version 2 --app-boot-validation VALIDATE_ECDSA_P256_SHA256 --key-file ..\..\..\private.key files\settings.hex
::nrfutil settings generate --family NRF52840 --application files\buttonless.hex --application-version 2 --bootloader-version 2 --bl-settings-version 2 --app-boot-validation VALIDATE_ECDSA_P256_SHA256 --sd-boot-validation VALIDATE_ECDSA_P256_SHA256 --key-file ..\..\..\private.key files\settings.hex


:: REPLACE THE SERIAL NUMBER TO MATCH YOUR TARGET DK
nrfjprog -e --snr 683825227
nrfjprog --program _build\nrf52840_xxaa_s140.hex --verify --snr 683825227
nrfjprog --program ..\..\..\..\..\components\softdevice\s140\hex\s140_nrf52_7.2.0_softdevice.hex --verify --snr 683825227
nrfjprog --program files\settings.hex --verify --snr 683825227
nrfjprog --program files\buttonless.hex --verify --snr 683825227
nrfjprog --reset --snr 683825227



nrfutil pkg generate --application files\buttonless2.hex --application-version 3 --hw-version 52 --sd-req 0x0100 --key-file ..\..\..\private.key files\dfu_test.zip
::nrfutil pkg generate --application files\buttonless2.hex --application-version 3 --hw-version 52 --sd-req 0x0100 --app-boot-validation VALIDATE_ECDSA_P256_SHA256 --key-file ..\..\..\private.key files\dfu_test.zip
timeout 5

:: REPLACE THE COM PORT TO MATCH YOUR CONNECTIVITY DK
nrfutil dfu ble -pkg files\dfu_test.zip -ic NRF52 -p COM8 -n "Nordic_Buttonless" -f

NB: You need to change the serial number to match your target DK and the COM port to match your connectivity DK.

The current setup in test.bat will fail to upload the DFU. To succeed, comment out line 25 and uncomment line 26.

Also, you need to compile the ble_app_buttonless_dfu example with a modification (not strictly needed to modify it), and place it in the files\ folder, with the name buttonless2.hex.

Best regards,

Edvin

[Dominik Eugster]

Edvin said:

Does not work. It transfers the image, but the image will be rejected when the CRC is validated. To confirm that it will not run, you can monitor the nrfutil output, or you can make a change in the application that you are trying to upload (I turned on LED4 in the updated application, just to see whether it was running or not). 

Yes this is the same behaviour what I had, the DFU OTA was possible but after the transfer of 100%, the image will be rejected. My fault was, that I expected that the image will be rejected before the transfer like when I generate the files with a wrong key.

Edvin said:

And then the image was accepted again.

Yes, I had the same on my custom HW.

-> at the end I can say it's working like it should, the only "problem" was that I expected the rejection before the transfer and not after.

Thank you for your effort and time!

[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