Using zephyr and MCUboot without image signatures

Is there a way to not use signatures at all for MCUboot?

Without any changes to the kconfig file, I get a warning when compiling a project using MCUboot:

--- WARNING: Using default MCUBoot key, it should not ---
--- be used for production. --

I have a DFU process that already includes signature verification, so I have no reason to use MCUboot to verify the signature again.

I know that I can set CONFIG_BOOT_SIGNATURE_TYPE_NONE in an MCUboot kconfig file (PROJ_DIR/child_image/mcuboot.conf), and that I could choose a custom key in the main zephyr application, but I have not seen a way to set the main application to not use any key to sign the image.

Thanks
Parents
  • Hello,

    That's strange. Then, I guess, you need to manually set the MCUboot build to not use a signature. I believe this feature will be included in the next release of NCS with the inclusion of Sysbuild as the new multi-image build system. 

    Kind Regards,

    Abhijith

  • Hi,

    the challenge here is that things are intertwined: Essentially the magic happens in two files:

    1. nrf/modules/mcuboot/CMakeLists.txt
    2. bootloader/mcuboot/boot/zephyr/CMakeLists.txt

    (1.) contains the function(sign), which creates all the desired build artifacts, i.e., app_update.bin, app_to_sign.bin _but only_ if CONFIG_SIGN_IMAGES=y. It further checks if CONFIG_BOOT_SIGNATURE_KEY_FILE has been provided. If so, it uses the private key contained in the provided .pem file to sign the build artifacts. If CONFIG_BOOT_SIGNATURE_KEY_FILE has not been set, it uses the default key root-ec-p256.pem provided by mcuboot and shows the well known warning banner (I suppose if you set CONFIG_BOOT_SIGNATURE_TYPE_RSA or CONFIG_BOOT_SIGNATURE_TYPE_ED25519 it would use the default key for those).

    Next, it tries to extract the pubkey from the .PEM file (line 332) and if this causes an error (if(${ret_val} EQUAL 2)), it warns you that the .PEM file does not contain a valid _private_ key (???) and suggests you set CONFIG_SIGN_IMAGES=n.

    Then it uses the private key contained in the .PEM file to sign the build artefacts.

    (2.) uses CONFIG_BOOT_SIGNATURE_KEY_FILE to extract the public key portion from it, create the file build/zephyr/autogen-pubkey.h which is then compiled into the bootloader.

    (2.) will also consider CONFIG_BOOT_SIGNATURE_TYPE_NONE but in my nrf connect SDK v0.2.5 this will only modify some library includes.

    I could confirm that setting

    CONFIG_SIGN_IMAGES=n @prj.conf

    CONFIG_BOOT_SIGNATURE_TYPE_NONE=y @mcuboot.conf

    results in only merged.hex build artifact.

    So to solve your problem, I suppose you need to modify (1.) and potentially (2.) such that functionality is disentangled and that (1.) still creates the build artifacts but does not try to sign them.

    You might find inspiration in [1], as this post made me understand how the Kconfig symbols are used in the two CMakelists.txt files.

    [1] devzone.nordicsemi.com/.../decouple-mcuboot-public-key-storage-and-image-signing-nrf9160-mcuboot

Reply
  • Hi,

    the challenge here is that things are intertwined: Essentially the magic happens in two files:

    1. nrf/modules/mcuboot/CMakeLists.txt
    2. bootloader/mcuboot/boot/zephyr/CMakeLists.txt

    (1.) contains the function(sign), which creates all the desired build artifacts, i.e., app_update.bin, app_to_sign.bin _but only_ if CONFIG_SIGN_IMAGES=y. It further checks if CONFIG_BOOT_SIGNATURE_KEY_FILE has been provided. If so, it uses the private key contained in the provided .pem file to sign the build artifacts. If CONFIG_BOOT_SIGNATURE_KEY_FILE has not been set, it uses the default key root-ec-p256.pem provided by mcuboot and shows the well known warning banner (I suppose if you set CONFIG_BOOT_SIGNATURE_TYPE_RSA or CONFIG_BOOT_SIGNATURE_TYPE_ED25519 it would use the default key for those).

    Next, it tries to extract the pubkey from the .PEM file (line 332) and if this causes an error (if(${ret_val} EQUAL 2)), it warns you that the .PEM file does not contain a valid _private_ key (???) and suggests you set CONFIG_SIGN_IMAGES=n.

    Then it uses the private key contained in the .PEM file to sign the build artefacts.

    (2.) uses CONFIG_BOOT_SIGNATURE_KEY_FILE to extract the public key portion from it, create the file build/zephyr/autogen-pubkey.h which is then compiled into the bootloader.

    (2.) will also consider CONFIG_BOOT_SIGNATURE_TYPE_NONE but in my nrf connect SDK v0.2.5 this will only modify some library includes.

    I could confirm that setting

    CONFIG_SIGN_IMAGES=n @prj.conf

    CONFIG_BOOT_SIGNATURE_TYPE_NONE=y @mcuboot.conf

    results in only merged.hex build artifact.

    So to solve your problem, I suppose you need to modify (1.) and potentially (2.) such that functionality is disentangled and that (1.) still creates the build artifacts but does not try to sign them.

    You might find inspiration in [1], as this post made me understand how the Kconfig symbols are used in the two CMakelists.txt files.

    [1] devzone.nordicsemi.com/.../decouple-mcuboot-public-key-storage-and-image-signing-nrf9160-mcuboot

Children
No Data
Related