wolfBoot: secure boot and more | Unique features to assist and optimize firmware updates

Secure boot. Simple, compact, safe.

wolfBoot is the universal secure bootloader designed for embedded systems. Its main task is to ensure that only a trusted firmware image can run on the target device, as indicated by RFC9019. To do so, it uses signature verification on the firmware image every time the device starts or when a firmware update is received, OTA or through any custom transport.
wolfBoot relies on wolfCrypt cryptographic engine to support the widest range of
options for signature verification algorithms, including ECC-256, RSA up to 4096 bit, Ed25519 and Ed448, and up to post-quantum algorithms such as LMS/HSS and XMSS
Thanks to a wide choice of hardware security modules and crypto co-processors supported by wolfCrypt, wolfBoot can offload all cryptographic operations to dedicated hardware components when available, cutting down boot time and run-time resources.

Support for Post-quantum cryptography

wolfBoot’s support for Post-Quantum Cryptography (PQC) firmware authentication introduces a robust layer of security to embedded systems, ensuring resilience against emerging threats posed by quantum computing advancements. Leveraging schemes like Leighton-Micali Signature (LMS) with Hash-based Merkle Signature Scheme (HSS) or eXtended Merkle Signature Scheme (XMSS), as well as its multi-tree variant, XMSS^MT, wolfBoot secures its firmware authentication mechanism against potential quantum attacks. By integrating these advanced techniques into the bootloader, wolfBoot ensures the integrity of firmware updates for future-proof systems, against the constantly evolving cryptographic attacks.

Secure boot for all systems

wolfBoot does not depend on any specific libraries, except for wolfCrypt. It does not rely on any operating system environment, driver, platform or toolchains.
wolfBoot can secure the entire boot process of any standalone applications as well as complex operating systems, from small class-I microcontrollers up to Rich Execution Environments, on a wide range of microcontrollers and processors architectures (ARM, x86, PowerPc, RISC-V, x86 and more).
Native ports are available for the majority of common embedded targets and evaluation boards. In cases where a native port isn’t readily accessible, wolfSSL extends its engineering services to prioritize porting efforts, ensuring compatibility across virtually any platforms.

Key management tools

The key command line tools, ‘sign’ and ‘keygen’ (for Windows, Linux, MacOS), distributed along with wolfBoot, follow the development of all the features supported by the bootloader to the latest version. They are easy to use, widely documented, and simple to integrate with any deploy mechanism and back-end update services.

Retrofitting existing non-secure bootloaders

Already using your very own bootloader in your existing project? Do not worry. wolfBoot can be integrated with your current solution, by including one single .c file to your old bootloader code.
For existing bootloaders lacking support for secure boot, wolfBoot can in fact be effortlessly integrated as a library, exposing an API for verifying the authenticity and integrity of firmware. This integration enables the utilization of host tools for key management and firmware signing, leveraging the compatibility of wolfBoot’s manifest header for streamlined firmware update processes.

Roll-back: the bootloader “rescue” mode

wolfBoot stores a copy of the old firmware that gets replaced during the update. Mistakes can happen when building or transmitting a firmware update: even if the firmware is trusted and authenticated by wolfBoot it might still introduce bugs and issues in the field that may prevent the device from being reachable again. For this reason, wolfBoot implements a mechanism that requires the firmware to confirm that the system is working as expected after the update. In absence of this confirmation, at the next reboot wolfBoot considers the update as failed, and restores the original image from the backup taken during the update.

Use any external storage, with built-in confidentiality

Some microcontrollers may not have enough flash space to accommodate two versions of the firmware in the internal FLASH. The only requirement on these systems is normally that only the current executing firmware image should be stored in FLASH, where it can be eXecuted in Place (XiP). Most systems don’t support XiP on external storage supports, but that space can still be allocated to store updates and host the swap space required by wolfBoot to perform the update.

Thanks to a transparent, generic external flash interface, wolfBoot can use any external non-volatile memory support to host update and swap partitions, maximizing the space available in the internal FLASH for the running software.

Neighbor systems can host a virtual partition for the wolfBoot target, using any communication bus to implement remote, emulated memory access.

Encryption and decryption is done at runtime by wolfBoot when accessing these external storage devices for writing and reading, respectively. This mechanism prevents wiretapping or intercepting the firmware images when they are transferred on the BUS (SPI, CAN, Uart,…) that connects to the storage device.

Examples distributed with wolfBoot showcase this feature, with common SPI FLASH targets, and emulated remote storage, on a neighbor system via UART.

HSM support, wolfTPM integration, measured boot

wolfBoot inherits from wolfCrypt the capability to access hardware-assisted functionality offered by Hardware Security Modules (HSMs).

