This post is older than 2 years and might not be relevant anymore
More Info: Consider searching for newer posts

Butonless secure DFU with bonds- limitation on client devices

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!

Parents
  • 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

  • Thank you Einar!
    I understand.

    One question, if I may.
    Can your first point -

    Only bonded peers can write to the Buttonless DFU characteristic

    be applied to buttonless DFU without bonds? Or can this only be achieved when using DFU with bonds?

    Thank you for the quick and concise reply!

  • 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:

    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);
    

Reply
  • 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:

    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);
    

Children
No Data
Related