Buttonless DFU Example broken

RE: Buttonless DFU Example broken

Hung Bui — Mon, 19 Mar 2018 08:26:36 GMT

@Thomas: Don't you read my reply right above? Please create a new case.

RE: Buttonless DFU Example broken

Thomas Y — Mon, 19 Mar 2018 06:56:59 GMT

I tried this in SDK v14 and when the device enter DFU in the bootloader (no bounding) nothing happen while waiting for event.

NRF Connect is stuck at start 0%

0> <info> app: Device is preparing to enter bootloader mode.
0> <info> app: Device will enter bootloader mode.
0> <info> app: Power management wants to reset to DFU mode
0>
0> <info> app: reset_prepare disconnect from peer
0> <info> app: reset_prepare app_timer_stop_all
0> <info> app: reset_prepare ble_conn_params_stop
0> <info> app: startDFU enter
0>
0> <info> app: Inside main
0> <debug> app: In nrf_bootloader_init
0> <debug> app: In real nrf_dfu_init
0> <debug> nrf_dfu_settings: Running
nrf_dfu_settings_init(sd_irq_initialized=false).
0> <debug> nrf_dfu_flash: Calling
nrf_dfu_flash_init(sd_irq_initialized=false)...
0> <debug> nrf_dfu_flash: Initializing nrf_fstorage_nvmc backend.
0> <debug> app: Initializing the clock.
0> <debug> app: Enter nrf_dfu_continue
0> <debug> app: Valid App
0> <debug> app: In nrf_dfu_enter_check user
0> <debug> app: enter FDU
0> <debug> app: Application sent bootloader request
0> <debug> app: In nrf_dfu_transports_init
0> <debug> app: num transports: 1
0> <debug> app: Initializing BLE DFU transport
0> <debug> app: vector table: 0x00073000
0> <debug> app: vector table: 0x00073000
0> <debug> app: Error code - sd_softdevice_vector_table_base_set: 0x00000000
0> <debug> app: Enabling SoftDevice.
0> <warning> nrf_sdh_ble: RAM starts at 0x20002830, can be adjusted
to 0x20002180.
0> <warning> nrf_sdh_ble: RAM size can be adjusted to 0xDE80.
0> <debug> app: SoftDevice enabled.
0> <debug> app: nrf_dfu_settings_adv_name_is_valid FALSE
0> <debug> app: Regular adv name
0> <debug> app: #### Advertising NO BONDING ####
0> <debug> app: Finished initializing BLE DFU transport
0> <debug> app: After nrf_dfu_transports_init
0> <debug> nrf_dfu_flash: Calling
nrf_dfu_flash_init(sd_irq_initialized=true)...
0> <debug> nrf_dfu_flash: Initializing nrf_fstorage_sd backend.
0> <debug> app: Waiting for events
0> <debug> app: #### Advertising NO BONDING ####
0> <debug> app: #### Advertising NO BONDING ####
0> <debug> app: #### Advertising NO BONDING ####
0> <debug> app: #### Advertising NO BONDING ####
0> <debug> app: #### Advertising NO BONDING ####
0> <debug> app: #### Advertising NO BONDING ####

then switch back to APP

RE: Buttonless DFU Example broken

Hung Bui — Wed, 25 Oct 2017 12:50:12 GMT

@Paul: Please create a new case when you have question. This is a pretty old case and we have buttonless supported natively in SDK v14. Please find it here. Make sure you have a look at the Buttonless Secure DFU Service to know how it works.

RE: Buttonless DFU Example broken

paul_tanner — Wed, 25 Oct 2017 05:46:54 GMT

@kevin I downloaded Vidar's version and don't see what makes that buttonless. What exactly does this mean: "Enable notifications on the control point, and write 0x01 to enter DFU mode" What is the nature of the trigger for entering DFU, is it something the application does or something it's always listening for when running? Thx.

RE: Buttonless DFU Example broken

sam wagner — Wed, 26 Jul 2017 18:02:18 GMT

Hi Hung,

