How to configure so that both immutable and upgradable bootloader are MCUBoot

RE: How to configure so that both immutable and upgradable bootloader are MCUBoot

AHaug — Tue, 21 May 2024 13:37:27 GMT

Hi,

It is as you state no documentation or samples for a second stage MCUboot on top of a first stage MCUboot due to there not being any support for this. It is not impossible to do, but you are 100% on your own w.r.t creating this and really not recommended due to all the considerations with security and SPU regions. MCUboot is originally created to be a first stage bootloader and NSIB is something Nordic has created to allow for MCUboot to be an uppgradable second stage bootlaoder.

Kind regards,
Andreas

RE: How to configure so that both immutable and upgradable bootloader are MCUBoot

franchan — Fri, 17 May 2024 14:29:33 GMT

Hello Andreas,

Thank you for your reply! For my deeper understanding, I have these additional question:

... as we don't support FW decryption in NSIB ...
Thank you for confirming the NSIB cannot be used for such purpose (only checking signatures). Could you confirm that it is impossible to configure a 1st stage MCUBoot (instead of NSIB) image as immutable and a different 2nd stage mutable MCUBoot image? I did not find documentation nor a sample illustrating such use case.

Kind regards, francis

RE: How to configure so that both immutable and upgradable bootloader are MCUBoot

AHaug — Wed, 15 May 2024 11:57:12 GMT

Hi,

Here's a summary of the discussion I had with

Upgradable MCUboot and keys in the firmware image is not supported as we don't support FW decryption in NSIB and any custom implementation will have to be a proprietary solution. NSIB only does signature validation of the second stage bootloader and chooses to boot into it if the signature is valid.

So what we understand your motivation as is that you wish to do this because of an assumption (or custom implementation) that your private keys can not be a part of a MCUboot image, which is why you say you need to have encryption of the second stage bootloader as well. To encrypt MCUboot to be able to store a key in the FW image is not a secure solution and will only give you a false sense of security. The only keys that is recommended to keep within MCUBoot FW image which you send as FW upgrade are public keys.

Instead we recommend that you use Key Management Unit (KMU) to securely handle your keys. This will also protect the keys from hostile accessing through the CPU. Symmetrical keys or private keys used for DFU needs to be placed on the device during production, and with the nRF5340 you have the option to put the keys within the KMU.

Here's some samples and documentation that showcases and explains KMU some more:

Do also note that as a side note that MCUboot does also support symmetrical keys (AES KW) and private keys (ECIES, where a hybrid algorithm that uses ECC-keys does a handshake to set up symmetrical FW encryption keys. Both of the must under no circumstances be sent over the air.

To summarize we recommend that you store the keys in KMU and use MCUboot as is with TF-M enabled. FW keys on a device without TF-M enabled will cause that anyone that has local access will be able to decrypt whatever they wish with the key or to do any other hostile actions.

Kind regards,
Andreas

RE: How to configure so that both immutable and upgradable bootloader are MCUBoot

AHaug — Tue, 14 May 2024 12:44:49 GMT

Hi,

I've picked up your case and will ask the bootloader team for clarification on some of your question. I will write you a summary of the discussion when we have a conclusion, hopefully within tomorrow.

Kind regards,
Andreas