nrf_dfu_set_peer_data returns 8 and does NOT start DFU bootloader

RE: nrf_dfu_set_peer_data returns 8 and does NOT start DFU bootloader

Andrew Ong — Fri, 21 Sep 2018 18:36:26 GMT

I actually meant "with bonds" in both cases--because configuration 1 is what I currently have working. I think your answer remains the same though. Thanks for clarifying!

RE: nrf_dfu_set_peer_data returns 8 and does NOT start DFU bootloader

Sigurd — Fri, 21 Sep 2018 11:17:49 GMT

I assume you meant "without bonds" for configuration 1. But yes, your understanding is correct. But note that the attacker won't have the private key, you are supposed to keep that a secret. With configuration 2, the bootloader will only accept DFU images from the device that triggered the DFU mode, (and that device need to be bonded.)

RE: nrf_dfu_set_peer_data returns 8 and does NOT start DFU bootloader

Andrew Ong — Fri, 21 Sep 2018 08:40:58 GMT

I still don't understand what the difference is between using configuration 1:

dfu_unbonded.c
with bonds
NRF_DFU_BLE_BUTTONLESS_SUPPORTS_BONDS = 0, and NRF_DFU_BLE_REQUIRES_BONDS = 0

and using configuration 2:

dfu_bonded.c
with bonds
NRF_DFU_BLE_BUTTONLESS_SUPPORTS_BONDS = 1, and NRF_DFU_BLE_REQUIRES_BONDS = 1

it sounds like the only difference is that in configuration 1, the attacker could intercept the connection and DFU another payload as long as the payload is signed with the private key, whereas in configuration 2, the attacker has no chance to intercept because the bond info is passed to the bootloader, is that right?

RE: nrf_dfu_set_peer_data returns 8 and does NOT start DFU bootloader

Sigurd — Fri, 21 Sep 2018 08:06:31 GMT

No, the init package with the new firmware would need to be signed with the private key, so even if an attacker connected to the device in DFU mode, he would need to know the private key to upload a new firmware image.

There is also some information about DFU with and without bonds here.

RE: nrf_dfu_set_peer_data returns 8 and does NOT start DFU bootloader

Andrew Ong — Thu, 20 Sep 2018 22:08:19 GMT

Are you implying that if NRF_DFU_BLE_REQUIRES_BONDS = 0, the application bond is NOT forwarded to the bootloader and an attacker could intercept the connection and DFU another payload?

RE: nrf_dfu_set_peer_data returns 8 and does NOT start DFU bootloader

Sigurd — Thu, 20 Sep 2018 14:24:49 GMT

Hi,

[quote user="androng"]The DFU still requires bonding because my attr_md.wr_auth = 1;. So then what is the point of NRF_DFU_BLE_BUTTONLESS_SUPPORTS_BONDS = 1, and NRF_DFU_BLE_REQUIRES_BONDS = 1 and using the "dfu_bonded.c" file? [/quote]

Please see this answer.

RE: nrf_dfu_set_peer_data returns 8 and does NOT start DFU bootloader

Andrew Ong — Thu, 20 Sep 2018 09:09:21 GMT

OMG IT WORKS

I was able to DFU my device twice with the "dfu_unbonded.c" file!

my iPhone bonded
NRF_DFU_BLE_BUTTONLESS_SUPPORTS_BONDS = 0, and NRF_DFU_BLE_REQUIRES_BONDS = 0
attr_md.wr_auth = 1 on the DFU characteristic;

The DFU still requires bonding because my attr_md.wr_auth = 1;. So then what is the point of NRF_DFU_BLE_BUTTONLESS_SUPPORTS_BONDS = 1, and NRF_DFU_BLE_REQUIRES_BONDS = 1 and using the "dfu_bonded.c" file?