Signing mcuboot, b0n and applications with custom private key on the nRF5340

RE: Signing mcuboot, b0n and applications with custom private key on the nRF5340

Vidar Berg — Wed, 03 Jul 2024 11:24:27 GMT

[quote user="puz_md"]No key information is needed in the main application[/quote]

Your understanding is correct, just wnat to add that the build system will use the MCUBoot key to sign the application update image. This happens automatically has a part of the build process with the help of 'imgtool'.

[quote user="puz_md"]And if you use two different files for signing, does this mean that the NET core app is signed twice (one time with the SB_SIGNING_KEY for b0n and one time with the mcuboot signing key)?[/quote]

Yes, MCUBOOT metadata such as the image hash, etc is not transferred to the netcore.

[quote user="puz_md"]Also thanks for the hint with CMakeLists.txt. I didn't know you could configure settings for child projects there. It seems like it does the same as creating chld_image/mcuboot.conf and hci_rpmsg.conf with the mentioned information.[/quote]

Yes, the end result is the same. You can check the generated configs to confirm that the path to the signature file is set correctly. E.g. in build/hci_rpmsg/zephyr/.config.

Best regards,

Vidar

RE: Signing mcuboot, b0n and applications with custom private key on the nRF5340

puz_md — Wed, 03 Jul 2024 09:18:52 GMT

Hi Vidar,

thanks for the information. From your reply, I understand that I need the following configuration artefacts for using mcuboot without the secure immutable bootloader on the APP core, and the automatically generated hci_rpmsg with b0n for Bluetooth on the NET core:

CONFIG_SB_SIGNING_KEY_FILE for the hci_rpmsg child project
CONFIG_BOOT_SIGNATURE_KEY_FILE for the mcuboot child project
No key information is needed in the main application
The NET core checks its application's signature during each startup because it's an automatic feature from b0n which cannot be turned off. This is what SB_SIGNING_KEY_FILE is for.

Can you please confirm?

And if you use two different files for signing, does this mean that the NET core app is signed twice (one time with the SB_SIGNING_KEY for b0n and one time with the mcuboot signing key)?

Also thanks for the hint with CMakeLists.txt. I didn't know you could configure settings for child projects there. It seems like it does the same as creating chld_image/mcuboot.conf and hci_rpmsg.conf with the mentioned information.

Best regards,
Michael

RE: Signing mcuboot, b0n and applications with custom private key on the nRF5340

Vidar Berg — Wed, 03 Jul 2024 05:04:21 GMT

Hi,

I tend to set the CONFIG_SB_SIGNING_KEY_FILE and CONFIG_BOOT_SIGNATURE_KEY_FILE symbols in the project's CMakeLists.txt file rather than using Kconfig fragments. It's more convenient if you want to reference the key files relative to the project source directory instead of using an absolute path.

Below is an example where I have selected a custom signing key for each bootloader. Note: The variables must be set right after the cmake_minimum_required() line to ensure they are applied early enough in the build process.

cmake_minimum_required(VERSION 3.20.0)

