Butonless secure DFU with bonds- limitation on client devices

Question

Hello! Reading the following segment regarding Buttonless DFU with bonds from the documentation, I'm not clear as to the meaning of these paragraphs. It looks like two contradicting designs are held simultaneously, so I was hoping someone could make this clearer. 
 Below is a snippet where I point out what I found confusing. I can't understand if the buttonless DFU with bonds process must always be requested by the same client, as indicated in the last marked portion, or if it may be requested by any bonded client, but once a client has requested the device to enter buttonless DFU mode, it must be the same client which completes the DFU process with the same peripheral. 
 Should a DFU process timeout or fail for any reason, other bonded clients will be able to start a buttonless dfu process with the same peripheral, but again, the same bonded client must be the one to complete the DFU process with this peripheral. Any clarification will be appreciated. Thanks!

Einar Thorsrud · Accepted Answer

Hi, 
 I think the description is consistent and your understanding seems correct, but perhaps some clarification is needed. Let me rephrase it, and all this applies when using buttonless secure DFU service with bonds: 
 
 Only bonded peers can write to the Buttonless DFU characteristic.
 
 Once written, the bootloader will provide the bonding information for the bootloader and start the bootloader, so that it is in a buttonless DFU state.

In this state, the bootloader will connect (and secure the link) only with the specific peer that triggered buttonless DFU 
 If DFU is performed or times out, so that the normal application starts again any bonded peer can start a new DFU procedure. 
 
 Einar

Einar Thorsrud · Answer

Hi, 
 A.P said: be applied to buttonless DFU without bonds? Or can this only be achieved when using DFU with bonds? 
 Yes, you can easily apply this limitation to DFU without bonds. In fact, that is the most sensible in my opinion (only allow bonded devices to enter DFU mode, but then let any device do DFU as that is less complicated and more robust, and the DFU images are anyway signed, so security would be good also in this case). The only change you need to achieve this is to modify components\ble\ble_services\ble_dfu\ble_dfu_unbonded.c like this:

Fullscreen 
 ble_dfu_unbonded.c.diff 
 Download 
 
 diff --git a/components/ble/ble_services/ble_dfu/ble_dfu_unbonded.c b/components/ble/ble_services/ble_dfu/ble_dfu_unbonded.c
index affdf32..1acf1d6 100644
--- a/components/ble/ble_services/ble_dfu/ble_dfu_unbonded.c
+++ b/components/ble/ble_services/ble_dfu/ble_dfu_unbonded.c
@@ -216,8 +216,8 @@ uint32_t ble_dfu_buttonless_char_add(ble_dfu_buttonless_t * p_dfu)
 add_char_params.is_var_len = true;
 add_char_params.max_len = BLE_GATT_ATT_MTU_DEFAULT;
 
- add_char_params.cccd_write_access = SEC_OPEN;
- add_char_params.write_access = SEC_OPEN;
+ add_char_params.cccd_write_access = SEC_JUST_WORKS;
+ add_char_params.write_access = SEC_JUST_WORKS;
 add_char_params.read_access = SEC_OPEN;
 
 return characteristic_add(p_dfu->service_handle, &add_char_params, &p_dfu->control_point_char);

Butonless secure DFU with bonds- limitation on client devices

Top Replies