MCUboot Secure Boot for Series 2 Devices#

Introduction#

Overview#

MCUboot is a secure bootloader for 32-bit microcontrollers that provides a common infrastructure for booting and upgrading firmware. This guide explains how to configure MCUboot with PSA Crypto builtin keys and hardware-accelerated cryptography for secure boot on Silicon Labs Series 2 devices that support the Hardware Secure Engine (HSE). It also describes how secure boot works on devices that use the Virtual Secure Engine (VSE), where MCUboot verifies images using an embedded public key and the same hardware-accelerated PSA Crypto implementation, but without PSA builtin keys.

Silicon Labs Series 2 devices support two Secure Engine (SE) variants:

Features#

The following table summarizes the main behavioral differences between using PSA builtin keys on HSE devices and using an embedded key on VSE devices. Both flows provide the same high-level secure boot guarantees (signed images, integrity verification, and versioning).

Boot Process Flow#

The secure boot process is similar on both HSE and VSE devices, with key handling and PSA Crypto configuration being the main differences.

HSE-based devices (PSA builtin keys)#

1. Device reset — System powers on or resets.

2. MCUboot initialization — Bootloader starts and initializes PSA Crypto with the HSE driver.

3. Key retrieval — MCUboot retrieves a PSA key handle referencing the public key stored inside the Secure Engine (for example, key ID 0x7FFF0001).

4. Image verification — ECDSA signature verification is performed using hardware acceleration through PSA Crypto opaque drivers.

5. Boot decision:

   • Valid signature → Boot the application.

   • Invalid signature → Stay in MCUboot.

VSE-only devices (embedded key)#

1. Device reset — System powers on or resets.

2. MCUboot initialization — Bootloader initializes PSA Crypto with the VSE driver.

3. Key retrieval — MCUboot uses a public key compiled into the bootloader image.

4. Image verification — ECDSA signature verification is performed using hardware acceleration via PSA Crypto transparent drivers.

5. Boot decision:

   • Valid signature → Boot the application.

   • Invalid signature → Stay in MCUboot.

From the application's point of view, the behavior is identical on HSE and VSE devices: the device boots only authenticated firmware.

Prerequisites#

Hardware Requirements#

Secure boot with MCUboot is supported on both HSE-based and VSE-based Series 2 devices:

• Silicon Labs Series 2 device with HSE support (for example, EFR32BG29), or

• Silicon Labs Series 2 device with VSE support (for example, EFR32BG27)

• Matching development board (for example, BG29-RB4420A)

Software Requirements#

