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]

Hello Sigurd,

Development on this issue has just been continuing after being on hold for a while.

I understand that this is not officially supported by NCS right now but I would appreciate any support on the following issue.

I have currently tried to build my application using the following config options on the mcuboot.conf fragment (.conf file in the child_image folder of our project)

CONFIG_BOOT_ENCRYPT_EC256=y
CONFIG_BOOT_ENCRYPTION_KEY_FILE="../mcuboot/keys/my_custom_encrypt_priv.pem"
CONFIG_BOOT_ECDSA_TINYCRYPT=y

However, after building, I get the following error:

c:/ncs/toolchains/v2.1.0/opt/zephyr-sdk/arm-zephyr-eabi/bin/../lib/gcc/arm-zephyr-eabi/10.3.0/../../../../arm-zephyr-eabi/bin/ld.exe: zephyr/libzephyr.a(boot_serial.c.obj): in function `bs_upload':
C:\ncs\v2.1.0\bootloader\mcuboot\boot\boot_serial\src\boot_serial.c:565: undefined reference to `boot_handle_enc_fw'
collect2.exe: error: ld returned 1 exit status
ninja: build stopped: subcommand failed.

 - Could you please provide some insight on this? ( I have also checked this ticket but it is not     helpful https://devzone.nordicsemi.com/f/nordic-q-a/92587/mcuboot-with-serial-uart-and-image-encryption/389489?focus=true )

- Also, I have noticed this statement on the MCUBoot repository, it essentially states that the encryption of FW images is only available for Single Application Slot mode which is not acceptable for us as we want to always have a secondary slot in case the DFU process fails at any point (and the device can revert back to its old image). Could you please confirm this?

Thank you

Best regards,

Stavros

[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