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

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

Edvin — Fri, 17 Mar 2023 08:29:33 GMT

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

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

RVM — Thu, 16 Mar 2023 21:27:14 GMT

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?

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

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

Edvin — Thu, 25 Aug 2022 06:48:02 GMT

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

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

Dominik Eugster — Wed, 24 Aug 2022 15:02:21 GMT

[quote userid="26071" url="~/f/nordic-q-a/91118/ble-secure-boot-validation-option-on-the-app-bootloader-zip-file/383048"]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). [/quote]

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.

[quote userid="26071" url="~/f/nordic-q-a/91118/ble-secure-boot-validation-option-on-the-app-bootloader-zip-file/383048"]And then the image was accepted again.[/quote]

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!

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

Edvin — Wed, 24 Aug 2022 11:37:07 GMT

[quote user="Dominik Eugster"]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)[/quote]

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

#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:

devzone.nordicsemi.com/.../2308.test.bat

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

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

Dominik Eugster — Tue, 23 Aug 2022 20:01:32 GMT

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

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

Edvin — Tue, 23 Aug 2022 14:03:23 GMT

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?

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

Dominik Eugster — Tue, 23 Aug 2022 13:55:37 GMT

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?

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

Dominik Eugster — Tue, 23 Aug 2022 13:07:12 GMT

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

devzone.nordicsemi.com/.../1207.secure_5F00_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

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

Edvin — Tue, 23 Aug 2022 12:29:13 GMT

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

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

Dominik Eugster — Tue, 23 Aug 2022 09:13:17 GMT

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?

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

Edvin — Mon, 22 Aug 2022 12:04:40 GMT

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

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

Dominik Eugster — Fri, 19 Aug 2022 12:46:59 GMT

What I like to implement is the VALIDATE_ECDSA_P256_SHA256 option to have the highest security level. Are there some settings in the sdk_config.h which are necessary to enable this?