Thanks for the reply. It is good to know that sharing of bonding information will be supported in the upcoming SDK release. Any idea when the SDK will be available?

I understand that anyone who gets the .zip DFU package might be able to reverse engineer the FW even though bonding information is shared between the App and the Bootloader. Yes, my concern about the replay attack is exactly what you mentioned above. Someone can just replay the OTA DFU packets (since they currently go unencrypted on air and hence are easy to sniff on air for any malicious user) and force the costly operation of firmware update on the device. As you mentioned, I can change the default bootloader behavior to reject DFU if the FW version is the same to avoid such situation.

Thanks, Sam

RE: Buttonless DFU Example broken

Hung Bui — Wed, 26 Jul 2017 12:27:41 GMT

Hi Sam,

We do plan to have bonding supported in the next release of the SDK. But still, attacker may have access to the phone (or to the .zip DFU package) and find the unencrypted firmware )

I'm not an expert in security, but what exactly the risk of having replay attack ? The attacker can't modify the firmware, if he send the same firmware, you can tell the bootloader to reject the firmware if the firmware version is the same (default behaviour is to accept it)

RE: Buttonless DFU Example broken

sam wagner — Wed, 26 Jul 2017 06:46:53 GMT

Sorry for the typos in the above comment. I hope the main points are clear. Please provide some insight into this and I am not able convince my team about the robustness of security mechanism used by the DFU mechanism in SDK12!

RE: Buttonless DFU Example broken

sam wagner — Wed, 26 Jul 2017 06:44:57 GMT

hi Hung,

Since the without sharing the bonding information between App and the Bootloader, the OTA DFU happens on an unencrypted link. So, anybody can look at the ECDSA signed FW image being transferred and possibly reverse engineer the image (since the FW itself is not encrypted) and/or do replay attack of the same ECDSA signed FW image. (some references: devzone.nordicsemi.com/.../). How does the current method of DFU guard against the above issues (namely, reverse engineering of FW image sniffer on air and replay attack of the same image along with its ECDSA signature)?

Thanks, Sarang

RE: Buttonless DFU Example broken

Hung Bui — Wed, 03 May 2017 09:17:04 GMT

Hi, The out come from the discussion on support portal was to not do bond forwarding and only do address change when switching to bootloader. Here is some quote explaining:

The main reason why bonding does not provide a benefit is that the upgrade image is signed, so the upgrade can only be performed with a valid image. The real issue when it comes to security for buttonless DFU is to prevent an attacker to put the device in DFU mode, as we discussed, which is independent of bonding used for DFU or not.

If bonding information is shared between bootloader and application there are some cases that could lead to problems. For example, if the application deletes the bond after the bootloader has started, the bonding information will be invalid. In that case, the bootloader need a way to delete the bonding information. Another situation is where the upgrade is aborted for some reason, and the device is reset into the bootloader (possibly with an invalid application if the application is so large that single bank DFU is needed). In that case, the application cannot be run in order to transfer bonding information to the bootloader. There are other corner cases as well.

The conclusion from our DFU team is that with the current solution, the only benefit of sharing bonding information is that there is no need to change the device address, and that this does not outweigh the disadvantages. That is why we have not implemented sharing of bonding information at the moment, and does not have immediate plans to do not. Nor do we recommend modifying the application and bootloader for sharing bonding information.

RE: Buttonless DFU Example broken

pmeilleur — Tue, 02 May 2017 23:41:40 GMT

I'm interested by the topic and I guess I'm not the only one! Can you please share the developments with the community..?

RE: Buttonless DFU Example broken

Hung Bui — Fri, 17 Feb 2017 08:59:56 GMT

OK, we will try to push the SDK team to get something for you. We will continue discussion on the case on support portal.

RE: Buttonless DFU Example broken

parco — Fri, 17 Feb 2017 01:44:47 GMT

Hung Bui, this is incredibly high priority for us, I created a support ticket.

RE: Buttonless DFU Example broken

Hung Bui — Thu, 16 Feb 2017 15:26:22 GMT

