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

[franchan]

Hello,

I'm using the nrf5340 and nrf Connect SDK 2.6.1.

Currently the MCUBoot is immutable and the cpuapp image is encrypted (it contains IP and secrets). The MCUBoot is kept confidential to not leak the private key.

We now want the MCUBoot to be upgradable as well. I only find documentation on using the NSIB as immutable bootloader and MCUBoot as second stage. But NSIB  does not support encrypted images?

Is there a way or sample to configure the prj.conf to use MCUBoot as both immutable and upgradable bootloader?

If not possible, how to protect the private key in the second stage bootloader. One way would be to store it during manufacturing in the OTP (it would mean the 2nd stage bootloader always works with this fixed key)? The documentation says that only the NSIB should use the bootloader storage library.

Thanks for any advice!

Kind regards,
francis

[AHaug]

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

[AHaug]

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:

• https://docs.nordicsemi.com/bundle/ncs-latest/page/nrf/samples/tfm/provisioning_image/README.html 
• https://docs.nordicsemi.com/bundle/ncs-latest/page/nrf/samples/keys/hw_unique_key/README.html 
•  And the blogpost Persistent storage of keys and data using the nRF Connect SDK  

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

[franchan]

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

[AHaug]

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