How to validate signature check requirements

[RMV]

I am trying to create a test case for in house validation and would like to know how to do so.

Here is what I want to do:

1. I want to create a boot loader that checks the signature of the application every time the device boots up.
2. I want to combine the SoftDevice, the boot loader, the boot loader settings and the application into a single HEX file
3. (IMPORTANT) I want to download this package to the device using a 'SWD debug port' -- not by any generic DFU workflows.
4. Then I want to power cycle and reboot the device and ensure that I can FORCE the device to FAIL the boot up validation by using a 'WRONG' key somewhere in the process that leads to the generation of the single HEX file in (2) above.

My SoC is the nRF52832_xxAA, and I am using SDK version 16.0.0, SoftDevice 132 version 7.0.1

Can this be done, and if so, how?

Cheers

RMV

[Einar Thorsrud]

Hi RMV,

Can this be done, and if so, how?

Yes, this is all supported out of the box.

I want to create a boot loader that checks the signature of the application every time the device boots up.

This is supported by the nRF5 SDK bootloader. By default it will only check a CRC of the application, but you can require a signature check by setting NRF_BL_APP_SIGNATURE_CHECK_REQUIRED to 1 in the bootloader's sdk_config.h.

I want to combine the SoftDevice, the boot loader, the boot loader settings and the application into a single HEX file

That is no problem. You can merge all these to a single hex using the mergehex tool which is part of nRF Command Line Tools.

(IMPORTANT) I want to download this package to the device using a 'SWD debug port' -- not by any generic DFU workflows.

No problem. As long as your merged hex file includes a bootloader settings page, the app will start and everything will work after programming via SWD. Note that you need to specify here as well that there should be a signature verification, so that the correct signature is part of the generated settings page.

Then I want to power cycle and reboot the device and ensure that I can FORCE the device to FAIL the boot up validation by using a 'WRONG' key somewhere in the process that leads to the generation of the single HEX file in (2) above.

To do this, just supply a dummy hex file instead of the correct hex file when generating the bootloader settings page. Then the signature will not be valid for the actual hex file, and the bootloader will not start the application.

Einar

[RMV]

Einar Thorsrud said:

(IMPORTANT) I want to download this package to the device using a 'SWD debug port' -- not by any generic DFU workflows.

No problem. As long as your merged hex file includes a bootloader settings page, the app will start and everything will work after programming via SWD. Note that you need to specify here as well that there should be a signature verification, so that the correct signature is part of the generated settings page.

I am sorry but I do not know how to "specify here as well that there should be a signature verification" -- I am using JLINK over SWD so what would be the workflow for specifying signature verification at boot up?

Einar Thorsrud said:

Then I want to power cycle and reboot the device and ensure that I can FORCE the device to FAIL the boot up validation by using a 'WRONG' key somewhere in the process that leads to the generation of the single HEX file in (2) above.

To do this, just supply a dummy hex file instead of the correct hex file when generating the bootloader settings page. Then the signature will not be valid for the actual hex file, and the bootloader will not start the application.

Do you mean a dummy 'key file' instead of 'hex file' ?

[Einar Thorsrud]

Hi,

RMV said:

I am sorry but I do not know how to "specify here as well that there should be a signature verification" -- I am using JLINK over SWD so what would be the workflow for specifying signature verification at boot up?

This is not related to programming itself. The points is that you need to specify the validation method when you generate the bootloader settings page so that it is properly signed. Specifically you need to use --app-boot-validation VALIDATE_ECDSA_P256_SHA256. You can type nrfutil settings generate --help for more details on settings page generation.

RMV said:

Do you mean a dummy 'key file' instead of 'hex file' ?

No, I ment hex file, but you will get the same effect by changing the key file. Essentially, you need both the correct data and correct key to generate a valid signature. So replacing any of the two when generating the bootloader settings page would cause subsequent signature verification to fail (as expected).

[RMV]

Thank you for the walkthrough. I will mark this as 'answered'

Cheers

RMV

[RMV]

Einar Thorsrud said:

This is not related to programming itself. The points is that you need to specify the validation method when you generate the bootloader settings page so that it is properly signed. Specifically you need to use --app-boot-validation VALIDATE_ECDSA_P256_SHA256. You can type nrfutil settings generate --help for more details on settings page generation.

I can get the version without any encryption to boot up, but have not been successful in making this update process work with encryption.

I am using SDK v16.0.0, Soft Device S132 v7.0.1 on an nRF52832 custom board.
I would like to use ECDSA with 256bit hash but can settle for a related and supported variant on this ecosystem.

My question is:
What combination of preprocessor symbols (and anything else that I am unaware of) is required to be defined in the sdk_config and the command line when:
1. Building the boot loader + DFU
2. Building the application + buttonless DFU service

Cheers
RMV