CMake warning: Using default MCUBoot key, it should not be used for production.

[nrbrook]

I'm following the steps at https://developer.nordicsemi.com/nRF_Connect_SDK/doc/latest/nrf/ug_bootloader.html#adding-a-bootloader-chain-to-your-application

I generated a private key using

openssl ecparam -name prime256v1 -genkey -noout -out priv.pem

Side note: I got this command from the bootloader sample readme.rst, it might be useful to include it in the docs at the link above.

To my prj.conf I added:

CONFIG_SECURE_BOOT=y
CONFIG_BOOTLOADER_MCUBOOT=y
CONFIG_SB_SIGNING_KEY_FILE="priv.pem"

When I re-run CMake I get the warning in the title of the question. Should it not be using the private key I specified?

[Håkon Alseth]

Hi,

 

That config is specific to the "SECURE_BOOT" (immutable bootloader, also named "B0"). To set the mcuboot key, you should first edit your CMakeLists.txt and add this just below the cmake_minimum_required() line:

if (EXISTS "${CMAKE_CURRENT_SOURCE_DIR}/mcuboot.conf")
    list(APPEND mcuboot_OVERLAY_CONFIG
      "${CMAKE_CURRENT_SOURCE_DIR}/mcuboot.conf"
      )
endif()

This will allow your application to append to the default mcuboot configuration.

Then you create a mcuboot.conf file in your application folder, holding the absolute path of your .pem file:

CONFIG_BOOT_SIGNATURE_KEY_FILE="/path/to/priv.pem"

 

Now, when you delete your build folder and re-run cmake (or west, SES-NE), it shall use your private key.

 

PS: Note that CONFIG_SB_SIGNING_FILE="" should be in your prj.conf, ie. specific to the project which also set the CONFIG_SECURE_BOOT.

 

Kind regards,

Håkon

[nrbrook]

Thanks Hakon, I think this is missing from the docs?

Is there any way to use a relative path, perhaps setting from CMake? Absolute path is not very friendly to share with others...

Thanks

[Håkon Alseth]

Hi,

 

I will report this back to the developer as a improvement (and doc bug).

 

nrbrook said:

Is there any way to use a relative path, perhaps setting from CMake? Absolute path is not very friendly to share with others...

Digging into the logic a bit deeper, I see that there's definitively room for improvement from our side. One problem is the inherited behavior of what is happening "in the background" - which is essentially a triggering of multiple project configurations and builds. We are trying to keep this logic as easy to use as possible, and this feedback is perfect help for us to improve our delivery in the future! Thank you very much for pointing this out and helping us improve.

The current way its implemented is that this check will do a absolute path check, and if its not, it'll print a warning:

https://github.com/nrfconnect/sdk-nrf/blob/v1.5.0-rc1/modules/mcuboot/CMakeLists.txt#L141-L159

This check is simplistic, given the multi-build process happening under-the-hood, as you can write BOOT_SIGNATURE_KEY_FILE=somekey.pem, and it will then go into the mcuboot repo directory and look for the "somekey.pem".

This means that if you add your key to the /path/to/ncs/bootloader/mcuboot/ directory, it will use that key when specified in COONFIG_BOOT_SIGNATURE_KEY_FILE=file.pem, but still print the warning when configuring your project.

 

I will speak to the maintainer of those cmake files, and see if we can do something with this functionality in the future.

 

Kind regards,

Håkon

[nrbrook]

Hi Hakon,

Looking at that code it seems you can set a relative file using CMake:

set(mcuboot_key_file ${CMAKE_CURRENT_LIST_DIR}/priv.pem)

However, although that script picks it up, the bootloader/mcuboot/boot/zephyr/CMakeLists.txt script does not:

MCUBoot bootloader key file: /opt/nordic/ncs/v1.5.0-rc1/bootloader/mcuboot/priv.pem

You can use this to set the path used in that file:

set(mcuboot_key_file ${CMAKE_CURRENT_LIST_DIR}/priv.pem)
set(mcuboot_CONFIG_BOOT_SIGNATURE_KEY_FILE "\"${mcuboot_key_file}\"")

Note that you must include escaped quotes. Using this approach, you don't need to use the overlay config.

However this is a workaround, it should really all come from one variable. You also get a warning because all mcuboot_ variables are passed to the MCUBoot CMakeLists.txt, and "key_file" is not used.

Thanks

[Jared]

Hey Hakon,

Looks like this is still happening on 1.6.1. Just wanted to make a note here for others. Setting the full path does seem to resolve the warning. 

Jared