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

[FARLY7]

Hi there,

I am working on a new product iteration that uses the nRF52840. Our existing application is already using nRF52832 + NCS + MCUBoot with image signing.

I would like to take this opportunity to enable image encryption in MCUBoot and use the CC310 crypto hardware accelerator to perform image verification and decryption. However, I cannot find a working KConfig configuration that enables image encryption on MCUBoot with CC310.

Normally I can eventually figure these configuration issues out, but this one is difficult. I cannot find a relevant example project, or similar questions on the devzone.

The main compiler errors I am getting are:

 #error "One crypto backend must be defined: either MBED_TLS or TINYCRYPT"

Could someone tell me what KConfig options are required, or point me to an existing sample project?

Thanks,

Sean

[Vidar Berg]

Hello Sean,

Encrypted DFU is feature we do not officially support in our SDK, even though it is made available through the mcuboot project. Also be aware that the solution does not utilize a secure key storage for the private key kept on the device. This means we cannot guarantee that the key cannot be extracted.

That said, the reason you are unable to build the bootloader in its current configuration is that the cc310 runtime library (nrf_cc310_bl crypto library) linked in by the bootloader only provide ECDSA and SHA-256 support. This sufficient to perform signature validation of the FW image, but not encryption/decryption. 

While it's not really what you want, a simple workaround would be to select the TINYCRYPT SW backend instead (CONFIG_BOOT_ECDSA_TINYCRYPT=y). The other alternative would probably be to integrate the full version of the cc310 library. This will require changes to the bootloader itself. If you end up trying this, then I think a good start is to take a look at the cc310_glue file here (https://github.com/nrfconnect/sdk-mcuboot/blob/main/ext/nrf) /cc310_glue.c and the include headers in https://github.com/nrfconnect/sdk-mcuboot/tree/main/boot/bootutil/include/bootutil/crypto. These files show the functions currently implemented for the cc310 backend.

You may also edit the imgtool sign command in ncs/nrf/modules/mcuboot/CMakeLists.txt if you want the build to encrypt the update binaries for you.

e.g.

diff --git a/modules/mcuboot/CMakeLists.txt b/modules/mcuboot/CMakeLists.txt
index 6dd442214..dffc07e35 100644
--- a/modules/mcuboot/CMakeLists.txt
+++ b/modules/mcuboot/CMakeLists.txt
@@ -149,6 +149,7 @@ if(CONFIG_BOOTLOADER_MCUBOOT)
       COMMAND
       # Sign the binary version of the input hex file.
       ${sign_cmd}
+      --encrypt <insert path or symbol here that points to your key file >
       ${sign_dependencies}
       --slot-size ${SIGN_ARG_SLOT_SIZE}
       ${to_sign_bin}

Best regards,

Vidar

[FARLY7]

Hi Vidar,

Thanks for the detailed answer.

We are aware of the vulnerabilities of storing the keys in FLASH but thank you for noting that - it is important for anyone else reading.

Ok, I understand why using the CC310 for MCUBoot encryption is currently unsupported. I have opted for the simple option from your suggestions, and I am now able to successfully compile. We can still use the CC310 in our application for signing operations.

There are two further related questions I would like to ask:

1. Your last point mentioned manually editing the ncs/nrf/modules/mcuboot/CMakeLists.txt file to automatically include encrypted binaries in the build process. However, I found the KConfig option CONFIG_MCUBOOT_ENCRYPTION_KEY_FILE, that says it's meant to perform this operation automatically? However, this KConfig option is not available unless I also specify CONFIG_MCUBOOT_SIGNATURE_KEY_FILE, and enabling this option results in the warnings below:

CMake Warning at /Users/FARLY7/workspace/um/catch-firmware-active/nrf/modules/mcuboot/CMakeLists.txt:630 (message):
CONFIG_MCUBOOT_SIGNATURE_KEY_FILE is set to
"./bootloader/mcuboot/catch-active-bloodaxe_gen2-sign-p256.pem".

You are using the NCS Mcuboot signing, which means this option will be
ignored.

Image signing in NCS is done via the MCUboot image's
CONFIG_BOOT_SIGNATURE_KEY_FILE option.

Consider setting CONFIG_MCUBOOT_SIGNATURE_KEY_FILE in your application
image back to its default value, the empty string.


It seems like this feature is not fully implemented or deprecated? I found this related GitHub Issue. We are already only using the CONFIG_BOOT_SIGNATURE_KEY_FILE as suggested, so is our only option to automatically generate the encrypted binaries to use your suggestion? I would rather not edit the CMakeLists.txt file directly, as we use different key files for different board builds, so it seems we will need to perform the encryption/signing separately.

2.  Not really a question, but I see the issue still exists where if the key file path provided is a relative one, CMake will print the false warning that MCUBoot is using the default key, when it is correctly using the provided key. (see here). I hope this is fixed soon, as it is quite confusing.

Thanks,

Sean

[eb12345]

I tried to build the sample application from the link above for the nrf52833dk board. It builds fine for the nrf5340dk, but not for the nrf52833dk. Below is a snippet of the build log, as I can't upload the complete log file.

<command-line>: warning: "MBEDTLS_CONFIG_FILE" redefined
<command-line>: note: this is the location of the previous definition
C:\ncs\v2.4.2\bootloader\mcuboot\ext\tinycrypt\lib\source\ctr_mode.c:33:10: fatal error: tinycrypt/constants.h: No such file or directory
33 | #include <tinycrypt/constants.h>

[Vidar Berg]

Please add 'CONFIG_BOOT_SIGNATURE_TYPE_ECDSA_P256=y' to the mcuboot.conf overlay in your child_image folder. This should remove the dependency on mbedtls and allow you to use Tinycrypt module for both the signature validation and decryption. 

[eb12345]

Thank you. Now I can build and test. Which brings me to the original issue. When you add CONFIG_MCUBOOT_SERIAL=y, you get an error:

C:\ncs\v2.4.2\bootloader\mcuboot\boot\boot_serial\src\boot_serial.c:634: undefined reference to `boot_handle_enc_fw'
collect2.exe: error: ld returned 1 exit status

The only way I found to alleviate this is to enable CONFIG_SINGLE_APPLICATION_SLOT=y. This is in the mcuboot child image. I think it's important failsafe to be able to use DFU/SMP Server (USB CDC, UART/Serial, or BLE) from the mcuboot image (can enter DFU in the bootloader using gpio or wait for DFU command for a short time). I don't care about switching images when you're in the bootloader, but there will be some cases where this will be the only way to recover a faulty image (correctly signed and encrypted, but one that needs to be overwritten manually).

[Vidar Berg]

I understand your concern. Unfortunately, once I enable encryption, I can no longer upload images to the secondary slot using serial recovery. I've tried various configurations and patches, but regardless of what I tried, the image was always updated "in-place". And to upload an encrypted image directly to the primary slot, we need to use the single loader to have the image decrypted on-the-fly (single loader is included through the CONFIG_SINGLE_APPLICATION_SLOT=y symbol). 

The problem with activating the single loader is that it disables FW updates via the application, leaving the serial recovery mechanism as the only DFU method.

I'm afraid my only suggestion is to try raising this issue in the MCUBoot project.

[eb12345]

I'll post something asking, although I think the upstream repository is different than what NCS has, so not sure if it is still a valid question. I don't mind that in serial recovery you can only write to the primary slot, just don't want it disable DFU in the application.