RE: Erase the Previous program when secure OTA with Wrong Key?

Nilesh Bhavsar — Fri, 04 May 2018 11:04:28 GMT

Hello Sir,

There is silly mistake by me in testing.

When i update the program using wrong credential. it is not like erase program but make it in again "DFUtarg" mode or when i restart device its start working normally like my previous application.

Thank you.

RE: Erase the Previous program when secure OTA with Wrong Key?

Rune Holmgren — Thu, 26 Apr 2018 15:23:41 GMT

It sounds to me like you are having a different problem. A wrong key shouldn't invalidate the existing application. I might have to try this out myself since there could be some bug unknown to me. If I can reproduce the issue I can help find a suitable workaround. First I have a few questions:

What error code are you getting from the device?

Is the failing update you are sending completely identical to the successful one?

Have you tried resetting the device after the failed update to ensure that it's not just the device being ready to receive another update?

Best regards,
Rune Holmgren

RE: Erase the Previous program when secure OTA with Wrong Key?

Nilesh Bhavsar — Mon, 23 Apr 2018 14:46:10 GMT

Hello sir,

Thank for your response.

But, i tried to change function "nrf_dfu_find_cache" which is called in "dfu_req_handling.c". By calling this function with "true" instead of "false". There is no change in behaviour of my chip. It will erase the program if once try to update using wrong key.

RE: Erase the Previous program when secure OTA with Wrong Key?

Rune Holmgren — Mon, 23 Apr 2018 13:30:59 GMT

Hi,

When a DFU process is running, there are a few different phases to consider. They are distinctly separated by the prevalidation and post validation operation.

Before prevalidation

Everything that happens before prevalidation can be done by anyone at any time given that they are able to connect to the BLE device. Because of this, we never perform operations at this point which are not reversible during this period. We will initiate the DFU process and receive the "init packet".

Prevalidation

After receiving the init packet, the prevalidation is run. At this point, we will check that this update is to be started. This includes checking compatibility with the SoftDevice, checking hardware version numbers, checking the version number of the new firmware, and finally verifying the ECDSA based signature. Only with a successful prevalidation will we continue the process. Note that the "debug" version of the bootloaders available in the SDK will skip several checks.

Between pre- and postvalidation

In this period we will be receiving the new firmware. If there is enough space to perform a dual bank update, the bootloader will not remove the existing application. If such an update fails though power failure, an invalid package or BLE disconnection, the original application will still be present and valid. However, if there is not enough free space for the new update the bootloader will delete the existing application and use the free space. If a single bank update is interrupted the device will only have a bootloader and no app. It can not be used until an application update has been performed.

In your case you want to never be in a situation where the application is deleted. This means that you will have to have enough space on the device to perform the update. You may change the value of the "dual_bank_only" parameter in the function "nrf_dfu_find_cache" which is called in "dfu_req_handling.c". By calling this function with "true" instead of "false" you force the device to reject any updates too large for dual banking. Note that this means you have to have a small enough application to receive whatever updates you are planning to send. On an nRF51 this means a very small application.

Post validation and after post validation

Not relevant to your problem. If the application has not been removed by this point, you will not have any issues.

"I had done secure OTA successfully with SDK 12 but when i am trying to update the code using wrong private key at that time my old program erased by itself and my board start to emit "DFUTarg"."

This is not something that should happen just because you have used the wrong key. Are you using the debug version of the example or something? I am curious as to how you got into this state. If you reset the device, will it the still not switch to the application?

Best regards,
Rune Holmgren