Need Bootloader pairing/bonding without APP pairing/bonding

[Tilak]

Hi,

Greetings!

I want to disallow an unknown bluetooth device (like phone, etc) to connect to "secure_bootloader_ble_s132_pca10040" except from a bunch of pca10056 (central). Basically, I want to authorize/authenticate the bluetooth connection in bootloader mode. I see this was not supported 4 years ago here, is it still the same? Is there a Nordic example for a standalone Nordic bootloader with softdevice (without the APP help) that can perform pairing, bonding and then perform DFU? 

I looked through the devZone, Glucose example with passkey that pairs and performs bonding. Also, looked at buttonless DFU example. All of these require the APP to perform the BOND and then hand over these connection details to the bootloader. This might not be true if the APP fails to bootup and also in the case of beacon advertising. Moreover, as I understand, using a whitelist approach does not scale with the increase in central devices.

Kindly let me know your thoughts on this, especially if I have overlooked something here.

Thanks,
Tilak

[bjorn-spockeli]

I want to disallow an unknown bluetooth device (like phone, etc) to connect to "secure_bootloader_ble_s132_pca10040" except from a bunch of pca10056 (central). Basically, I want to authorize/authenticate the bluetooth connection in bootloader mode. I see this was not supported 4 years ago here, is it still the same?

 Yes, adding bonding management in the bootloader will increase the size of the bootloader considerably so we have opted to keep the size of the bootloader as small as possible so that is why we have chosen the bond sharing approach, where the application shares the bonding information of the central peer that initiates the DFU procedure with the bootloader. 

Is there a Nordic example for a standalone Nordic bootloader with softdevice (without the APP help) that can perform pairing, bonding and then perform DFU? 

 No, we do not have such an example in our SDK. See answer above. 

I looked through the devZone, Glucose example with passkey that pairs and performs bonding. Also, looked at buttonless DFU example. All of these require the APP to perform the BOND and then hand over these connection details to the bootloader. This might not be true if the APP fails to bootup and also in the case of beacon advertising. Moreover, as I understand, using a whitelist approach does not scale with the increase in central devices.

Yes, the application shares the bonding data with the bootloader. The SoftDevice supports up-to whitelisted 8 peers, but in the bootloader case it will only get the bonding information of the central peer that initiated the DFU process. After the DFU process is finished the bootloader will delete this bonding information,  see the DFU Service documentation. 

It is possible to modify the bootloader to have a fallback solution where it does undirected advertising when a specific value is written to a characteristic and then perform pairing before starting the DFU process. That way the link will be encrypted when the image is transfered. 

Its important to note that its only devices that have a valid DFU package signed with the private key that will be able to update the device, regardless if the central device is bonded or not. 

Best regards

Bjørn

[Tilak]

Thank you very much Björn for your detailed response. This has been very helpful.

Thanks,
Tilak