Using MCUboot with secure private key

[simonhwm]

The current default and only recommended way to use MCUboot is to make the private key available as part of the build process.

There have been several questions about this previously, asking whether the private key can be kept private, and the answer always seems to be to point to a piece of sample code which is no longer maintained, which does everything manually.

github.com/.../mcuboot_manual_sign

As of 1 August 2025 we are required to meet the robust cyber security requirements of the Radio Equipment Directive if we want to sell in the EU with a CE mark.

Having the private key exposed in this way definitely does not meet these requirements. We are told that the private key must be locked away in a vault and not accessible to developers. We can request a signature but we can't access the private key, so the default build process is broken for any product targeting EU sales.

Does Nordic Semiconductor have any plans to help us out with this? It's great having an automated build system like Zephyr's but a nightmare if you ever want to do anything different from the default.

Simon

[simonhwm]

The first problem is that in order to do what you suggest, I cannot use the supported build process. I will need to hack something together based on sample code which you (i.e. support agents in other threads) say is outdated and not maintained to the current NCS.

devzone.nordicsemi.com/.../518181

And it's not something that's easy to automate as it relies on doing a partial build, changing a key file and then making sure not to do a pristine build.

Keys locked in a vault might seem stupid - I thought that too when I first started out on this process - but the signing key must remain private for the lifetime of the product, maybe 20 years, and if it's compromised then the security of all those products is also compromised. Best practice is that the private key is stored securely in an HSM, key vault (server, not a steel box) or other secure storage. You can never export or see the private key; all you can do is log in to the secure store and request a signature for a file, or for a hash you've already taken. Imgtool always wants to create the signature itself, so it needs direct access to the private key.

This part I can probably deal with. The signed file format is pretty simple, just the unsigned binary sandwiched between a fixed format header and a TLV trailer containing the signature, so it's not too hard to re-create.

But the point is it shouldn't need hackery and reverse engineering to do this. There should be an easy way to build the bootloader with only the public key file. There should be a way to generate the signed binary with the signature coming from an external source. RED has just landed and everyone is trying to catch up. The Cyber Resilience Act is not far away and that will be even more stringent. All the individual parts are there to make this work, just not very well joined up at the moment.

[Sigurd Hellesvik]

Hi Simon,

You make some good points on this.

Here is what I got as answers:

1. As you can see at https://github.com/mcu-tools/mcuboot/issues/599 (Issue name: Add HSM support to imgtool ), it looks like MCUboot upstream is working towards a solution for this. When that is ready, it will eventually be available in the nRF Connect SDK as well.

2. You can read more on what we do with RED DA at What is the RED Delegated Act and associated standard (our page on this). Maybe this answers your question on if this will be good enough for RED DA?

3. I will forward your messages to our Bootloader team, as I think this will be good input for them.
Of course, I cannot promise you anything on this front, but know that you are heard. If learn anything from them that I can share, I will let you know.

Are these the answers you were looking for?

Regards,
Sigurd Hellesvik

[simonhwm]

Hi Sigurd,

Good to see that MCUboot has something in the works, albeit moving very slowly. I appreciate that you are dependent on a 3rd party for this.

We are working with a consultant on RED DA so most of this comes from his recommendations.

My biggest concern was making the bootloader build without requiring the private cert, which I think relates to the way Zephyr/NCS builds MCUboot rather than being a problem with MCUboot itself.

Thanks for your answers, I will be interested to hear of any developments.

Simon

[Sigurd Hellesvik]

simonhwm said:

My biggest concern was making the bootloader build without requiring the private cert, which I think relates to the way Zephyr/NCS builds MCUboot rather than being a problem with MCUboot itself.

If you only mean the bootloader and not the signing of the application, the nRF54L15 uses the KMU to store the public key, which you must provision manually. So for this, MCUboot builds without a private key.

simonhwm said:

We are working with a consultant on RED DA so most of this comes from his recommendations.

One more thing here that I came to think of. A logical argument is as follows:

If Nordic Semiconductor cannot sell SoC to products sold in the EU, the loss of revenue would be way too large to accept.
=> Nordic Semiconductor must make sure that our SoCs meet requirements for RED DA and eventually CRA.

So  while you say "Having the private key exposed in this way definitely does not meet these requirements.", I would argue that following the above logic, I would think that the way we use the private key should be good enough for RED DA.

(PS: The above are logical arguments made by me personally, and not promises from Nordic Semiconductor)

If you (or anyone else) experience that you cannot achieve RED DA because of the nRF Connect SDK key handling, we would be interested in knowing that!

[simonhwm]

Alas we are using the nRF52840. We would have picked from the nRF54L range, but at the time we started the project it was not yet available to buy.

Provisioning the public key manually is absolutely fine, so it seems it's just a problem for the older device family.