nRF52832 Buttonless Secure DFU with bonds

[GCL-SOENCO]

Hey Everyone, 

    Looking for some direction, I'm trying to create a secured DFU bond between my nRF52832 and the nRF Connect Mobile app following the instructions from the links below,

https://infocenter.nordicsemi.com/index.jsp?topic=%2Fsdk_nrf5_v17.0.2%2Fservice_dfu.html

https://infocenter.nordicsemi.com/index.jsp?topic=%2Fsdk_nrf5_v17.0.2%2Fble_sdk_app_buttonless_dfu.html

https://infocenter.nordicsemi.com/index.jsp?topic=%2Fsdk_nrf5_v17.0.2%2Fble_sdk_app_dfu_bootloader.html

I've programmed "sd_s132_bootloader_buttonless_with_setting_page_dfu_secure_ble_debug_with_bonds" HEX file to the device and am working towards creating the bond with the phone per below.

Bond to the device using nRF Connect (it is advertising as 'Nordic_Buttonless'). Click the settings button, select "Security Settings", check "Perform bonding", and click "Apply".

but am having issues finding the "security setting" or "perform bonding" button in this version of the nRF Connect app. Any help with navigating the app is MUCH appreciated, once I learn how to make the connection, I can try and troubleshoot from there. 

 

    

Please let me know if I'm leaving anything out, I've done a lot of steps up to this point.

Thank you, Gerald

[Einar Thorsrud]

Hi,

There is no support for bonding in the bootloader. The difference between using the bootloader with and without bonds is that when you configure the bootloader to use bonding, it will get the bonding data from the application (which must previously have bonded with the phone), and use that to secure the link when re-connecting in bootloader mode.

See the Testing Buttonless Secure DFU with bonds in the Buttonless DFU Template Application documentation for details on how to do this.

[GCL-SOENCO]

This bonding data comes from the project's hex file that is converted into a zip file?

I'm still confused by the instructions listed in the "Testing Buttonless Secure DFU with bonds" section since it states to go into Settings -> Security Settings -> Perform Bonding  (I cannot find this in the phone's mobile app)

[Einar Thorsrud]

GCL-SOENCO said:

This bonding data comes from the project's hex file that is converted into a zip file?

No, the bonding data comes from the pairing process (when two bluetooth devices exhcange encryption keys etc).

GCL-SOENCO said:

I'm still confused by the instructions listed in the "Testing Buttonless Secure DFU with bonds" section since it states to go into Settings -> Security Settings -> Perform Bonding  (I cannot find this in the phone's mobile app)

If you are using nRF Connect for Android, then there is an option to bond. On iOS, there is no way for an app to explicitly bond, so you will need to try to access a characteristic that requiers security in order to initiate pairing/bonding if that is what you are using.

I am wondering though. Do you really need/want DFU with boding (this is particularily relevant as it seems to me you were not aware what this feature was)? It causes a few potential pittfals, and in most cases DFU without bonds is secure enough. You can still use bonding as normal when in the application, and the updgrade images are signed. The only major difference is that the DFU procedure is not encrypted.

[GCL-SOENCO]

Thank you! That makes more sense, we're using iPhone for this process.

Long story short, I've been tasked to get up to speed with secure DFU for the nRF52832 chip we're using on our product in pre production. The company's goal is to either.

1) Only allow access to firmware updates through one main device (iphone, ipad, etc) here at our facility without the ability of someone with an external device being able to read or write to memory on the chip (locked)

2) To be able to integrate the DFU process into the product's mobile application allowing the end users to download the firmware update to the chip whenever changes have been made (i.e any device nowadays)

[Einar Thorsrud]

I suggest you look at DFU without bonding then, as it does not seem you have a specific reason for using it.

The secure bootloader always checks the signature of the image, so only images signed by someone that has the private key will be accepted. So in the 2) case, just allow anyone to enter DFU mode.

There is one caveat, though. If anyone is allowed to cause the device to enter DFU mode via Bluetooth, that could potentially mean that it is possible to do a denial of service attach by making the device enter DFU mode again and again. So even if that would not make it possible to update the device with any firmware that is not signed, it could be a problem non the less. So in that case, it could be that you would want to adjust the buttonless DFU service so that bonding is requiered in order to enter DFU mode (that would mean changing line 220 in components/ble/ble_services/ble_dfu/ble_dfu_unbonded.c. Or use some other mechanism like whitelisting to only allow specific devices to connect in the first place. But generally how to solve this, and your 1) and 2) in general, will be application specific.

[GCL-SOENCO]

Last question I promise.

I downloaded the Android app and have been successfully about to make a bond with the example project programming " sd_s132_bootloader_buttonless_with_setting_page_dfu_secure_ble_debug_with_bonds" to the board and downloading the zip file. 

I trying to figure out how to create my own DFU_buttonless bootloader by changing the config.h files and compiling both the debug bootloader and the ble_app_buttonless_dfu armgcc folder. I tried creating the bootloader settings.hex file by input my "project file in the command like so, but wondering if I needed to put the bootloader .hex file name into the command rather than my own.

taking the softdevice file, the bootloader file and the newly created settings file and dragging them into the programmer to write but I'm unable to get any type of DFU buttonless targ to display on the Connect app

nrfutil settings generate --family NRF52 --application BoardTimer.hex --application-version 1 --bootloader-version 1 --bl-settings-version 2 BLsettings.hex"

[Einar Thorsrud]

Hi,

GCL-SOENCO said:

I trying to figure out how to create my own DFU_buttonless bootloader by changing the config.h files and compiling both the debug bootloader and the ble_app_buttonless_dfu armgcc folder.

I am not able to understand exactly what you have done and how things are not working. Perhaps you can elaborate in more detail on what you have done and in what way it does not work? Note that the example bootloader projects are normally suitable to be used as is, though often with minor configuration changes.

When it comes to buttonless support in the application (which is the functionality of entering DFU mode via the application) adding that can be a bit more work, but you should refer to the buttonless DFU template application example. You can test the other bootloader functionality without this though (by simply programming only the Bootloader and SoftDevice). Then you should be able to upload an application via DFU, showing that you got most of the bootloader functionality working.

GCL-SOENCO said:

I tried creating the bootloader settings.hex file by input my "project file in the command like so, but wondering if I needed to put the bootloader .hex file name into the command rather than my own.

No, you do not need the bootloader hex file to generate the bootloader settings. What you need to provide, is the exact application hex that is running, as a checksum will be generated. You can also test the bootloader as explained earlier  in this post without bootloader settings just as without the application. The point with generating and flashing bootloader settings is that this metadata contains things like a flag indicating that a valid application is present, a hash or checksum of the application and application version (and some other data not relevant here). In order to get the bootloader to start the application the bootlaoder settings needs to be correct, and that can happen either by installing the application via DFU (as then the metadata is proivded to the bootloader as part of the upgrade procedure), or by flashing the bootloader settings page directly. So when doing production programming, or just flashing something you built for testing, you need to also generate and program a valid bootloader settings page that match the current application.

GCL-SOENCO said:

taking the softdevice file, the bootloader file and the newly created settings file and dragging them into the programmer to write but I'm unable to get any type of DFU buttonless targ to display on the Connect app

The nrfutil command you use to generate the bootloader settings looks correct to me, so if BoardTimer.hex is the exact application hex that you are using (and does not include the SoftDevice or anything else), then this should be good. As you are testing with the debug bootloader you should look at the RTT log to see why it does not start the application. You can upload the log here if you need help to interpret it.