# Set signature key for network core bootloader (B0n).
set(hci_rpmsg_CONFIG_SB_SIGNING_KEY_FILE \"${CMAKE_CURRENT_SOURCE_DIR}/keys/nsib.pem\")

# Set signature key for MCUBoot
set(mcuboot_CONFIG_BOOT_SIGNATURE_KEY_FILE \"${CMAKE_CURRENT_SOURCE_DIR}/keys/mcuboot.pem\")

...

<project directory>/keys
├── mcuboot.pem
└── nsib.pem

RE: Signing mcuboot, b0n and applications with custom private key on the nRF5340

puz_md — Tue, 02 Jul 2024 13:36:51 GMT

Hi Vidar,

thanks for the details. Please let me ask one final question:

Assuming that I do not use the nRF Secure Immutable Bootloader (CONFIG_SECURE_BOOT=n). Just mcuboot (and b0n on the NET core which appears to be mandatory). Which options in which (child and main) projects do I need to replace all the default keys from the nRF Connect SDK? Just a simple list of configuration files and the CONFIG_* options I have to set in them would be nice..

Best regards,
Michael

PS: I edited my first comment with two updates, the problem was caused by enabling secure boot with my pm_static.yml which did not leave room for the new components.

RE: Signing mcuboot, b0n and applications with custom private key on the nRF5340

Vidar Berg — Tue, 02 Jul 2024 12:15:00 GMT

Hello,

[quote user=""]Question 1: CONFIG_SECURE_BOOT[/quote]

With this symbol selected, the nRF Secure Immutable Bootloader will become included in the build and causing MCUBoot to be included as a second-stage bootloader on the application core, see Secure bootloader chain. Enabling secure boot is optional and is not needed for supporting DFU of the main app.

The CONFIG_SB_SIGNING_KEY_FILE symbol specifies the signing key to be used by the nRF Secure Immutable Bootloader to validate the mcuboot image, which will be the next image in the bootchain, see Adding a custom signature key file.

[quote user=""]Question 2: Key error for hci_rpmsg[/quote]

The Network core bootloader should also be provisioned with an unique key. This is done with the same CONFIG_SB_SIGNING_KEY_FILE symbol. This thread disucusses how you can configure this symbol for you hci_rpmsg child image:

How to use CONFIG_SB_SIGNING_KEY_FILE as a relative path

[quote user=""]

Question 3: Understanding key usage

Please help me understand the process of deployment. As far as I know:

mcuboot on the APP core needs the private key to recognize correctly signed images.
mcuboot checks both the app_update.bin and net_core_app_update.bin for correct signatures
both APP core and NET core binaries must be signed at the end of the build process. I assumed that CONFIG_SB_SIGNING_KEY_FILE in my prj.con would be used by the build system to sign both images, as signing is a separate action at the end of the build process and not during child image building. Is my assumption here wrong?
Big question: Is the signature for firmware updates checked exclusively by mcuboot, and b0n is not aware of the signature? Or will I have to add the private key information also to b0n when I use dual core MCU's like the nRF5340? (If so, how do I do it correctly?)

[/quote]

The public key from your private/public keypair is included the bootloader and used to verify that the app was signed with the corresponding private key. The private is not distributed with the FW.

MCUBOOT will validate both netcore and app core images during DFU. But the netcore bootloader (B0n) will be responsible for doing subsequent boot validation of the netcore image after the DFU has been completed with the CONFIG_SB_SIGNING_KEY_FILE key provided to the hci_rpmsg build. You may use the same CONFIG_SB_SIGNING_KEY_FILE key for the application core and network core.

b0n is not aware of the MCUBoot signature that was verified during the DFU process.

[quote user=""]Question 4: Multiple keys for mcuboot[/quote]

This is correct. To revoke an old key, you would need to update to a new mcuboot image with a different key-pair.

[quote user=""]Question 5: Handling of invalid images by mcuboot[/quote]

The correct behaviour is that it falls back to the previous version if the validation failed. The long processing time suggests that the swap alghoritm is enabled in MCUBOOT. I.e., BOOT_UPGRADE_ONLY is not enabled in build/mcuboot/zephyr/.config.

[quote user="puz_md"]One more question... if I configure my project as described above, it compiles without any problem, but I cannot flash merged_domains.hex anymore. It tries to access an invalid memory location. Any ideas?[/quote]

I have not seen this error before. But the failing address is in the UICR.KEYSLOT.CONFIG range for the application core. Do you see the same error if you try to program the merged_domains.hex with nrfjprog directly (note: this requires an up to date version of nrfjprog installed)?

nrfjprog --program merged_domains.hex --chiperase --verify --fast -r

Best regards,

Vidar

RE: Signing mcuboot, b0n and applications with custom private key on the nRF5340

puz_md — Tue, 02 Jul 2024 10:53:49 GMT

One more question... if I configure my project as described above, it compiles without any problem, but I cannot flash merged_domains.hex anymore. It tries to access an invalid memory location. Any ideas?

-- runners.nrfjprog: Flashing file: c:\svn\TecnoBasicDigital\Prototyp\Source\_trunk_\TecnoBasicDigital\build\zephyr\merged_domains.hex
-- runners.nrfjprog: c:\svn\TecnoBasicDigital\Prototyp\Source\_trunk_\TecnoBasicDigital\build\zephyr\merged_domains.hex targets both nRF53 coprocessors; splitting it into: c:\svn\TecnoBasicDigital\Prototyp\Source\_trunk_\TecnoBasicDigital\build\zephyr\GENERATED_CP_NETWORK_merged_domains.hex and c:\svn\TecnoBasicDigital\Prototyp\Source\_trunk_\TecnoBasicDigital\build\zephyr\GENERATED_CP_APPLICATION_merged_domains.hex
[ #################### ]  12.468s | Erase file - Done erasing                                                          
[ #################### ]   1.302s | Program file - Done programming                                                    
[ #################### ]   1.305s | Verify file - Done verifying                                                       
[error] [ Client] - Encountered error -173: Command erase_file executed for 35 milliseconds with result -173
[error] [ Worker] - Address 0x00FF8424 does not map to a known memory.                                                 
ERROR: The file specified is not a valid hex file, has data outside valid areas
ERROR: or does not have data in valid areas.

This strange section at 0xFF8424 (just before the NET core flash) is added to merged_domains.hex now...

:10752000BEA6FC690552B186829B9B8651604FCBFB
:107530007DEC913192C0EE23707C7B70C1DBDB204F
:0C7540006681C60F3265076BE652A17F22
:0200000400FFFB
:10842400000202000041050001000000FFFFFFFF01
:10843400C7770375F2E3FC2E99D83C4E6840DE936F
:108444000100010001001400FFFFFFFFFFFFFFFF19
:10845400FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF28
:10846400FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF18
:020000040100F9
:10000000A00D0021E116000187420001B516000194
:10001000B5160001B5160001B5160001000000007C

Update 1: Found it in the Memory report, is's a provision partition...:

Instead of only mcuboot, the build system now also includes b0, s0 and s1 (including image slots) in my primary APP space. This was not epected/intendet, I already created my static oatririon file with mcuboot only... I guess it's the CONFIG_SECURE_BOOT option.

Update 2: Today, I could strangely build with CONFIG_SECURE_BOOT disabled...