Secure DFU rescue

[nrbrook]

I've implemented secure DFU which works fine. However, if a user was to do something like quit the App or disable Bluetooth during DFU, or another fault occurred, because the DFU is single bank then the device will be stuck in the bootloader. So I added a capability in the App to discover devices stuck in the bootloader and perform DFU again, this works fine. However, what if the user removed the bonding from iOS/Android? The bootloader will be stuck with the old bonding and the device cannot be recovered. So I'm attempting to modify the bootloader to allow new bondings, but It's not very easy. Has this situation been considered by Nordic? What is the suggested way to solve this problem?

[Ivan Herrera]

Do you need the bootloader to verify bonds? A simple solution would be to only allow bonded devices to enter the device into DFU mode, but not have the bootloader check for bonds. The firmware should be signed anyways so there isn't a way that somebody could flash rogue software on your device.

Do you have any buttons on your device which you could use to communicate with the bootloader? Another option in that case would be to edit the bootloader so that a long button-press would disable bond checking in the bootloader.

[nrbrook]

Yes I can allow new bonds in bootloader (or use existing bond for normal DFU) which I have just been able to implement (it's a bit more involved than just disabling a check for bonding), but IMO this should be available in the bootloader without modification, perhaps as an SDK config option, because otherwise the case where the iOS/Android device has lost the bonding is not handled. Preventing new bondings in the bootloader only matters if you care which devices can perform DFU, because as you say all updates are signed anyway. So I wanted to know if there was a more "officially supported" way of doing this than modifying the bootloader.

[Ivan Herrera]

But DFU without bonds is in there by default! :) You can set NRF_DFU_BLE_REQUIRES_BONDS to 0 in the bootloader config

[nrbrook]

I don't think that works if already bonded? There was some reason I was using secure bootloader...

[Vidar Berg]

The flash footprint of the bootloader would increase quite considerably if we duplicated the bond management in the bootloader code.

But you said:

nrbrook said:

Preventing new bondings in the bootloader only matters if you care which devices can perform DFU, because as you say all updates are signed anyway.

If you are not worried about which device is sending the request, wouldn't it be better to just disable NRF_DFU_BLE_REQUIRES_BONDS in the bootloader and NRF_DFU_BLE_BUTTONLESS_SUPPORTS_BONDS in the app? Note that these settings don't impact the bond support in your main application.

[nrbrook]

Yes I can do this. For some reason I didn't think it would work without bonds if already bonded. Perhaps because the name of "NRF_DFU_BLE_BUTTONLESS_SUPPORTS_BONDS" is a bit misleading – if you disable it, will DFU work if you are using bonding in the App? It's not clear, because you are indicating "bonding isn't supported". "REQUIRES_BONDS" would be better IMO, because it does require bonding if enabled.

[Vidar Berg]

I agree, "REQUIRES_BONDS" would make more sense. I'm not sure why we didn't use the same naming in the app as in the bootloader, but I'll report it. Sorry for the confusion.