Through wolfTPM‘s integration, wolfBoot strengthens the security of firmware updates but also establishes a robust foundation for safeguarding critical assets and maintaining the trustworthiness of embedded systems. Through wolfTPM’s support, wolfBoot enables measured boot processes, ensuring the integrity of the entire boot chain and providing robust protection against tampering and unauthorized modifications of both hardware and software components. wolfTPM facilitates the implementation of advanced security policies, utilizing Platform Configuration Registers (PCRs) to unlock secrets and enforce access controls in accordance.

Self-update: can a secure bootloader update itself?

wolfBoot offers the possibility to authenticate and install a newer version of itself. A special update package can be created with the key tools, containing an update for the bootloader itself. wolfBoot will parse, authenticate and install the update by temporarily executing a copy of itself in RAM.

Incremental updates: faster OTA transfers with “delta updates”

wolfBoot supports incremental updates, based on a specific older version. Thesign tool can create a small “patch” that only contains the binary difference between the version currently running on target and the update package, a ‘delta update’ package. This package is processed by wolfBoot to reconstruct a complete image of the resulting update. The authenticity of the update is verified twice: first when the package is received before applying the patch, and then after the patch is applied, every time the new firmware is staged for boot.

Where has wolfBoot been ported so far?

  • STM32: nearly all models (STM32C0, STM32F0, STM32G0, STM32L0, STM32F4, STM32L4, STM32L5, STM32H5, STM32H7, STM32U5, STM32WB)
  • NXP: LPC54xxx, i.MX-RT10xx, K64F, K83F, MCXA, P1020, T1024, T2080
  • Microchip: SAM R21, SAM E51, PSoC6
  • Renesas: RA6M4, RX72N, RZN2L
  • Nordic: nRF52
  • TI “Hercules” TMS570
  • SiFive: HiFive1 RISCV RV32 microcontroller
  • Cortex-A Microprocessors: Xilinx Ultrascale Zynq+, Raspberry PI
  • x86_64bit: as UEFI application
  • x86_64 Intel Tigerlake: native BIOS replacement using Intel FSP

Porting wolfBoot to a new target is easy. Our HAL API consists of only six mandatory functions to be implemented to perform target-specific clock initialization and interact with the non-volatile memory containing the signed software images.

What feature would you like to see in the next release of wolfBoot? Contact us at facts@wolfSSL.com with any comments or questions!

Check out our GitHub page for the full documentation, and to stay up to date with our latest developments. And while you are there, consider giving the wolfBoot project a star!

If you have questions about any of the above, please contact us at facts@wolfSSL.com or call us at +1 425 245 8247

Download wolfSSL Now

wolfBoot support for the Xilinx Zynq UltraScale+ MPSoC

wolfBoot support for the Xilinx UltraScale+ was added in 2020 and is a direct U-Boot replacement for improved security.

wolfBoot provides enhanced features compared to U-Boot such as:

  • Firmware integrity and signature verification on each boot
    • Image integrity checking SHA2-256 or SHA3-384.
    • Validation of the signature using ECC P256/P384, RSA (2048-bit or 3072-bit), ED25519 and LMS or XMSS.
  • Multiple boot partition support
    • Rollback to last known working or fail-safe “golden” image on failure
  • TPM 2.0 Support
    • Measured Boot (PCR’s)
    • Sealing secret to unlock or decrypt a storage device
  • Root of trust options
    • Onboard eFUSES
    • Public key embedded in wolfBoot partition
    • TPM 2.0 NV (supported with wolfTPM)
  • Delta/Differential updates using bentley-mcilroy scheme
  • Encrypted updates using AES CFB or ChaCha20/Poly1305

Additional wolfBoot Features:

  • QSPI, SDMC and eMMC boot support
  • ELF (32 and 64) loader support
  • FDT (Flattened Device Tree) support for fixups
  • AARCH64 EL1/EL3 support

We have included a full example for building with Xilinx SDK and integrating into the FSBL chain of trust. Also creation of the flash boot.bin image with boot.bif and bootgen.

Tested support with bare-metal, QNX, GreenHills Integrity OS and Linux/Fedora.
24×7 support available

Links:

If you have questions about any of the above, please contact us at facts@wolfSSL.com or call us at +1 425 245 8247.

Download wolfSSL Now

wolfBoot support for the STM32C0 in 2024

We have added wolfBoot support for the new STM32C0. This is a low cost MCU similar to the STM32G0 based on a Cortex-M0 (48MHz). It is a very low cost general purpose 32-bit MCU with up to 32KB flash and 12KB RAM.

Our wolfBoot secure bootloader is the only solution available for this platform thanks to our small code size. Most STM32 parts are supported with wolfBoot out of the box.

The default STM32C0 configuration uses RSA 2048-bit and SHA2-256 and is less than 10KB. This leaves 10KB for the application partition, 10KB for the update partition and one 2KB sector for swap.

STM32C0 documentation and build steps can be found here.

See our video series with ST for a tutorial on using wolfBoot.

