MCUBOOT Sign the firmware

[Aleksa]

Hello Everyone,

First of all, what a terrible experience this has been. I'm trying to use custom RSA private key in order to sign the firmware before we go into production. However whatever I do, I can't get rid of this warning:

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

Let me say that I've gone through all of devzone forum, all of the documentation I could find, and nothing seems to work. So I think the only thing that can work for me is to give me a step by step guide on how to use a custom key to sign one of your samples, and I'll adjust it for our product. I've been stuck on this for hours, and it seems like config is completely broken.

We are using ncs v1.9.1.

What I'd like to do is to get it all done in the config (probably mcuboot.conf which I've linked in the CMakeLists.txt). Something like this seems to be working on your end:

CONFIG_BOOT_SIGNATURE_TYPE_ECDSA_P256=n
CONFIG_BOOT_SIGNATURE_TYPE_RSA=y
CONFIG_BOOT_SIGNATURE_KEY_FILE="custom_key_rsa-2048.pem"

But the build system just keeps telling me how this is wrong, how the key file variable is ignored and how it will keep on using the default keys. 

Does this really work at all for NCS? It should be trivial to sign the firmware with a custom key, but somehow I've wasted quite a bit of time on it by now.

Cheers,
Aleksa

[Einar Thorsrud]

Hi Aleksa,

You need to specify a full path to the key file. Alternatively, you can do as described here.

[Aleksa]

I was able to sign with a full path. But the suggestion for the relative path doesn't work, I get an error:

CMake Error at /home/aleksa/Desktop/01_POSAO/02_UPWORK/04_PENNY/01_MG105_NCS191/mg105-nrf9160-root/lib/nordic/ncs/nrf/cmake/multi_image.cmake:409 (message):
  CMake generation for mcuboot failed, aborting.  Command: 1
Call Stack (most recent call first):
  /home/aleksa/Desktop/01_POSAO/02_UPWORK/04_PENNY/01_MG105_NCS191/mg105-nrf9160-root/lib/nordic/ncs/nrf/cmake/multi_image.cmake:150 (add_child_image_from_source)
  /home/aleksa/Desktop/01_POSAO/02_UPWORK/04_PENNY/01_MG105_NCS191/mg105-nrf9160-root/lib/nordic/ncs/nrf/modules/mcuboot/CMakeLists.txt:216 (add_child_image)

Also, I don't understand why I had to make child_image/mcuboot.conf file. Signing works only when I put there the config below, but I see no logic behind it. Here is the config:

CONFIG_BOOT_SIGNATURE_TYPE_RSA=n
CONFIG_BOOT_SIGNATURE_TYPE_ECDSA_P256=y
CONFIG_BOOT_SIGNATURE_KEY_FILE="path/to/private.pem"
# CONFIG_BOOT_SIGNATURE_KEY_FILE="private.pem"

 

Also, it doesn't work when I try to use RSA instead of ECDSA (and fix their respective configs of course). Again, I see no reason why it would behave this way.

[Einar Thorsrud]

Hi,

When you build an application and enable MCUboot, that will also be built as a child image (which is a build system concept). In recent nRF Connect SDK releases, you can add a configuration overlay under child_image/<child_image_name>.conf. This also works for other overlays. When you do this, it is automatically picked up by the build system and applied.

With regard to relative paths that is a common request but there are no elegant ways to do this for now.

[mytzyiay]

Einar Thorsrud said:

With regard to relative paths that is a common request but there are no elegant ways to do this for now.

I second this request.  It's very common in our environment for multiple developers to clone the project into their respective home directories on MacOS/Linux, which will have different absolute paths.  Requiring them to fix up the .config options adds an unnecessary point of failure to the build process.

[KRich]

Is there a plan to add/fix the relative path support soon? The documentation would seem to indicate that relative paths are supported. Is this a bug that will be fixed soon? As is already mentioned, expecting multiple developers to use a system that requires absolute paths is untenable.

Also, based on https://developer.nordicsemi.com/nRF_Connect_SDK/doc/latest/nrf/ug_bootloader_adding.html?highlight=mcuboot_config_boot_signature_key_file#id2 it seems that even though I get the message about MCU boot using the default key, the actual generated code is using my new/private key (even when using the relative path to the key file). Is that possible?

[Einar Thorsrud]

Hi,

I did not get a chance to test it myself today, but a colleague of me mentioned that it should be possible now (in 2.0.0). You can modify the application CMakeLists.txt as indicated here, where a relative path to the key file is used:

cmake_minimum_required(VERSION 3.20.0)

set(mcuboot_CONFIG_BOOT_SIGNATURE_KEY_FILE \\"${CMAKE_CURRENT_SOURCE_DIR}/../burd.pem\\")

find_package(Zephyr REQUIRED HINTS $ENV{ZEPHYR_BASE})
project(hello_world)

target_sources(app PRIVATE src/main.c)

[KRich]

Thanks Einar Thorsrud, I have confirmed that this method works for my project and configuration. Since this is not my thread originally, I'll leave marking as an accepted answer it to Aleksa.

Some quick (I hope) follow-up questions:

1. Will a relative path ever be supported in a Kconfig fragment as indicated at https://developer.nordicsemi.com/nRF_Connect_SDK/doc/latest/kconfig/index.html#CONFIG_MCUBOOT_SIGNATURE_KEY_FILE?
2. Per that link above it seems necessary to set both CONFIG_MCUBOOT_SIGNATURE_KEY_FILE and CONFIG_BOOT_SIGNATURE_KEY_FILE. Is that correct, or is it sufficient to set only CONFIG_BOOT_SIGNATURE_KEY_FILE?
3. Why is it necessary to double escape (\\") the quotation marks in the sample code you provided?

Thanks!

[mytzyiay]

KRich said:

Why is it necessary to double escape (\\") the quotation marks in the sample code you provided?

I believe this is the same issue as https://github.com/nrfconnect/sdk-nrf/pull/7997

i.e. the NCS cmake scripts cache the value of this variable but they're storing that value without properly escaping the quotes.

Hoping it gets fixed in v2.1.0.

(Also I suspect that backslashes might suffer from a similar issue, but I'll leave it to the Windows users to test that.)

KRich said:

Per that link above it seems necessary to set both CONFIG_MCUBOOT_SIGNATURE_KEY_FILE and CONFIG_BOOT_SIGNATURE_KEY_FILE. Is that correct, or is it sufficient to set only CONFIG_BOOT_SIGNATURE_KEY_FILE?

I'm just a random user so maybe I'm doing things all wrong, but after applying the change from the above PR on github, this is what has worked for me:

OTA_ARGS = \
 -DOVERLAY_CONFIG=overlay-fota.conf \
 -DPM_STATIC_YML_FILE=pm_ota.yml \
 -D"mcuboot_CONFIG_BOOT_SIGNATURE_KEY_FILE=\"$(ZIGBEE_SIGNING_KEY)\"" \
 -D"CONFIG_MCUBOOT_IMAGE_VERSION=\"$(shell ./scripts/unix-time-to-version.sh)\"" \
 -D"CONFIG_DATE_CODE=\"$(shell date +%Y%m%d-%H%M)\""

.PHONY: ota
ota:
 $(if $(ZIGBEE_SIGNING_KEY),,$(error Please set $$ZIGBEE_SIGNING_KEY))
 $(WEST_BUILD) --board raw_dongle -- $(OTA_ARGS)

There are no CONFIG_MCUBOOT options in prj.conf or overlay-fota.conf