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,

RMV said:

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

It should have worked if you only use signature verification on the app. If also used on the SoftDevice then there is a bug in SDK 16 which was fixed in SDK 17 (see SDK 17.0.2 release notes). You could back-port that if needed. In what way does this not work? Do you get any errors or sensible logs form the bootloader if you test with the _debug bootloader with RTT loggign?

RMV said:

I would like to use ECDSA with 256bit hash but can settle for a related and supported variant on this ecosystem.

The bootloader supports exactly what you want, and that is the only cryptographic has that is supported out of the box. Others can be added, but I do not see a need for that as your wishes is in line with the SDK support.

RMV said:

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

To be honest the down-side with sdk_config.h is that it is huge and automatically generated. We do not provide any minimal set. I recommend you just start off with the relevant example. Most examples have a complete sdk_config.h. If you for some reason want to minimize it, you can remove configurations that is not used, but I do not have any such minimal sdk_config.h files to provide. That does not have any effect on the resulting code, though. Similarly, if you miss some configuration macros you will typically see quite easily from the error when building what is missing so that you can add missing parts form an example sdk_config.h file. I understand this is not the answer you hoped for, but this is how the nRF5 SDK is organized.

Einar