nrf8240 Signature validation failed during testing

[R_S]

Hi , 

i am using nrf52840 dk board. and using 17.1 sdk for examples code.

i am trying to customize open bootloader code and trying to validate the signature of a input data by using nrf_dfu_validation_signature_check() API.

Note: - i am having my own public and signature data, which i fed to this function.

But i am getting "NRF_DFU_RES_CODE_INVALID_OBJECT" in return from the above API.

Below i attcahed the calling function with input parameters.

static uint8_t m_message[] = "ABCDEFGHIJKLMNOPQRSTUVWXYZ0123456789";
const size_t m_message_len = 36; // Skipping null termination

Regards

[R_S]

And above this can i c ross check my created signature whether it is ok or not.

is there any way to do that....?

https://infocenter.nordicsemi.com/pdf/nrfutil_v1.3.pdf

i am following this user guide to generate private key. but what about the signature data, how can i generate that so that i can cross check whether there is an issue with my signature or not.

Thanks

[Einar Thorsrud]

Hi,

R_S said:

And above this can i c ross check my created signature whether it is ok or not.

is there any way to do that....?

The only way I can see to do that is to do the validation operation and ensure that it is successful. Also, there is not really much information you can get about what is wrong wen you you validate the signature. Either it validates OK, or there is a problem.

R_S said:

i am following this user guide to generate private key. but what about the signature data, how can i generate that so that i can cross check whether there is an issue with my signature or not.

I see you use nrfutil, and the nRF5 SDK bootloader, with some modification. If you use  nrfutil to generate the upgrade image and an unmodified bootloader, this will work assuming you did not accidentally use wrong keys (for instance forget to build the bootloader with the public key that corresponds to the private key you used with nrfutil). If you have checked the keys it would be interesting to know which changes you have done in the bootloader? Perhaps you can backtrack and go back to the working SDK example and then see which change you does that cause problems?

[R_S]

HI Einar,

yes you are right i am just verify my application before it start.

bootloader settings i am using following command.

nrfutil.exe settings generate --family NRF52840 --application blinky_pca10056.hex --application-version 1 --bootloader-version 1 --bl-settings-version 2 settings.hex

and how to specify that i want to validate VALIDATE_ECDSA_P256_SHA256 while creating bootloader settings rather than CRC.

Regards

Rohit saini

[Einar Thorsrud]

Hi Rohit,

You would have to expand your nrfutil command to something like this:

nrfutil.exe settings generate --family NRF52840 --application blinky_pca10056.hex --application-version 1 --bootloader-version 1 --bl-settings-version 2 --app-boot-validation VALIDATE_ECDSA_P256_SHA256 --key-file /path/to/key_file.pem settings.hex 

You should also set NRF_BL_APP_SIGNATURE_CHECK_REQUIRED to 1 in the bootloader's sdk_config.h to enforce it.

[R_S]

Hi Einar,

in this command , these version number will it effect the process or its just the version just assigning here?

And in application part which hex file i need to pass whether its a bootloader hex file or my application hex file which will run after bootloader?

Regards

Rohit Saini

[Einar Thorsrud]

Hi Rohit,

R_S said:

in this command , these version number will it effect the process or its just the version just assigning here?

The version numbers for application and bootloader does not matter in itself, other than that downgrade protection ensures that you need to use increasing numbers. So when you set 1, a DFU image which is not higher will not be accepted (this can be adjusted by sdk_config.h macros, though). This data will be programmed to the bootloader settings page and is read whenever there is a DFU procedure. This is just the starting point though. If you update to for instance application version 3, the number in the settings page on the device would then be changed to 3.

The bl-settings-version is a bit different, and depends on the SDK version of the bootloader. As you use SDK 17.1 it should always be set to 2. This is to match the data structure and content that is used by the bootloader version you use.

R_S said:

And in application part which hex file i need to pass whether its a bootloader hex file or my application hex file which will run after bootloader?

You normally only need to pass the hex file of the application when generating bootloader settings page. If you also want SD boot validation you need to pass the SoftDevice hex file as well.

Einar

[R_S]

Thanks Einar,

one last thing is the below commands are ok for programming

1. Erase the entire flash

nrfjprog.exe --family NRF52 --eraseall

2.Program the MBR

nrfjprog --reset --program mbr_nrf52_2.4.1_mbr.hex  --family NRF52 --sectoranduicrerase

3.Program the Bootloader Settings

nrfjprog --program settings.hex -f NRF52 -r

4. Program the Bootloader

nrfjprog --reset --program open_bootloader_usb_mbr_pca10056.hex --family NRF52 --sectoranduicrerase

5. Program Blinky App

nrfjprog --reset --program blinky_pca10056.hex --family NRF52 --sectoranduicrerase

Regards

 

[Einar Thorsrud]

Hi,

No, these sets of commands are not OK. The specific problem is that the bootloader start address is stored in the UICR, and that is part of the bootloader hex file. When you later program the application with the "--sectoranduicrerase" option, the UICR is deleted again. In this specific case it would be enough to just skip "--sectoranduicrerase" from step 5, but as you start with an erase all there is no need to use this anywhere, so I suggest you remove this option from all the commands.

[R_S]

Thanks Einar