Buttonless Secure DFU - Preparing for Production

[jumpingfool]

I am porting an application with buttonless DFU from SDK 14.2 to SDK 15.2 to target nRF52840 and in the process working to prepare the code for production.

After some effort to get the environment set up correctly (I initially missed the compile time pre-processor configuration for enabling NRF_DFU in the SES project, which created some very cyptic macro errors - not sure why the DFU config is not included in sdk_config like everything else!!) it is working and I managed to flash new firmware OTA with our application on SDK 15.2.

However, the skeleton code in the buttonless DFU template is sparsely documented and I would appreciate assistance with the following questions:

1. What is the purpose of the buttonless_dfu_sdh_state_observer function? What drives the need to enter system off here?
2. In app_shutdown_handler -> NRF_PWR_MGMT_EVT_PREPARE_DFU there is code (but commented out) that would disable the softdevice and stop the application timers. Is this required and if so why given the system is about to be reset to enter DFU?

I would also appreciate any additional advice on best practice to "productionise" the DFU process beyond the skeleton code in the SDK, for example:

1. It it usual to change the name advertised by the bootloader to be application specific or leave it as the generic DfuTarg in production?
2. What is the correct way to handle the situation where a device gets stuck in DFU mode (e.g. due to link loss part way through an update)? How does our central (smartphone application) identify the device and recover it to a working state?
3. Our application is bonded but at present we are doing open DFU. Is this a common approach and if so are there any security risks when doing secure DFU without bonding?
4. Is it recommended to use the same private key for signing firmware to all devices or should each device be coded with an individual key? If so how can the key in the bootloader be set without needing to recompile each time?
5. Any other security/logistics considerations around the DFU process we should be aware of before entering production?

All advice gratefully received!

[Marjeris Romero]

Hi,

 

What is the purpose of the buttonless_dfu_sdh_state_observer function? What drives the need to enter system off here?

All our BLE peripherals examples advertise for a certain amount of time and then they go to sleep. The skip CRC thing is because there is a bootloader, so it will make bootup a little faster. So what happens here is that the advertising times out -> the Softdevice is disable -> the buttonless_dfu_sdh_state_observer handler puts the system to sleep.

 

In app_shutdown_handler -> NRF_PWR_MGMT_EVT_PREPARE_DFU there is code (but commented out) that would disable the softdevice and stop the application timers. Is this required and if so why given the system is about to be reset to enter DFU?

 This part of the code can be used if you have an application that needs to finish a task before it resets into DFU mode.

 

It it usual to change the name advertised by the bootloader to be application specific or leave it as the generic DfuTarg in production?

 You can change the name if you want or leave it as it is. Just make sure your mobile app know which target the application is going to connect to perform DFU.

 

What is the correct way to handle the situation where a device gets stuck in DFU mode (e.g. due to link loss part way through an update)? How does our central (smartphone application) identify the device and recover it to a working state?

This will depend if you are using dual-bank or single-bank updates. In the buttonless_dfu example this is taken care of. The preferred update mode if there is enough space for the application (something that usually is the case using nRF52840) is dual-bank. There is a time-out in the DFU bootloader, and it will either recover to the old application and start advertising again, or it will start advertising in bootloader mode if using single-bank. If there is a disconnect and connect while the DFU update is going on the bootloader will remember where in the update it is and continue from it.

 

Our application is bonded but at present we are doing open DFU. Is this a common approach and if so are there any security risks when doing secure DFU without bonding?

I have asked around here and it seems that DFU without bonding is a common approach. Some may see more disadventages than adventages when using bonds. The bootloader will verify the signature of the init packet regardless of it using bonds or not to perform updates.

 

Is it recommended to use the same private key for signing firmware to all devices or should each device be coded with an individual key? If so how can the key in the bootloader be set without needing to recompile each time?

 Yes, you should use the same private key, as long as it is kept private 

 

Any other security/logistics considerations around the DFU process we should be aware of before entering production?

One I can think of is that is you are using bonds you will need to use dual-bank updates. If the application you are updating the nRF52840 with is not valid and you loose your bonded device while performing the update, you will be stucked if using single-bank. When using dual-bank you can go back to the last verified application.

Best Regards,

Marjeris