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

[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