Buttonless DFU Example broken

[parco]

Hi there,

I know you guys are very busy and I appreciate your quick response on Devzone.

I'd like to make a request for a more polished example of Buttonless DFU using SDK 12.1 with nRF52.

We are nearing production and if there's anything I'd like to get in concrete, it's a reliable way to upgrade firmware in the field.

The current example is not working out of the box, and the documentation doesn't offer a complete start to finish of how to upgrade. For example, what should we do after we send a 0x01 to the characteristic?

Thanks, Paul

[pmeilleur]

I'm interested by the topic and I guess I'm not the only one! Can you please share the developments with the community..?

[Hung Bui]

Hi, The out come from the discussion on support portal was to not do bond forwarding and only do address change when switching to bootloader. Here is some quote explaining:

The main reason why bonding does not provide a benefit is that the upgrade image is signed, so the upgrade can only be performed with a valid image. The real issue when it comes to security for buttonless DFU is to prevent an attacker to put the device in DFU mode, as we discussed, which is independent of bonding used for DFU or not.

If bonding information is shared between bootloader and application there are some cases that could lead to problems. For example, if the application deletes the bond after the bootloader has started, the bonding information will be invalid. In that case, the bootloader need a way to delete the bonding information. Another situation is where the upgrade is aborted for some reason, and the device is reset into the bootloader (possibly with an invalid application if the application is so large that single bank DFU is needed). In that case, the application cannot be run in order to transfer bonding information to the bootloader. There are other corner cases as well.

The conclusion from our DFU team is that with the current solution, the only benefit of sharing bonding information is that there is no need to change the device address, and that this does not outweigh the disadvantages. That is why we have not implemented sharing of bonding information at the moment, and does not have immediate plans to do not. Nor do we recommend modifying the application and bootloader for sharing bonding information.

[sam wagner]

hi Hung,

Since the without sharing the bonding information between App and the Bootloader, the OTA DFU happens on an unencrypted link. So, anybody can look at the ECDSA signed FW image being transferred and possibly reverse engineer the image (since the FW itself is not encrypted) and/or do replay attack of the same ECDSA signed FW image. (some references: devzone.nordicsemi.com/.../). How does the current method of DFU guard against the above issues (namely, reverse engineering of FW image sniffer on air and replay attack of the same image along with its ECDSA signature)?

Thanks, Sarang

[sam wagner]

Sorry for the typos in the above comment. I hope the main points are clear. Please provide some insight into this and I am not able convince my team about the robustness of security mechanism used by the DFU mechanism in SDK12!

[Hung Bui]

Hi Sam,

We do plan to have bonding supported in the next release of the SDK. But still, attacker may have access to the phone (or to the .zip DFU package) and find the unencrypted firmware )

I'm not an expert in security, but what exactly the risk of having replay attack ? The attacker can't modify the firmware, if he send the same firmware, you can tell the bootloader to reject the firmware if the firmware version is the same (default behaviour is to accept it)

[sam wagner]

Hi Hung,

Thanks for the reply. It is good to know that sharing of bonding information will be supported in the upcoming SDK release. Any idea when the SDK will be available?

I understand that anyone who gets the .zip DFU package might be able to reverse engineer the FW even though bonding information is shared between the App and the Bootloader. Yes, my concern about the replay attack is exactly what you mentioned above. Someone can just replay the OTA DFU packets (since they currently go unencrypted on air and hence are easy to sniff on air for any malicious user) and force the costly operation of firmware update on the device. As you mentioned, I can change the default bootloader behavior to reject DFU if the FW version is the same to avoid such situation.

Thanks, Sam