• Simplicity SDK for Zephyr (Silicon Labs' Zephyr-based SDK with MCUboot integration)

• Simplicity Commander

  • Required for HSE devices (SE key provisioning and secure boot configuration)

  • Required for VSE devices to sign the MCUboot image so it is linked to the device's root of trust

Flash Partition Layout#

MCUboot relies on a flash partition layout defined in Devicetree (DTS). The exact layout is board-specific, but Series 2 devices commonly follow a structure similar to the example below. The following layout matches the Devicetree definition for a 1 MiB flash device.

Example flash layout (1 MiB flash):

Note: Addresses in the table are offsets from the flash base; boards commonly use a flash base of 0x08000000.

The partition layout is configured under the partitions node in Devicetree. To adjust partition sizes, update the relevant partition nodes (for example, boot_partition, slot0_partition, slot1_partition, and storage_partition) in the board Devicetree or in an overlay file.

Key Generation and Secure Engine Provisioning#

This section covers the one-time setup steps for generating signing keys and configuring the Secure Engine for Secure boot. These steps apply to both HSE- and VSE-based Series 2 devices:

• HSE devices require provisioning of the public key into SE OTP, which is later used by MCUboot via PSA Crypto builtin keys.

• VSE devices require secure boot configuration and signing of the MCUboot image, because the VSE verifies the MCUboot image itself as part of the root of trust.

• Key generation is required in all cases because MCUboot signs and verifies application images.

Generate ECDSA Key Pair#

Generate an ECDSA P-256 key pair using the MCUboot imgtool included with the Simplicity SDK for Zephyr:

imgtool keygen -k my-signing-key.pem -t ecdsa-p256

This creates a PEM file that contains both the private and public key.

Security warning:

• Development: Use test keys (for example, test-ecckey.pem).

• Production: Generate unique keys and store them securely.

• Never commit keys to version control — add *.pem to .gitignore.

• SE OTP writes are permanent — keys cannot be changed once written on production devices.

Extract Public Key (HSE provisioning)#

For HSE devices, extract the public key portion for SE provisioning:

imgtool getpub -k my-signing-key.pem > my-pubkey.pem

VSE devices do not use PSA builtin keys for MCUboot's application verification, but the MCUboot bootloader image must still be signed so that the VSE can authenticate it.

Provision Public Key to the Secure Engine (HSE only)#

On HSE devices, write the public key to the Secure Engine's OTP memory so MCUboot can access it via PSA Crypto builtin key identifiers:

commander security writekey --sign my-pubkey.pem

When prompted, type: continue

Warning: This operation is permanent and irreversible on production devices. Verify you're using the correct key before proceeding.

For additional background, see:

• Simplicity Commander Documentation.

Configure Secure Boot#

Apply security configuration to enable secure boot using Simplicity Commander:

commander security writeconfig --secureboot --nostore

When prompted, type: continue

Enabling secure boot configures the device's Secure Engine to verify the MCUboot bootloader (HSE and VSE). On HSE devices, this also enables MCUboot to use PSA Crypto builtin keys for application image verification.

Verify Secure Boot Status#

commander security status

Expected output:

Secure Boot: enabled

Notes for VSE-based Devices#

On VSE-only devices, the secure boot flow is the same from the application's point of view (signed image, version checks, verification by MCUboot), but:

• The public key used by MCUboot to verify application images is compiled into the MCUboot image instead of being stored in SE OTP.

• PSA builtin keys are not used by MCUboot, so SE key provisioning is only required for the VSE to verify the MCUboot image itself.

• The Simplicity SDK for Zephyr provides an MCUboot configuration with an embedded public key suitable for development on supported VSE boards.

For most users on VSE-based devices, it is sufficient to:

1. Use the standard Sysbuild-based flow described in Building and Flashing with Sysbuild.

2. Enable secure boot in the device's security configuration (for example, using commander security writeconfig --secureboot).

MCUboot verifies application images on VSE devices using hardware-accelerated PSA Crypto with the public key embedded in the bootloader image.

Building and Flashing with Sysbuild#

Build MCUboot and Application#

Use Sysbuild to build both MCUboot and your application together. For example, to build the blinky sample:

west build -b bg29_rb4420a --sysbuild samples/basic/blinky -- -DSB_CONFIG_BOOTLOADER_MCUBOOT=y

In this configuration:

• --sysbuild enables Zephyr's multi-image build system to build both MCUboot and the application.

• SB_CONFIG_BOOTLOADER_MCUBOOT=y enables MCUboot as the bootloader in the Sysbuild configuration.

In this flow:

• Sysbuild orchestrates the build of both images and manages the flash layout.

• MCUboot itself selects the appropriate signature verification method based on its Kconfig configuration and the device's Secure Engine capabilities (PSA builtin keys on HSE, embedded key on VSE).

Flash#

After a successful build, flash the two images:

west flash

This uses the board configuration and Sysbuild-generated metadata to program both MCUboot and the application to the correct flash locations.

Reset and Boot#

Reset the device using either:

commander device reset

or the board's reset button/debugger. On reset, MCUboot verifies the application image and boots it if verification succeeds.

Advanced Configuration#

Debug Logging#

Enable MCUboot logging to observe the boot process by adding the following options to your application's prj.conf (or a Kconfig fragment that affects the MCUboot configuration via Sysbuild):

CONFIG_LOG=y
CONFIG_MCUBOOT_LOG_LEVEL_DBG=y
CONFIG_SERIAL=y
CONFIG_CONSOLE=y
CONFIG_UART_CONSOLE=y

These options are helpful during development and debugging.

Troubleshooting#

MCUboot Fails to Verify Image#

Symptoms: Device stays in MCUboot; signature verification failure in logs (if enabled).

Solutions:

1. Verify key match:

   imgtool getpub -k my-signing-key.pem

   Confirm that the public key matches the one provisioned to the Secure Engine (HSE) or embedded in MCUboot (VSE).

2. Verify Secure Engine configuration:

   commander security status

   Ensure that the signing key used by the build system is the same key whose public portion was written to SE OTP (HSE) or embedded in MCUboot (VSE).

Build Fails with PSA or Mbed TLS Errors#

Symptoms: Compilation errors related to PSA Crypto or Mbed TLS.

Solutions:

1. Perform a clean build:

   west build -b bg29_rb4420a samples/basic/blinky --pristine --sysbuild -- -DSB_CONFIG_BOOTLOADER_MCUBOOT=y

2. Ensure that you are using the Simplicity SDK for Zephyr.

SE Key Write Fails#

Symptoms: Simplicity Commander reports an error; secure boot shows disabled.

Solutions:

1. Check device connection:

   commander device info

2. Verify that the Secure Engine is not already provisioned with an incompatible key (for example, on pre-programmed devices).

3. Ensure the public key is an ECDSA P-256 key in PEM format generated by imgtool.

Wrong Key Used for Signing#

Symptoms: Signature verification fails; MCUboot rejects the application.

Solutions:

1. Verify that the private key used by the build system matches the public key provisioned to the Secure Engine (HSE) or embedded in MCUboot (VSE).

2. If the wrong public key was written permanently to SE OTP on a production device, the device might not be recoverable and must be treated accordingly.

Notes for VSE-based Devices#

VSE devices use an embedded public key in the MCUboot image and do not use PSA builtin keys in MCUboot. If verification fails on a VSE device:

1. Ensure the MCUboot image was rebuilt after changing signing keys.

2. Ensure the application was signed using the private key that corresponds to the embedded public key in MCUboot.

3. Confirm that secure boot is enabled in the device's security configuration by running:

   commander security status

   and checking that Secure Boot: enabled appears in the output.

Security Considerations#

Key Management Best Practices#

References#

• Simplicity SDK for Zephyr Getting Started Guide

• UG162: Simplicity Commander Reference Guide

• UG489: Gecko Bootloader User's Guide