How do I configure Android App for Legacy DFU Implementation?

[tjhasan]

Very quick question:

I've created a device which implements the Legacy DFU Service. I've also created an Android Application that I plan to develop to be able to conduct OTA DFU updates with the device I created. I understand that Legacy DFU Service is not secure, but this is just for testing for now.

My question is how do I tell my Android Application to conduct the firmware update using the Legacy DFU Service? Looking at the Github page, do I just have to set setUnsafeExperimentalButtonlessServiceInSecureDfuEnabled(true), or is there any other way to tell my Android Application to do this? Any help or guidance would be appreciated!

[Edvin]

Hello,

So by Legacy DFU, you mean the nRF5 SDK Bootloader without keys? 

Do you plan to add the security later? If so, I recommend that you don't go through the trouble of disabling it manually and reintroducing it later. 

That being said, I believe this will set automatically in the DFU library, if you use it as is. There is an example on how this library is used in the nRF Toolbox application. While I don't know much about Android development, I know that you can use the nRF Toolbox app without modifications to update a non-secure bootloader from the nRF5 SDK.

Best regards,

Edvin

[tjhasan]

> So by Legacy DFU, you mean the nRF5 SDK Bootloader without keys?

I'm talking about the application updating functionality that Nordic chipsets can use. For example, I create a BLE Device with Firmware Updating functionality. I can then create an Android application that can send new firmware to that BLE Device in order to keep the firmware up to date.

After SDK 12, Nordic introduced "Secure DFU" which uses a public-private key sharing to ensure that the firmware being sent is from a trusted vendor and not just anyone (which was the case pre SDK 12). However, the "Insecure DFU" implementation is still available and vendors still use it today. Hence my question.

> I recommend that you don't go through the trouble of disabling it manually and reintroducing it later.

I am aware of this, but this is currently for experimentation purposes. I want to test some things out hence why I asking for clarification here.

> There is an example on how this library is used in the nRF Toolbox application.

It looks like the DFU Library was moved to its own Github Repo. There's a section in this repo's README.MD that goes into the history of the DFU Function. In this section, it says "This library is fully backwards compatible and supports both the new and legacy DFU". This is where my question stems from:

If I create a BLE Device with DFU Functionality from prior to SDK 12, how do I tell my Android Application that the target device does not require the keys that are needed in the more recent SDKs? I hope this clarifies my question.

[Edvin]

tjhasan said:

After SDK 12, Nordic introduced "Secure DFU" which uses a public-private key sharing to ensure that the firmware being sent is from a trusted vendor and not just anyone (which was the case pre SDK 12). However, the "Insecure DFU" implementation is still available and vendors still use it today. Hence my question.

OK, I understand. You are talking about the non-secure DFU from the nRF5 SDK.

tjhasan said:

If I create a BLE Device with DFU Functionality from prior to SDK 12, how do I tell my Android Application that the target device does not require the keys that are needed in the more recent SDKs? I hope this clarifies my question.

As it says from the documentation you are pointing to, it is backwards compatible, so from a higher level, you don't actually need to know whether the image is signed or not, which again suggests that there is really no point in going through the work that it is to remove the security, for then to add it back in later.

My first concern, if you go back too many SDK versions (before SDK12), then the DFU service will change the service UUID (or to put it in another way, the UUID was changed at some point). If you struggle with the DFU, check whether the service UUID is the same in SDK 17 as the SDK you are using now.

tjhasan said:

It looks like the DFU Library was moved to its own Github Repo.

Yes, it has a separate github repo, but it is still the same DFU library that is used in the nRF Toolbox, so I suggest you look there at how it is used. 

Just in case we are looking at an XY problem here. Did you attempt to do the secure DFU? Or did you attempt to perform a non-secure DFU? If so, what issues did you run into that made you create this ticket?

Best regards,

Edvin