mcuboot: support multiple signing keys#1
Open
JPHutchins wants to merge 1103 commits into
Open
Conversation
JPHutchins
requested review from
aldenhaase,
Copilot,
davedesro,
intercreate-gab,
kylermconnelly and
robhelvestine
There was a problem hiding this comment.
Pull request overview
Draft integration of MCUboot “multiple signing keys” support into Zephyr’s sysbuild flow, including new Kconfig/CMake plumbing, documentation, and a sample demonstrating the dual-key verification use case.
Changes:
- Switch MCUboot module source to a fork/branch carrying the multi-key feature.
- Add
*_KEY_FILE_2support across sysbuild Kconfig/CMake and expose it to app configuration. - Add a new sysbuild sample + docs/release-notes updates and a new test scenario.
Reviewed changes
Copilot reviewed 19 out of 19 changed files in this pull request and generated 4 comments.
Show a summary per file
| File | Description |
|---|---|
| west.yml | Points MCUboot module to a fork/feature branch for the multi-key work. |
| tests/boot/test_mcuboot/testcase.yaml | Adds a new test variant enabling the second key setting. |
| tests/boot/test_mcuboot/root-ed25519-2.pem | Adds an ED25519 key file used by the new test variant. |
| share/sysbuild/images/bootloader/Kconfig | Introduces BOOT_SIGNATURE_KEY_FILE_2 and clarifies key path semantics. |
| share/sysbuild/images/bootloader/CMakeLists.txt | Normalizes signing key paths (incl. second key) before passing to MCUboot image. |
| share/sysbuild/image_configurations/MAIN_image_default.cmake | Forwards second key path into main app Kconfig (CONFIG_MCUBOOT_SIGNATURE_KEY_FILE_2). |
| share/sysbuild/image_configurations/FIRMWARE_LOADER_image_default.cmake | Forwards second key path into firmware-loader app Kconfig. |
| scripts/ci/check_compliance.py | Allows the new Kconfig symbol in compliance checks. |
| samples/sysbuild/mcuboot_dual_key/sysbuild/mcuboot.conf | Sample-specific MCUboot config fragment. |
| samples/sysbuild/mcuboot_dual_key/sysbuild.conf | Sysbuild configuration demonstrating dual accepted verification keys. |
| samples/sysbuild/mcuboot_dual_key/src/main.c | Minimal app used by the new sysbuild sample. |
| samples/sysbuild/mcuboot_dual_key/sample.yaml | Adds test definition for the new sample. |
| samples/sysbuild/mcuboot_dual_key/prj.conf | Placeholder application config for the sample. |
| samples/sysbuild/mcuboot_dual_key/keys/prod_pubkey.pem | Public-only PEM embedded as the “production” verification key in the sample. |
| samples/sysbuild/mcuboot_dual_key/README.rst | End-to-end documentation for the dual-key sysbuild sample. |
| samples/sysbuild/mcuboot_dual_key/CMakeLists.txt | Sysbuild-enabled sample CMake wiring. |
| modules/Kconfig.mcuboot | Adds MCUBOOT_SIGNATURE_KEY_FILE_2 to expose the second key path to app builds. |
| doc/releases/release-notes-4.5.rst | Release note entry for the new sysbuild option and sample. |
| doc/build/signing/index.rst | Documents SB_CONFIG_BOOT_SIGNATURE_KEY_FILE_2 in the signing guide. |
💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.
JPHutchins
force-pushed
the
mcuboot/multiple-signing-keys
branch
2 times, most recently
from
7c86709 to
6ea44fe
Compare
Collaborator
Author
|
Good results by following the readme! |
davedesro
approved these changes
May 29, 2026
JPHutchins
force-pushed
the
mcuboot/multiple-signing-keys
branch
from
6ea44fe to
5c070ce
Compare
JPHutchins
force-pushed
the
mcuboot/multiple-signing-keys
branch
from
5c070ce to
5b45aad
Compare
JPHutchins
commented
Jun 10, 2026
JPHutchins
commented
Jun 10, 2026
JPHutchins
commented
Jun 10, 2026
JPHutchins
commented
Jun 10, 2026
JPHutchins
commented
Jun 10, 2026
JPHutchins
commented
Jun 10, 2026
JPHutchins
commented
Jun 10, 2026
Enable testing of the STM32 HASH driver on HAL2 series. Signed-off-by: Mathieu Choplain <mathieu.choplain-ext@st.com>
Align the closing parenthesis of the two ARMFVP_FLAGS set() calls with the function, matching the project's CMake style. Cosmetic only. Signed-off-by: Nicolas Pitre <npitre@baylibre.com>
Fix incorrectly formatted/indented bullet lists. Signed-off-by: Benjamin Cabé <benjamin@zephyrproject.org>
Fix incorrectly formatted/indented bullet lists. Signed-off-by: Benjamin Cabé <benjamin@zephyrproject.org>
This test depends on hardware, no need to try and run it on simulators. Signed-off-by: Anas Nashif <anas.nashif@intel.com>
zephyr sdk does not have newlib support. Signed-off-by: Anas Nashif <anas.nashif@intel.com>
zephyr sdk does not support newlib, so skip this toolchain on the newlib scenarios. Signed-off-by: Anas Nashif <anas.nashif@intel.com>
no need to spend type checking if simulators can run those samples/tests, filter on platform type and vendors to speed things up. Signed-off-by: Anas Nashif <anas.nashif@intel.com>
dma_bee.h documentation was "polluting" top-level doxygen groups. Fix by reparenting under DMA (will need to properly organize all other DMA headers at some point, btw). Signed-off-by: Benjamin Cabé <benjamin@zephyrproject.org>
SB_CONFIG_BOOT_SIGNATURE_KEY_FILE now accepts a comma-separated list of
PEM paths in addition to a single path. When a list is given, the MCUboot
bootloader embeds the public half of every key and accepts an image
signed with any of them. The first entry is also the key the application
is signed with; every entry past the first must be a public-only PEM of
the same signature type (MCUboot enforces this at build time with
'imgtool keyinfo --require public'). A common use is a development
bootloader that boots both development- and production-signed images
while never holding the production private key.
The keys the bootloader embeds and the single key the application is
signed with are both derived from this one list through the sysbuild
helpers sysbuild_mcuboot_resolve_signature_key_files() and
sysbuild_mcuboot_application_signature_key_file(). Entries are forwarded
verbatim for each image to resolve, so a single-key value behaves exactly
as before and no previously working configuration breaks.
The feature is exercised at runtime by tests/boot/mcuboot_multiple_keys,
which builds a two-key bootloader on the mps2/an385 QEMU machine and boots
an application signed with either embedded key, asserting MCUboot
validates it against the matching key (key_id 0 and key_id 1). The keys
live in the application's own keys/ directory, referenced with ${APP_DIR},
to demonstrate the development/production custody the feature enables
rather than MCUboot's insecure built-in defaults.
Signed-off-by: JP Hutchins <jp@intercreate.io>
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
JPHutchins
force-pushed
the
mcuboot/multiple-signing-keys
branch
from
1b5f693 to
6af2720
Compare
github-actions
Bot
added
manifest-hal_bouffalolab
manifest-lvgl
manifest-percepio
manifest-hal_adi
manifest-hal_nordic
manifest-trusted-firmware-a
manifest-hal_xtensa
manifest-hal_espressif
manifest-hal_atmel
manifest-trusted-firmware-m
manifest-hal_infineon
manifest-hal_stm32
manifest-hal_silabs
manifest-nrf_wifi
manifest-hal_nxp
manifest-hostap
DNM (manifest)
Binary Blobs Modified
Binary Blobs Added
labels
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
What
SB_CONFIG_BOOT_SIGNATURE_KEY_FILEnow accepts a comma-separated list of PEM pathsin addition to a single path. The MCUboot bootloader embeds the public half of every
listed key and accepts an image signed by any of them; the application is signed with
the first entry, and every entry past the first must be a public-only PEM (enforced at
build time with
imgtool keyinfo --require public). The canonical use is a developmentbootloader that boots both development- and production-signed images while never holding
the production private key.
Both the keys the bootloader embeds and the single key the application is signed with
derive from this one list, resolved through a single sysbuild helper
(
sysbuild_mcuboot_resolve_signature_key_files()) against the application sourcedirectory, so the application is always signed with exactly the key whose public half is
embedded — including for relative paths.
Dependency
Requires the multiple-key support in MCUboot (mcu-tools/mcuboot#2701, merged). The
manifest is pinned to
zephyrproject-rtos/mcuboot@5497c95f.Testing
tests/cmake/sysbuild_mcuboot_keys— HW-free unit test of the key-path resolver(absolute / relative /
${VAR}/ multi-key / whitespace forms) at CMake configure time.tests/boot/mcuboot_multiple_keys— runtime acceptance test on the mps2/an385 QEMUmachine (pytest harness): a two-key bootloader boots an application signed with either
embedded key (
key_id 0andkey_id 1), with no DFU, swap or SMP.tests/boot/test_mcuboot— gains a two-key bootloader swap scenario (hardware).samples/sysbuild/mcuboot_signing_keysdemonstrates the development/productioncustody split.