nrfutil.exe, keys for signing only, or also cyphering ?

[Stef]

Hello,

If we use keys with DFU nrfutil.exe, is the new firmware in the DFU package only signed or also ciphered ?

The real question is:

• do we prevent unwanted uploading of a foreign unsigned firmware into our existing device (a firmware which would not be signed with out private key) ?

• do we protect our IP from being stolen by reverse engineering our DFU package (by ciphering the new firmware in the DFU package with our private key) ?

Since the DFU package is exposed while upgrading devices in the field, how can we protect it ?

Which key from my private.pem (private/public) is used where and how (in nrfutil.exe, in the device itself) ?

Since your documentation is not very detailed regarding this process, could you please explain how this all works ?

Best Regards, Stef

[bjorn-spockeli]

Hi Stef,

• Do we prevent unwanted uploading of a foreign unsigned firmware into our existing device (a firmware which would not be signed with out private key) ?

Yes, firmware packages that are not signed or signed with an incorrect public key will be rejected by the bootloader.

• Do we protect our IP from being stolen by reverse engineering our DFU package (by ciphering the new firmware in the DFU package with our private key) ?

No, the keys generated using nrfutil v1.5.0 are only used for signing the firmware packet, i.e. the firmware image is not encrypted. nrfutil will generate two keys, one private key that is used to sign the firmware image and and one public key that is generated from the private key, which is used to verify that the firmware image was signed by said private key.

The public key is added to the bootloader source code and the private key should be kept safe. Note that it is not possible to derive the private key from the public key.

The easiest way to ensure that the firmware image is not sniffed is to encrypt the link by bonding to the device in bootloader mode prior to sending the firmware image. If both sides of the link support BLE v4.2, then you can use the LE Secure Connections feature that uses ECDH cryptography to encrypt the link.

However, you still have to get the firmware image to the mobile device that is updating the nRF5x device without an unauthorized party getting hold of the firmware. Thus, if you want end-to-end encryption you will have encrypt the firmware image prior to signing it and add a de-cryption step in the secure bootloader when the image is written to flash.

Best regards

Bjørn