Subject: Security Concern Regarding OTA and Signed Firmware Reproduction

[mehmetefe]

Hello Nordic Team,

I’m currently working with the nRF5340-DK and nRF Connect SDK (v2.6) using VS Code. I’ve been testing OTA firmware update processes using MCUboot and signature verification.

I’d like to describe a scenario I encountered and ask for clarification regarding secure firmware update enforcement.

---

Scenario:

1. I created a firmware image, signed it using my private key (standard MCUboot RSA signing).

2. I successfully performed an OTA update and verified the image was accepted.

3. I then took that signed image (or the project ZIP), moved it to another computer.

4. On this new machine, I deleted the original build/ folder and re-built the firmware, making minor changes.

5. I then re-signed the firmware using the same private key, and attempted to OTA update the same device again.

6. Surprisingly, the device accepted and installed the modified image.

---

Concern:

Since the firmware was modified and re-signed on a completely different machine, I expected the device to reject the new image. However, it appears the device still accepts any image as long as it is signed — even if it's been modified or generated outside of the trusted build environment.

This raises a concern:

If someone obtains the private key, they can generate their own signed firmware, even if they are not the trusted developer.

---

My Questions:

1. Is there a way to prevent re-signed or modified firmware from being accepted — even if the private key is the same?

2. How can I ensure that only firmware coming from a trusted build environment can be updated OTA on the device?

3. What is the recommended production practice to:

   • Avoid signing firmware on local machines

   • Embed public key securely on the device

   • Ensure that only legitimate, versioned, untampered firmware is accepted

Any advice, documentation, or verification on best practices (CI-based signing, manifest usage, anti-rollback, etc.) would be highly appreciated.

---

Additional Details:

• Device: nRF5340-DK

• SDK: nRF Connect SDK v2.6

• OTA Update via: MCUboot + Zephyr

• Tools: imgtool for signing, VS Code, west build

---

Thanks in advance for your support and clarification.

Best regards,
[Mehmet Efe Öten]

[Kenneth]

Hi,

As long as the firmware is signed with the same private key that the device trusts, MCUboot will happily install it, regardless of where or how it was built. That’s by design — MCUboot is purely a signature-verification bootloader, and it has no concept of “trusted build machine” or “original developer” beyond the cryptographic key.

So if the signing key is the same, the firmware will pass authentication. This means your real root of trust is that private key. If it’s compromised, an attacker can sign and install arbitrary firmware.

To prevent this scenario, you need key control. 

First and foremost: Never sign firmware on developer workstations. Keep the private signing key offline or in a dedicated signing server.

Developers can build unsigned firmware locally, but only the CI can sign and publish “release” images. This means:

Local testing uses unsigned builds (or uses a test key that is not in production devices).

Production devices only accept firmware signed by the production key.

Kenneth