wolfBoot Features:

  • Written in C for bare-metal use
  • Small footprint to run on small embedded devices
  • Memory safety (no malloc/free)
  • Support for on-board or external SPI flash
  • Simple partitioning and header scheme
  • Abstracted HAL design for CPU speed and flash
  • Bootloader handles swapping and loading of partitions
  • Key tools for key generation/import and signing
  • Encrypted updates
  • Delta updates (only differences)

Signature algorithms supported:

  • ECC (SECP256R1,SECP384R1)
  • RSA (2048/3072/4096)
  • ED25519
  • ED448
  • Post Quantum LMS and XMSS

Firmware image integrity using hash digest:

  • SHA2-256
  • SHA2-384
  • SHA3-384

Flexible partition scheme determined at build-time:

  • Bootloader (10-30KB)
  • Application
  • Update
  • Swap (1 sector)
  • And custom partition ID’s

Reliable Firmware update mechanism:

  • Independent from the update transport mechanism
  • Fallback to a previous version when the update fails
  • Resume interrupted swap operations during update, in case of power failure

Support for STM hardware crypto acceleration:

  • STM32 HASH/AES/PKA
  • ST33TP* TPM 2.0 using wolfTPM
  • STSAFE

If interested in trying our wolfBoot on the STM32C0 or curious about post-quantum signature support in wolfBoot please contact facts@wolfSSL.com or call us at +1 425 245 8247.

Download wolfSSL Now

wolfBoot Support for Renesas RZ/N2L

wolfBoot currently support both Renesas RA6M4 and RX72N MCUs. Supporting other Renesas MCUs for wolfBoot should not be difficult. We are considering the addition of Renesas RZ/N2L support for wolfBoot, which will build on our existing support at the wolfSSL and wolfCrypt level for Renesas RZ/N2L.

The Renesas RZ/N2L uses a high-performance Arm Cortex-R52 core to easily add network functionality onto industrial equipment and machines. The RZ/N2L is supported by an open and flexible ecosystem concept – the Flexible Software Package (FSP), built on FreeRTOS – and is expandable to use other RTOS and middleware solutions.

If you are interested in wolfBoot support on the RZ/N2L or have questions about any of the above, please contact us at facts@wolfSSL.com or call us at +1 425 245 8247.

Download wolfSSL Now

wolfBoot v2.0.0 intel x86_64 support

wolfBoot v2.0.0 introduced support for the Intel x86-64 bit architecture by leveraging the Intel Firmware Support Package (Intel FSP) and several new exciting and interesting features: TPM integration, Multiboot2/ELF support, PCI support, AHCI support, SATA security features, and others.

On Intel x86_64, wolfBoot uses a dual stage design. In the first stage, It initializes the memory and the hardware with the help of Intel FSP. Intel FSP allows BIOS and bootloader developers to focus on the critical features and broad support without worrying about the hardware initialization details. After the memory and silicon initialization, wolfBoot enumerates and configures all PCI devices in the system.

In the second stage, when the hardware is up and ready, wolfBoot does the necessary steps to read, decrypt, verify, and safely boot the main application. We added support for AHCI controller, SATA disks and ATA security commands: the main application can now be stored in a password-locked hard drive!

In both stages, wolfBoot verifies each component loaded, either from system ROM or from the hard disk, plus the TPM support allows very interesting scenarios. First, it enables TPM-assisted measured boot: each component loaded into the system is “measured”, taking part in an integrity proof managed inside the TPM itself so that certain operations are allowed only if the system is in a trustful state. The TPM can store (“seal”) secrets that can be recovered (“unsealed”) only if the system is in a precise state. If compromised software is running on the target, the secret never leaves the TPM.

In wolfBoot we leverage this by sealing the disk password (randomly generated at the first boot) in the TPM and binding the unsealing to a precise state of the system. If the loaded components are compromised or if the disk is removed from the device for direct tampering, the disk can’t be unlocked at all!

Once the disk is unlocked, it’s time to load the application in the right place and communicate the current hardware situation before booting. wolfboot supports the Multiboot2 standards to communicate with the main application and it supports the Executable and Linkable Format (ELF) format, one of the most ubiquitous object file formats for binary distribution, to load the application in the right places into the memory. As it supports memory virtualization, the application can be loaded anywhere in the address space, even above the 4GB limit.

And, as always, all current features of wolfBoot such as verified boot, OTA firmware secure update with power-fail tolerance, delta updates, encrypted firmware, and post-quantum firmware verification, will be directly available on the Intel x86-64 architecture.

All these new features are supported on the VX3060 Kontron board and can be tested on QEMU, but new hardware will be supported soon. If you have a new Intel-based board you would like to have supported or for any other comments, feedback or questions, don’t hesitate to contact us at facts@wolfSSL.com or call us at +1 425 245 8247.

Download wolfSSL Now