Buttonless Secure DFU - Preparing for Production

RE: Buttonless Secure DFU - Preparing for Production

jumpingfool — Mon, 05 Nov 2018 04:17:03 GMT

Thanks - that works!

To save confusion for others it might be wise to update Appendix 1 of the DFU tutorial to note that the MBR needs to be cleared when flashing new firmware with the bootloader present when using SDK 15:

devzone.nordicsemi.com/.../getting-started-with-nordics-secure-dfu-bootloader

RE: Buttonless Secure DFU - Preparing for Production

Marjeris Romero — Fri, 02 Nov 2018 12:18:27 GMT

Hi,

My mistake, there was a change from SDK 14.2 to SDK15.2. In SDK 15.2 we use MBR parameter storage as a backup of the bootloader settings page. You will need to erase the backup stored in the MBR (and reflash app + settings). Try this:

nrfjprog --erasepage 0x000FE000
nrfjprog --program application.hex --sectorerase
nrfutil settings generate --family NRF52840 --application application.hex --application-version 1 --bootloader-version 2 --bl-settings-version 1 settings.hex
nrfjprog --program settings.hex --sectorerase
nrfjprog --reset

Where 0x000FE000 is the start adress of the MBR parameter storage in nRF52840.

See the comment on the update under "New features" here:

- The bootloader settings page is now backed up before being updated. This increases protection from corruption caused by chance events
    (for example, power failure) and malicious apps.

Regards,

Marjeris

RE: Buttonless Secure DFU - Preparing for Production

jumpingfool — Wed, 31 Oct 2018 22:52:57 GMT

These are the commands I'm using that work and bring the application up correctly (application is built prior in SES):

nrfjprog -e
nrfjprog --program s140_nrf52_6.1.0_softdevice.hex
nrfjprog --program bootloader.hex 
nrfjprog --program application.hex --sectorerase
nrfutil settings generate --family NRF52840 --application application.hex --application-version 1 --bootloader-version 2 --bl-settings-version 1 settings.hex
nrfjprog --program settings.hex --sectorerase
nrfjprog --reset

If I don't do the erase and just flash the application/bootloader settings the device comes up in DFU mode. I didn't have this issue with SDK 14.2.

RE: Buttonless Secure DFU - Preparing for Production

Marjeris Romero — Wed, 31 Oct 2018 15:17:51 GMT

Hi,

You should be able to re-flash the application + bootloader settings using --sectorerase. There are no changes in SDK15.2 that modify this. Could you post the commands you are using to update the application?

Just as a recap, you'll need to

Build the application hex file
Generate a new bootloader settings based on new application hex file
Flash the new application and new bootloader settings

Best Regards,

Marjeris

RE: Buttonless Secure DFU - Preparing for Production

jumpingfool — Wed, 31 Oct 2018 09:48:46 GMT

Thanks msromero - we will follow your advice!

A seperate but related question - I have found that on SDK 15.2 I can no longer re-flash just the application (+ settings page) when the bootloader is present. If I try the device will go to DFU mode on reset, presumably because the bootloader is rejecting the updated application.

Instead I have to fully erase the chip and write SD + bootloader + application + settings page all at the one time, then it works. If I send a new application over DFU it also works. It is only when attempting to flash a new application directly there is a problem.

Has something changed in the SDK 15.2 bootloader that means the application cannot be re-flashed after initial programming? Any work around for this? It is a pain for development having to fully erase the device each time the application is updated as bonding information, etc is lost in the process.

RE: Buttonless Secure DFU - Preparing for Production

Marjeris Romero — Tue, 30 Oct 2018 15:09:04 GMT

Hi,

[quote user=""]What is the purpose of the buttonless_dfu_sdh_state_observer function? What drives the need to enter system off here?[/quote]

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.

[quote user=""]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?[/quote]

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.

[quote user=""]It it usual to change the name advertised by the bootloader to be application specific or leave it as the generic DfuTarg in production?[/quote]

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.

[quote user=""]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?[/quote]

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.

[quote user=""]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?[/quote]

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.

[quote user=""]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?[/quote]

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

[quote user=""]Any other security/logistics considerations around the DFU process we should be aware of before entering production?[/quote]

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