Using MCUboot with secure private key

RE: Using MCUboot with secure private key

simonhwm — Fri, 22 Aug 2025 15:08:05 GMT

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.

RE: Using MCUboot with secure private key

Sigurd Hellesvik — Fri, 22 Aug 2025 07:37:14 GMT

[quote user="simonhwm"]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.[/quote]

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.

[quote user="simonhwm"]We are working with a consultant on RED DA so most of this comes from his recommendations.[/quote]

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!

RE: Using MCUboot with secure private key

simonhwm — Thu, 21 Aug 2025 13:35:33 GMT

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

RE: Using MCUboot with secure private key

Sigurd Hellesvik — Thu, 21 Aug 2025 12:29:09 GMT

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

RE: Using MCUboot with secure private key

simonhwm — Wed, 20 Aug 2025 15:39:32 GMT

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.

RE: Using MCUboot with secure private key

Turbo J — Wed, 20 Aug 2025 14:20:19 GMT

What is the problem? Just have the secure machine generate/run the imgtool stuff that generates the signature for the "release" MCUboot.

Devs will work with a "devel" MCUBoot key that only work with the different dev/testing MCUBoot image.

Locked away in a vault seems stupid, you have to use it in order to generate the required firmware signatures. It has to have a method for you to put the hex to sign in and the finished image out. So its usually just another PC but one that is locked away physically when don't need to sign stuff.