MCUboot with KMU utilization

Hi Nordic,

I'm having a hard time to utilize the KMU of the nRF54l15 for image signature verification in MCUboot with ncs v2.9.0.

Previously, I used ncs v2.7.0 without the KMU for image signature verification purposes. Image encryption was activated too.

Currently, I'm in the process of migrating our application to ncs v2.9.0. We are using the freestanding application type approach.

Unfortunately, I'm facing some obstacles.

In a nutshell the application uses (among others) MCUboot and MCUmgr over BLE and the slot1 partition resides on external flash.

For my understanding this leads to the following KMU related options for MCUboot when using Sysbuild (e.g. SB_CONFIG_BOOT_SIGNATURE_TYPE_PURE cannot be used): 

SB_CONFIG_BOOT_SIGNATURE_TYPE_ED25519=y

SB_CONFIG_MCUBOOT_SIGNATURE_USING_KMU=y

CONFIG_NRF_SECURITY=y

CONFIG_MBEDTLS=n

CONFIG_BOOT_ED25519_PSA=y

The first problem, that I encountered was, that the key hashing algorithm for MCUboot is forced to SHA512 by Sysbuild (see ncs/v2.9.0/nrf/sysbuild/CMakeLists.txt:261). Unfortunately, the default imgtool script, that is pulled by the toolchain (i.e. ncs/toolchains/b77d8c1312/usr/local/lib/python3.12/site-packages/imgtool/), does not support the --sha 512 command line option, whereas the ncs/v2.9.0/bootloader/mcuboot/scripts/imgtool.py does support it.

This can be solved by overriding the CMakeCache in the project's top level CMakeLists.txt file to:

set(IMGTOOL "$ENV{HOME}/ncs/v2.9.0/bootloader/mcuboot/scripts/imgtool.py" CACHE FILEPATH "Path to imgtool used for signing images")

What I don't quite understand is, that, when I for instance build the sample in ncs/v2.9.0/nrf/tests/subsys/kmu/hello_for_kmu with, the CMake signing  script ncs/v2.9.0/nrf/cmake/sysbuild/image_signing.cmake is used by the toolchain.

(v2.9.0) xxx:~/ncs/v2.9.0/nrf/tests/subsys/kmu/hello_for_kmu$ west -vvv build -b nrf54l15dk/nrf54l15/cpuapp --sysbuild .

...
-- Including signing script: /home/xxxxx/ncs/v2.9.0/nrf/cmake/sysbuild/image_signing.cmake
...


Whereas for my freestanding application, the toolchain selects the ~/ncs/v2.9.0/zephyr/cmake/mcuboot.cmake script instead.

Nevertheless, image signing by the toolchain and verification by MCUboot works now and I can upgrade the application remotely.

As long as the image is not encrypted!

Because when I enable image encryption through SB_CONFIG_BOOT_ENCRYPTION=y and SB_CONFIG_BOOT_ENCRYPTION_KEY_FILE="xxx"),
MCUboot rejects the image:

[00:04:07.613,052] <err> mcuboot_psa_enc: Key derivation setup failed -134
[00:04:30.590,512] <err> mcuboot: Image in the secondary slot is not valid!

To use logging in MCUboot with enabled encryption a small patch is needed though:

diff --git a/boot/bootutil/src/encrypted_psa.c b/boot/bootutil/src/encrypted_psa.c
index c3f72884..38ed3c6e 100644
--- a/boot/bootutil/src/encrypted_psa.c
+++ b/boot/bootutil/src/encrypted_psa.c
@@ -25,7 +25,7 @@
 #include "bootutil_priv.h"
 #include "bootutil/bootutil_log.h"

-BOOT_LOG_MODULE_DECLARE(mcuboot_psa_enc);
+BOOT_LOG_MODULE_REGISTER(mcuboot_psa_enc);

 #define EXPECTED_ENC_LEN    BOOT_ENC_TLV_SIZE
 #define EXPECTED_ENC_TLV    IMAGE_TLV_ENC_X25519

I'm a bit lost now.

Any help is appreciated.

Best regards

Christian

  • Hi,

    So this fails when you use the KMU with both Encryption and the public key?

    Could you try this with only the public key to verify that this works by itself?

    Regards,
    Sigurd Hellesvik

  • Hi,

    the KMU has the public key for image signature verification.

    And as stated in my initial post, MCUboot is able to verify the image signature.

    Image update through MCUmgr works too. As long as the uploaded image in the slot in the external flash isn't encrypted, MCUboot will swap the images.

    But when the uploaded image is encrypted, MCUboot throws

    [00:04:07.613,052] <err> mcuboot_psa_enc: Key derivation setup failed -134
    [00:04:30.590,512] <err> mcuboot: Image in the secondary slot is not valid!

    Correct me if I'm wrong. But as far as I understand the MCUboot code, the KMU is not involved in image encryption/decryption.

    Best regards

    Christian

Related