yes, you would need to forward the bond information (LTK) from applicaton, and send it to the softdevice when in bootloader by calling sd_ble_gap_sec_info_reply() when there is BLE_GAP_EVT_SEC_INFO_REQUEST event.

RE: Buttonless DFU Example broken

parco — Thu, 16 Feb 2017 15:16:15 GMT

Would this require changes to the bootloader?

RE: Buttonless DFU Example broken

Hung Bui — Thu, 16 Feb 2017 15:09:58 GMT

I see, that part is not covered in the current DFU buttonless, you may need to implement on your own, I would suggest to follow what we did in the example in SDK v11.

RE: Buttonless DFU Example broken

parco — Thu, 16 Feb 2017 14:33:26 GMT

The nice handing off from application to dfu that took place like in legacy dfu. I think it's called bond sharing?

RE: Buttonless DFU Example broken

Hung Bui — Thu, 16 Feb 2017 14:29:23 GMT

Could you let me know the main feature lacking on the experimental example that you need ?

RE: Buttonless DFU Example broken

parco — Thu, 16 Feb 2017 14:26:27 GMT

@Hung Bui what are the chances we can get some dedicated work on this?

RE: Buttonless DFU Example broken

Hung Bui — Thu, 16 Feb 2017 13:03:02 GMT

Nope, seems still in experimental in SDK v13 releasing next month.

RE: Buttonless DFU Example broken

parco — Thu, 16 Feb 2017 08:46:50 GMT

It's been nearly 4 months, any updates on a production ready buttonless example?

RE: Buttonless DFU Example broken

Hung Bui — Tue, 14 Feb 2017 13:25:51 GMT

It's our proprietary service so it's normal that Apple products show it as Unknown Service. Regard the issue that you have to send command several time, please try to capture a sniffer trace we will be able to investigate further. I suggest to create a new case on this.

RE: Buttonless DFU Example broken

Kevin s — Mon, 13 Feb 2017 18:23:43 GMT

@Hung: OK, I was able to get Vidar's modified code going to bootloader mode by turning off the bluetooth and leaving it off for a couple of minutes. Then turning it back on; I guess since I'm using the same dev board and phone, there was some cached information prohibiting the service from running. I have also verified Vidar's code works for an Andriod tablet and an Ipad Air2. Although it does not work immediately; sometimes I must have to send the command to go to bootloader multiple times. Also, the Andriod tablet shows the name of the service (Experimental Buttonless DFU Service") whereas the apple products show the service as "Unknown Service".

RE: Buttonless DFU Example broken

Hung Bui — Mon, 13 Feb 2017 14:08:22 GMT

Hi Kevin,

Sorry for misunderstanding. It's most likely the phone cached the ATT table so that you can't find the DFU control point characteristic you should write. What was the "a write/notify Characteristic" you used ? What was the UUID ? The UUID for the DFU buttonless char is 50-EA-DA-30-88-83-B8-9F-60-4F-15-F3-01-00-40-8E. You should try to turn off and on bluetooth on the phone, then use nRFConnect to connect and service discovery.

RE: Buttonless DFU Example broken

Kevin s — Mon, 13 Feb 2017 12:52:41 GMT

@Hung: Maybe you misunderstood my previous comment; I have used the experimental_ble_app_buttonless_dfu project, modified by Vidar in the zip file link above. It does not go to the DFU mode as mentioned by daniel77 and me above. "With my iPhone, I see the same as Daniel77; Nordic_Template and the services he mentioned. When I use Master Control Panel from my computer I see "Nordic_Template" with a write/notify Characteristic. I write 01 00 to the value and rescan, but the Board does not go to bootloader."

RE: Buttonless DFU Example broken

Hung Bui — Mon, 13 Feb 2017 10:23:25 GMT

@Kevin: If you update the firmware with a normal application (not an buttonless DFU application) then you should not expect that you can enter DFU after that. You need to implement Buttonless DFU service in the application.

Please refer to the experimental_ble_app_buttonless_dfu, check the services_init() function.