Encryption of FW images when using MCUBoot + SMP Server for DFU

[clockis]

Greetings,

We are developing a new product based on the nRF52840 and have been using MCUBoot + SMP Server + MCUMgr for DFU via Serial & BLE on our application with great success up to now.

We want however to have encrypted .bin & .zip (for Serial & BLE DFU respectively) so that reverse engineering our FW from the binaries is not possible.

We also want to have downgrade protection so that only newer versions can be updated on the device.

When adding the following configuration options on the MCUBoot (using a .conf file in the child_image folder of our project) configuration to enable encryption of the FW image generated we get the following error:

(documentation used:  Enryption , Encryption ticket #1, Encryption ticket #2 , Downgrade prevention)

configuration options for MCUBoot - mcuboot.conf

# Encryption configuration
CONFIG_BOOT_SERIAL_ENCRYPT_EC256=y
CONFIG_BOOT_ENCRYPTION_KEY_FILE="C:/ncs/feel_v2_fw/feel_v2_fw/child_image/keys/feel_encrypt_priv.pem"

CONFIG_BOOT_ECDSA_TINYCRYPT=y

CONFIG_SINGLE_APPLICATION_SLOT=y

Error:

In file included from C:\ncs\v2.1.0\bootloader\mcuboot\boot\bootutil\src\bootutil_public.c:43:
C:/ncs/v2.1.0/bootloader/mcuboot/boot/bootutil/src/bootutil_public.c: In function 'boot_swap_type_multi':
c:\ncs\v2.1.0\bootloader\mcuboot\boot\zephyr\include\sysflash\sysflash.h:15:40: error: 'PM_MCUBOOT_SECONDARY_ID' undeclared (first use in this function); did you mean 'PM_MCUBOOT_PRIMARY_ID'?
   15 | #define FLASH_AREA_IMAGE_SECONDARY(x)  PM_MCUBOOT_SECONDARY_ID

What could be the reason for this? Are we missing any configuration options?

Also as a follwup question, is it easier/better to use the nRF Secure Immutable Bootloader as the first stage? Does this bootloader feature encryption of the generated FW images?

I also understand that it features roll-back protection. Can you confirm this?

Thank you very much!

Best regards,

Stavros

[Sigurd]

Hi

If you have a pm_static.yml file, then try to remove the mcuboot_secondary label in that file if present.

Note that Encrypted DFU is feature we do not officially support in our SDK, even though it is made available through the mcuboot project.

Some links that you might find useful:

 RE: nRF52840 + NCS + MCUBoot, CC310-enabled image encryption? 

 How to encrypt FW for MCUBOOT image update? 

[clockis]

Hi Sigurd,

Kind reminder if you have any information on the previous questions and also a similar question that came up.

In the case that the config option CONFIG_SINGLE_APPLICATION_SLOT is enabled can the device revert to the previous FW image if the DFU process fails at any point (e.g. because of a disconnection during the transfer of the image etc.)?

Thank you and I look forward to hearing from you!

BR

Stavros

[Sigurd]

Hi,

Looks like single slot application is the only thing that works. For your boot_handle_enc_fw error, see this comment:  RE: MCUBoot with serial UART and image encryption 

clockis said:

In the case that the config option CONFIG_SINGLE_APPLICATION_SLOT is enabled can the device revert to the previous FW image if the DFU process fails at any point (e.g. because of a disconnection during the transfer of the image etc.)?

No, if the DFU process fails in a single-slot DFU, then you would need to retry the DFU.

[clockis]

Hi,

Yes I have checked this solution and I have tried it but the build fails with the error indicated in the original post of this thread (see the original post at the top of the thread)

In file included from C:\ncs\v2.1.0\bootloader\mcuboot\boot\bootutil\src\bootutil_public.c:43:
C:/ncs/v2.1.0/bootloader/mcuboot/boot/bootutil/src/bootutil_public.c: In function 'boot_swap_type_multi':
c:\ncs\v2.1.0\bootloader\mcuboot\boot\zephyr\include\sysflash\sysflash.h:15:40: error: 'PM_MCUBOOT_SECONDARY_ID' undeclared (first use in this function); did you mean 'PM_MCUBOOT_PRIMARY_ID'?
   15 | #define FLASH_AREA_IMAGE_SECONDARY(x)  PM_MCUBOOT_SECONDARY_ID

So I am not really sure what is missing that causes this error.

Sigurd said:

No, if the DFU process fails in a single-slot DFU, then you would need to retry the DFU.

The device cannot perform DFU if the FW image of the application is not present and active on the device as it uses the MCUMgr to perform DFU, which is part of the application (DFU cannot be retried as it is not performed by the MCUBoot itself but by the application using MCUMgr) so does this mean if the DFU fails in Single-Slot mode the device is unrecoverable(stays forever in Bootloader mode)?

On another note, I was talking with some members/contributors to the Zephyr Project in the Zephyr Discord to learn more about how to achieve the encrypted FW images using the MCUBoot that is already included in our application and I was informed that

1. The MCUBoot code is currently being reworked to support FW image encryption
2. It could possibly be included in the upcoming NCS SDK release.

Could you please confirm if this is indeed the case?

Finally, I would like to know, in the case the new SDK release includes this encryption feature, what are the steps to migrating from a previous version of the SDK (v2.1.0) to the latest one and if there is relevant documentation or a guide you could point me to so I can be prepared if this does occur.

Thank you very much for the support and I look forward to hearing from you!

Best regards,

Stavros

[Sigurd]

Hi,

clockis said:

The device cannot perform DFU if the FW image of the application is not present and active on the device as it uses the MCUMgr to perform DFU, which is part of the application (DFU cannot be retried as it is not performed by the MCUBoot itself but by the application using MCUMgr) so does this mean if the DFU fails in Single-Slot mode the device is unrecoverable(stays forever in Bootloader mode)?

In Serial Recovery Mode / single slot, the the bootloader is receiving and writing to the slot. The bootloader is not updated. If something breaks during the DFU, then just retry the DFU.

clockis said:

On another note, I was talking with some members/contributors to the Zephyr Project in the Zephyr Discord to learn more about how to achieve the encrypted FW images using the MCUBoot that is already included in our application and I was informed that

1. The MCUBoot code is currently being reworked to support FW image encryption
2. It could possibly be included in the upcoming NCS SDK release.

Could you please confirm if this is indeed the case?

There might be some plans here, but I'm not aware of them. For roadmap questions, you should contact your local Nordic Semiconductor sales representative

[clockis]

Sigurd said:

In Serial Recovery Mode / single slot, the the bootloader is receiving and writing to the slot. The bootloader is not updated. If something breaks during the DFU, then just retry the DFU.

Our device does not have a reset button so If I understood correctly cannot be setup to enter Serial Recovery mode. Is there any other way to enter Serial recovery mode that I am not aware of?

Sigurd said:

There might be some plans here, but I'm not aware of them. For roadmap questions, you should contact your local Nordic Semiconductor sales representative

Ok, will do, thank you!

[Sigurd]

clockis said:

Our device does not have a reset button so If I understood correctly cannot be setup to enter Serial Recovery mode. Is there any other way to enter Serial recovery mode that I am not aware of?

The Serial Recovery mode is usually activated if a pin is held high at boot, but the mode can also be activated for some time at each boot. So if you can make the app trigger a SW reset, then you will have a time window where you can enter Serial Recovery mode.

You might find this repo here created by a colleague of mine useful: https://github.com/hellesvik-nordic/samples_for_nrf_connect_sdk/tree/main/bootloader_samples/serial_recovery

[clockis]

Sigurd said:

but the mode can also be activated for some time at each boot

Ok, I see, a functionality like this is very useful!

Thank you very much I wasn't aware of this!