unique private keys per device during OTA DFU

RE: unique private keys per device during OTA DFU

Vidar Berg — Thu, 29 Jun 2023 12:32:24 GMT

[quote userid="26310" url="~/f/nordic-q-a/100975/unique-private-keys-per-device-during-ota-dfu/433655"]it is already known to both sides[/quote]

This is what I meant. I was not concerned about how the key was distributed in the first place. The private key is not supposed to be known by either of the devices when using our DFU solution.

[quote userid="26310" url="~/f/nordic-q-a/100975/unique-private-keys-per-device-during-ota-dfu/433655"]can we just send the binary image through the Android DFU library instead of the zip with the manifest/DAT files?[/quote]

The manifest file can be omitted, but you will need the generated .dat file if you are going to use our dfu protocol and DFU library.

RE: unique private keys per device during OTA DFU

Omri Friedman — Thu, 29 Jun 2023 11:14:12 GMT

we are not sharing the private key. it is already known to both sides (private key, not shared over the air) - the application (on the Android side) and the firmware (on the device side).

can we just send the binary image through the Android DFU library instead of the zip with the manifest/DAT files?

RE: unique private keys per device during OTA DFU

Vidar Berg — Thu, 29 Jun 2023 10:13:59 GMT

nrfutil is not available for Android, unfortunately. If you are going to implement this, you can use the python source as a reference. However, wouldn't it be better if you could avoid having to distribute the private key like this? Have you considered having a "signing service" hosted on a web server?

RE: unique private keys per device during OTA DFU

Omri Friedman — Thu, 29 Jun 2023 08:25:33 GMT

one more related question - we need to create zip from binary image on our Android device.

This is done after we encrypt the binary image.

We cannot use nrfutil.exe on Android OS.

Do you have Android utility to do that? or alternatively - can you explain how you create the DAT file and how you ZIP by nrfutil?

RE: unique private keys per device during OTA DFU

Vidar Berg — Mon, 19 Jun 2023 10:08:58 GMT

OK, it sounds like you have a plan on how to solve this. I will leave the ticket open in case you have any follow up questions.

RE: unique private keys per device during OTA DFU

Omri Friedman — Fri, 16 Jun 2023 06:40:42 GMT

[quote user="vibe"]So, what you are saying is that any device that can establish a secure connection with your product should also be able to change the public key?[/quote]

yes, but i think the easier way is to use our other option i have mentioned, which entirely bypasses the DFU and uses our proprietary encryption/authentication methods.

[quote user="vibe"]But how do you intend to apply these modifications to units you already have out in the field?[/quote]

on the field we already have a unique keys per any device, and the host knows this private keys. so our steps would be:

1. host takes the zip file it needs to send to the device

2. host extracts the binary and encrypts/authenticates this entire file using our private keys

3. host makes zip out of it

4. host performs FOTA as usual with the nRf DFU on the device.

5. we modify the device side nRf bootloader to also be able to decrypt/de-authenticate the file

6. the nRf bootloader on the device side decrypt/de-authenticate the file (since it has the set of private keys which it uses for device/host routine communication)

RE: unique private keys per device during OTA DFU

Vidar Berg — Fri, 16 Jun 2023 06:28:39 GMT

As I mentioned in my previous response, if you are using the original bootloader, the only way you will be able to update the firmware over-the-air is by signing each update individually. Note that this update may include the bootloader with a new public key.

[quote user="Omri F"]secure connection with the device over BLE. this means it is encrypted and authenticated using private (!)[/quote]

So, what you are saying is that any device that can establish a secure connection with your product should also be able to change the public key?

[quote user="Omri F"]alternatively we can just apply the same encryption/authentication on the binary image and modify the dfu code to use it on it side with the same private keys we use. is that makes sense?[/quote]

But how do you intend to apply these modifications to units you already have out in the field?

RE: unique private keys per device during OTA DFU

Omri Friedman — Fri, 16 Jun 2023 05:48:26 GMT

we have a secure connection with the device over BLE. this means it is encrypted and authenticated using private (!) keys etc. so we can use this channel to send new public key, modify the DFU so it would take this key from where we place it....

alternatively we can just apply the same encryption/authentication on the binary image and modify the dfu code to use it on it side with the same private keys we use. is that makes sense?

RE: unique private keys per device during OTA DFU

Vidar Berg — Thu, 15 Jun 2023 20:21:46 GMT

If you haven't modified anything in the bootloader, the only way you will be able to update your devices will be to sign each update individually and ensure you send the update to the correct device. So, you will need some kind of database to keep track of which signing key to use for each device.

[quote user="Omri F"]our walkaround may be to send a unique public key over the air using our secured connection BEFORE we start an update, and then do the update with this public key. [/quote]

Sorry, but I'm not sure I understand what you mean here. If the public key could be updated on the DFU target, then what would prevent an attacker from doing the same?

RE: unique private keys per device during OTA DFU

Omri Friedman — Thu, 15 Jun 2023 20:02:43 GMT

our cyber security requirements forces us to have a unique key per every device. it does not matter if it is public or private. if we use the same keys, it is assume unsafe security wise, since we assume an attacker will gain control over our secret key (unless it is a different key per device).

Our concern is that an attacker with the keys can send a malicious firmware image using nRF EVAL to any of our devices. only with a unique key per each device, we are safe cyber-security wise.

our walkaround may be to send a unique public key over the air using our secured connection BEFORE we start an update, and then do the update with this public key.

hope i understood correctly your implementation....

RE: unique private keys per device during OTA DFU

Vidar Berg — Thu, 15 Jun 2023 18:39:12 GMT

None of the keys are exchanged over the air. The public key is embedded into the bootloader image (defined in the dfu_public_key.c file) and is used to verify if an update has been signed with the private key, see 'Signature verification' for more details.

Could you please explain how you made the keys and how you provisioned them? Did you generate private/public 100 key pairs?

RE: unique private keys per device during OTA DFU

Omri Friedman — Thu, 15 Jun 2023 15:46:06 GMT

we do base it on nRF5 SDK. So how does the private key used? if i change the private key on the host side, then how does the far end device learns about it? only the public key is sent over the air. correct?

RE: unique private keys per device during OTA DFU

Vidar Berg — Thu, 15 Jun 2023 10:15:39 GMT

Hello,

We don't store the private key on the device in our secure DFU solution. Have you based your bootloader on our bootloader from the nRF5 SDK or some other bootloader? Either way, if you have a unique key on each device, I imagine you will need to sign each update based on what device the update is meant for.

Best regards,

Vidar