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

Possible to enter DFU only when bonded?

Unless I am not understanding the code correctly (highly possible...), once the bootloader has restarted into DFU mode, no bond is required to upload new firmware. This works great if you have to physically press a button to enter DFU mode.

Not so safe when doing it buttonless since anyone with "nRF Toolbox" could potentially upload an image. Yes, I know there is DEVICE_TYPE and DEVICE_REVISION as a safety check.

Is it possible to require being bonded to the application before allowing the restart into DFU? Maybe by changing the security setting of one of the dfu characteristics? I know the DFU bootloader changes the gap address, so the bond wouldn't be valid anymore, but that's OK if you can prevent getting into DFU without a bond in the first place.

Thanks.

  • @Chris: It's a good point that there should be a security check before we allow a master to tell the device to enter bootloader mode in the example. Recently we provided signing solution as an experimental project in SDK 9.0. However, this only block attacker to flash non-genuine firmware but not blocking him to flash the device with older or wrong firmwares that come from the vendor.

    But it's not too difficult to implement some security check before you allow the application to start the bootloader. As you mentioned, you can set the write permission on the DFU characteristic to require encryption. So that bonding is needed if the central want to write 0x01 here to start DFU. If it's the case, you should also block unwanted central to connect to your device by using whitelist.

    If your application should have an open connection and allow any central to bond, then you may want to implement proprietary password and/or public+private key authentication procedure before you allow the application to enter bootloader mode.

  • When I change this in the dfu_ctrl_pt_add function from:

    BLE_GAP_CONN_SEC_MODE_SET_OPEN(&attr_md.write_perm);

    Changed to:

    BLE_GAP_CONN_SEC_MODE_SET_ENC_NO_MITM(&attr_md.write_perm);

    nRF Toolbox asks me to pair, which is what I want, I see the device reset into the bootloader, but then it errors out with "Error on BLE Notification Message: The handle is invalid...".

    I tried keeping it OPEN in the bootloader and encrypted in the application, but that throws the same error.

    It works perfectly if just set to OPEN.

    What do I need to do to require a paired connection to DFU?

    Btw, I am using SDK8.0.0.

    Thanks.

  • Hi Chris,

    I suspect that you haven't handled the service changed indication correctly. Make sure you have sent the indication in bootloader when reconnected. The error "Error on BLE Notification Message: The handle is invalid..." tells that the attribute table is not updated.

    Did you test with the ble_app_hrs_withdfu example ? If not please test with that example, and follow how we handle switching back and forth between application and bootloader. The example is not by default require bonding, but you can modify as you did above, or force a bonding using our nRFMaster Control Panel app.

  • But it works perfectly when set to OPEN, so the service changed indication must be working correctly, no?

    Making that one change to NO_MITM breaks it.

    Btw, I am using SDK8.0.0.

    I assume you are talking about:

    ble_enable_params.gatts_enable_params.service_changed = IS_SRVC_CHANGED_CHARACT_PRESENT; //=1
    

    It's in there and my bootloader is based on the ble_app_hrs example.

  • @Chris: When it's not bonded, the phone will try to do service discovery again when reconnected (service changed indication only apply when devices are bonded). This explains why you don't have the issue. I would prefer to have a sniffer trace to understand what could be wrong in your case. Have you tested with the ble_app_hrs_dfu example, to check if it has the same issue ?

Related