Which secure firmware to use and how to it onto a nfr5840 USB Dongle to connect with the OpenThread Border Router.

[rocksetta]

I have 3 Fanstel USB 840F Dongles which have the  nfr 52840 inside. I want to connect one of them to the OpenThread Border Router using a Linux machine (Ubuntu 18.04), but they are expecting secure software. I either need a public signed software or how to sign the correct software to install.

What I have so far:

nrf-connect working and can view the dongle in DFU mode

I have the NRF SDK nRF5_SDK_15.2.0_9412b96

I have nrfpro and mergehex programs

I have wpantund working

I have Openthread docker installed on my linux machine

I have the OpenThread border router working and can view the local webpage.

I downloaded pre-made NCP software   https://openthread.io/guides/ncp/ot-ncp-ftd-gae2b0194-nrf52840.tar.gz   to install on the dongle.

Issue: The pre-made NCP software shows up on nrf-connect but the write button is greyed out. I think it is because the dongle is expecting secure firmware and the pre-made NCP software is for non-secure installations.

I have signed android app software before but have no idea of the signing  process for firmware.

[rocksetta]

So it looks like I just have to use nrfutil to sign the firmware.hex files. Still don't really know the process. but at least I now have something I can lookup.

[bjorn-spockeli]

Hi Jeremy, 

Has Fanstel provided you with a private key that you can use to sign the Pre-Built NCP Firmware from OpenThread.io ? 

I'm not sure if you will be able to perform an update with the precompiled binary from OpenThread as its overlapping the MBR section 0x0000-0x1000 and thats why the write button is greyed out.. The Thread NCP Example in the nRF5 SDK for Thread and Zigbee comes in four configurations, where one of them is USB with bootloader. This configuration uses the USB peripheral that is available in nRF52840 and communicates as a native USB CDC device. This configuration targets PCA10059 board that contains factory-programmed USB bootloader. 

I have attached a the precompiled binary for the USB bootloader configuration below, could you try to use that one instead?

nrf52840_xxaa.hex

[rocksetta]

Thank you so much for the reply. A private key from Fanstel would make so much sense, but I got nothing on paper with the purchase, I just emailed them.  On my windows machine the bootloader and cli .hex files come up with "write" enabled but then the install dies since the fanstel expects a signed file.

Just checked my email and they say the bootloader is pre-installed. The link is here

https://www.fanstel.com/download-opensource/

With an install  here 

www.fanstel.com/.../BT840_USBbootloader181018b.rar

That seems positive

But to connect with the OpenThread border router I am going to need to know some connection information from  Fanstel. Any suggestions for this step? A few of them like the network Name and passphrases I make up but the PAN ID etc?

[rocksetta]

Thanks for the .hex file. I did get a debug private key from Fanstel. It looks like I need a Jlink with another board if I want to wipe the Fanstel USB Dongle clean to be able to use my own private key, but that is fine I am just testing anyway.

Do you think with nfrConnect for Desktop that I can just take your .hex file and the keys and make a package that will install? That seems a lot easier than what many posts are suggesting I do where I build the files from scratch.

I will try doing things on my own but if you have a link showing how to sign the firmware .hex file that would be really useful.

[bjorn-spockeli]

Hi Jeremy, 

If you want to generate your own keys, then you should be able to update the bootloader of the Fanstel USB to a bootloader with your public key in it through a DFU since you have the private key that corresponds to the public key in the Fanstel bootloader. If that is not possible then you'll have to erase the Fanstel bootloader with a programmer and then flash your own.  

You create a signed firmware image using the nrfutil pkg generate command, see the documentation here. However, you should only have to pass the .hex file I attached to the Programmer App and then it will generate the firmware image and perform the update of the application firmware. 

[rocksetta]

Things are looking up. The following line compiles

nrfutil pkg generate --hw-version 52 --sd-req 0x80 --bootloader-version 4 --bootloader nrf52840_xxaa.hex --key-file private.pem outputBoot/nrf52840_xxaa.zip

And I see

So things are looking good.

Couple of questions:

The .hex file you sent, was it compiled with your own public.c key or does it have no key?

I am starting to understand. Your bootloader is needed before I try installing my Border Router Application. 

Too bad the .dat file inside the .zipped output is binary. If that could be edited I could simple replace the public key. Any idea how to edit the .dat file?

I did get this line working

nrfutil dfu usb-serial -p /dev/ttyACM0 -b 9600 -pkg ncp-signed.zip 

except I did not have your bootloader so it tried to work but couldn't iwht a non-matching softdevice

I just tried your bootloader and I get the same error.

Error 0x07: The arrayof supported SoftDevices for the update does not contain the FWID of the current SoftDevice. 

Any suggestions.

P.S. I had to do

chmod 777 /dev/ttyACM0 to get the port active.

[bjorn-spockeli]

Hi Jeremy, 

the hex file I attached is the NCP firmware configured to be compatible with devices that has a USB bootloader, i.e. it starts at 0x1000 instead of 0x0000. It does not contain a bootloader, hence it does not have any public key in it. 

Secure DFU works the following way: A private key is generated, from this private key a public key is generated. The private key is used to sign the firmware image that is used to update the firmware of a device, referred to as the DFU target. The public key is placed in the bootloader code on the DFU target and is used to verify if a firmware image is signed with the private key or not. 

So there is no need to edit the .dat file, nrfutil places the signature in this file when you generate the firmware image with the pkg generate command. You can specify multiple softdevice versions with the --sd-req command as a comma separated string, i.e. 

--sd-req 0xA9,0xAE

As mentioned above the hex fiel i attached is not a bootloader, but application code so you should generate the .zip package as follows

nrfutil pkg generate --hw-version 52 --sd-req 0xA9,0xAE  --application-version 1 --application nrf52840_xxaa.hex --key-file private.pem outputBoot/nrf52840_xxaa.zip

Just make sure that you also generate the settings file with application-version set to 1 otherwise you will not be allowed to perform the update. The application version of the new image must be equal or higher than the one present on the DFU target for the image to be accepted by the bootloader. 

[rocksetta]

Thanks for the awesome reply. I am getting there. I have 3 Fanstel Dongles.

I tried your suggestions (minus the excellent idea to update the version settings, I just used version 6 as a guess).

I did 

chmod 777 /dev/ttyACM0

nrfutil dfu usb-serial -b 9600 -p /dev/ttyACM0 -pkg nrf52840_xxaa.zip

To my surprise it installed.

Even said on the command line that it was installed.

Yeh.

...

now it's a brick.

No worries I have 2 more. 

First question. These Dongles have 2 buttons, once you take off the pretty covering, but I can't find a button combination to put the Dongle back into DFU mode?

NRC Connect for Desktop used to prove it was in DFU mode (but I can't install a package with nrfConnect for Desktop only .hex files.) 

Now even with nrfConnect for Desktops it will not go into DFU mode. 

Any suggestions.

Should I try the next Dongle but do the settings commands, I have found this example

nrfutil settings generate --family NRF52840 --application nrf52840_xxaa.hex --application-version 3 --bootloader-version 2 --bl-settings-version 1 settings.hex

The only problem is I don't know either of these settings since they were made by Fanstel

--bootloader-version 2 --bl-settings-version 1



On a positive note>\: I used an extension USB cable to be able to activate 
the very hard to reach button so I can now get the device back into DFU mode. 


I will try messing with the nrfutil settings
Any other ideas.