nRF52 error during DFU process

[Mehdi]

Hi, 

I'm developing an nRF52 application based on SDK14 and S132 that require the DFU service.

The DFU is not performed using the nRF toolbox application on both of android and iOS with a different error message.

I got one of the error messages below: 

• Enabling Indication failed : Under iOS_V10.3.2.
• DFU device not bonded   : Under Android_V6.0.1.

When I tested with the DFU_Buttonless example from SDK14 the DFU performed correctly under Android.

Best Regards,

Mehdi.

[Einar Thorsrud]

Hi Mehdi,

Do you use DFU with or without bonds? Can you test with nRF Connect for iOS/Android upload the full logs from the mobile side? If you have a debug bootloader with logging enabled, logs from the nRF would be useful as well.

BR,

Einar

[Mehdi]

Hi Einar,

Thank you for your quick reply.

Previously, I used the DFU with bonds and my device is not bonded with the smartphone, this is why, the android application indicate that the device is not bonded.

So when i switched to DFU without bonds, it works correctly.

My question now, how can I performe DFU process with bonding.

BR,

Mehdi

[Einar Thorsrud]

Hi Mehdi,

It seems to me like you did not bond in the application before attempting to do DFU, or that you removed the bond from the phones. Alternatively, simply that your application did not transfer the bonding information to the bootloader correctly. You can refer to the Buttonless DFU Template Application to see how to use DFU with bonding.

In my opinion, removing the bond between the state when entering DFU mode and actually performing DFU is a significant risk with the bootloader which requires bonding. In this case, the nRF device would stay in bootloader mode, but you would not be able to upgrade it. In SDK 14 there is no timeout in the bootloader, so it would stay in the bootloader. Personally, I advice against using DFU with bonds for this reason, but you do not actually risk bricking the device as the SDK 14 bootloader introduced a inactivity timeout that restarts into the application after 120 seconds of inactivity.

As an alternative could be to require pairing/bonding in order to write to the DFU characteristic to put the device in bootloader mode, but still use the bootloader without bonds. This way only the bonded phone would be able to put the device in bootloader mode, but any device would be able to upgrade. This in turn does not pose a practical risk, as only an upgrade image with the correct signature will be accepted.

Best regards,

Einar

[Mehdi]

Hi Einar,

Thank you for your quick reply and for the advice.

I have another question please, now i'm using DFU without bonds, I changed the private key in my '.pem' file and i generated another application package '.ZIP' in order to test the security of our DFU.

When i tested DFU with the modified private key, this operation still proceed.

Is this the normal behavior ? 

Best Regards,

Mehdi. 

 

[Einar Thorsrud]

Hi Mehdi,

This sounds like normal behaviour. The signature is not checked until the device enters the bootloader (no part of the DFU image is transferred while the device is in application mode). This is OK, as the purpose of the signing is to prevent the device from being programmed with a un-authorized firmware image.

If you want to prevent the device from entering bootloader mode, you should instead require security for writing to the DFU characteristic, triggering DFU mode. This is essentially a completely different problem, which has no relationship with the signature verification of the DFU image.

Best regards,

Einar