Bonding in DFU Bootloader

[ilnadi]

I have found many questions regarding passing bonding information from the application to the bootloader (e.g. https://devzone.nordicsemi.com/f/nordic-q-a/34497/dfu-with-bonds-and-nrf52810) and we already have Buttonless DFU working in several implementations.

We have a new project that may use BLE for OTA only.  I'm trying to avoid bringing up BLE in the main application just for OTA.  If we bring up BLE only in the bootloader, I see two options:

1. work without a bond, with the associated security risks.  This may not be a huge risk as the overall device outside of our implementation has some UI and we may be able control when OTA happens.
2. Try to establish a bond in the bootloader.  Is there a reason the "no button, no display" bonding would not work from inside the bootloader?  I can see the bootloader may get big but I am not sure if there is any other reason.  The bootloader uses the same SoftDevice features and API as the main application.

Thank you

[Kenneth]

Hi,

I do not see any security improvements of having the bootloader support bonding. The data you are transferring is in any case available to "read" by various means (e.g. either by someone sniffing communication when bonding and/or by someone just get the hex by other means). The best approach is to physically have a button the user must press to perform OTA, and then only when someone have physically access can they trigger OTA, you may still use signing of the hex file to ensure that only valid OTA will be performed.

Best regards,
Kenneth

[ilnadi]

Thank you.  This will simplify the design.