A new version of wolfBoot (1.10) has been recently released and can be downloaded from our website, or cloned from our github repository. A full list of features can be found in our Changelog.
As we recently announced, we have ported wolfBoot to run as an EFI application to verify the subsequent stages in the boot chain of a x86_64 PC. We have improved the configuration for some of the supported platforms and targets. Finally, because of improved support for delta updates and one new signature verification algorithm (Ed448), this new version adds even more unique characteristics that you won’t find in any other existing secure boot solutions.
Here is a summary of our users’ favorite unique features, now fully supported in wolfBoot 1.10:
Secure, compact, fast, FIPS-compliant cryptographic library
wolfBoot’s main task is to ensure that only a trusted firmware image can run on the target device, as indicated by RFC9019. 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.
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.
Simplicity and portability
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 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, and more). It can manage the initialization of Trusted execution environments (TEE) (e.g. TrustZone-M in ARM Cortex-M33).
The build-time configuration is concentrated in a single configuration file, and a command-line wizard is made available to ensure a quick and painless integration.
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.
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 through 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 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 system 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.
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.
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!
