Option to roll back from confirmed image slot in rare OTA situations

[Bogdan Yanko]

Hi. I am working on firmware for nRF9160 based IoT device
Already found a way how I can switch between two different images in flash from the current firmware and it's super useful

Firmware image that laying on backend cloud server includes logic to check that main features like server connection and peripherals working well to make a decision to keep that version or roll back to the previous one. One more secure mechanism implemented using MCU boot it's if firmware not confirming itself device switching back to known firmware stored in a flash that should work well. All those methods providing a good way of reliability, so it really hard to brick the device in process of OTA.

But what if somehow binary with for example blink code that confirming to use this FW as the main one appears on the server

So at the end device after such update would run just "blink" code without any options to roll back to an older image

I understand that this is a very unlikely case, but if it's happening in production all user devices would be bricked as the result of for example a hacker attack on the server and replacing image to as in my example "self-confirming blink" so the device should be shipped back for restoration e.t.c

I wonder if there is any way how we could roll back the device to the old image without a J-link connection in situations like described upper to make it usable for production cases

Regards, Bogdan

[Håkon Alseth]

Hi,

Already found a way how I can switch between two different images in flash from the current firmware and it's super useful

Its great to hear this!

Firmware image that laying on backend cloud server includes logic to check that main features like server connection and peripherals working well to make a decision to keep that version or roll back to the previous one. One more secure mechanism implemented using MCU boot it's if firmware not confirming itself device switching back to known firmware stored in a flash that should work well. All those methods providing a good way of reliability, so it really hard to brick the device in process of OTA.

You can read about the concepts of mcuboot, specifically how it behaves when reverting (and how to trigger it), here:

https://developer.nordicsemi.com/nRF_Connect_SDK/doc/1.7.0/mcuboot/design.html

I understand that this is a very unlikely case, but if it's happening in production all user devices would be bricked as the result of for example a hacker attack on the server and replacing image to as in my example "self-confirming blink" so the device should be shipped back for restoration e.t.c

In order for mcuboot to accept an image, it must match the static partition layout in addition to be signed with your own key. If the key is compromised, you can get into this scenario.

Just applying arbitrary binary data to mcuboot  (ie. from a "fake" webserver) will not trigger such a scenario, as mcuboot will recognize that the incoming data is not signed accordingly.

 

Kind regards,

Håkon