wolfBoot is wolfSSL’s universal secure bootloader. It was initially designed to bring secure boot technology to small 32-bit microcontrollers following the guidelines of the IETF SUIT group. But nowadays, it’s used on a large number of heterogeneous devices, from IoT connected systems with limited resources, to faster, more powerful 64-bit embedded Linux systems. Examples of systems which wolfBoot has been successfully used with include STM32, SiFive HiFive, LPC5406, Cortex-A54, ARMv8, Xilinx Zynq UltraScale+, NXP Kinetis, TI CC26x2, and Atmel SAMR21.
One of the most evident strengths of our implementation is the flexibility to integrate secure boot and remote updates with any Operating System. This aspect, combined with the drivers and the support available for large numbers of target platforms in continuous expansion, gives us the possibility to bring secure boot technologies and reliable firmware updates to various embedded projects.
Secure Firmware Updates
One of the aspects that allows wolfBoot to interoperate with the existing infrastructure in every IoT project is given by its unique “transport-agnostic and highly reliable remote firmware update mechanism”.
wolfBoot in fact doesn’t rely on specific protocols or data link interfaces used to transfer the updated images from the infrastructure to the firmware consuming devices. We know that every project uses different communication links and protocol families to reach the device fleet from the back-end server responsible to distribute the firmware updates. The communication between the infrastructure and the device itself is usually already implemented in the software running on the system, and used to exchange assets and data over some project-specific transport layer.
We always recommend using secure socket communication whenever possible, and rely on the existing standards such as MQTT-over-TLS, SSH or HTTPS and other REST services, offered by the major cloud service providers (Microsoft Azure, AWS, Google Cloud, etc.). wolfSSL provides a range of libraries, implementing the latest standards available, to access these services from embedded systems.
In smaller systems, there is rarely the possibility to replicate the software stack needed to
realize data transfers in both the application and the bootloader contexts. For this reason, transferring the firmware image to the target device is a task that is left as responsibility for the application itself. The only requirement for the application is to use any existing communication channel to transfer the signed firmware update image from the back-end to the device, and store it to a local non-volatile memory at a predefined address. Upon the next reboot,
wolfBoot will take care of validating, authenticating and installing the update if all the necessary checks are successful.
How to implement remote transport-agnostic updates using wolfBoot
Alongside with the bootloader itself, wolfBoot provides tools and mechanisms to integrate with the process of uploading and distributing signed firmware images.
The first step consists in creating a valid firmware image, containing all the elements necessary for wolfBoot to identify, validate and authenticate the update. The most important tool is a host application, “sign”, provided in two versions (python and portable C) in the wolfBoot distribution. This tool is used to compose the manifest header and attach it to the actual firmware. wolfBoot uses the information contained in this header to verify the integrity and the authenticity of the firmware before starting the installation of the update on the device.
In a typical scenario, the “sign” tool needs a version number to associate to the current release, and a file containing the private key, which can be created by the owner of the firmware, or derived from more complex operations when a specific provisioning system is used.
Given a firmware update in its original binary format, e.g. “firmware.bin”, a version number (say “2”) and a previously generated private key (e.g. ecc256.der), the signed image can be obtained by running:
sign.py --ecc256 --sha256 firmware.bin ecc256.der 2
The resulting image `firmware_v2_signed.bin` can be transferred to the target, using any protocol. We always recommend to transfer any sensitive data, such as firmware updates, through a secure connection, by using wolfSSL, wolfSSH, curl, or wolfMQTT. However, any custom transfer mechanism can be adopted to distribute the firmware updates through the application.
libwolfBoot: Interact with the bootloader from the application
LibwolfBoot is a library provided within the wolfBoot package which is used to interact with the bootloader, in particular to notify wolfBoot that a new firmware update has been stored on the designed NVM partition, and it is ready to be checked by the bootloader at next reboot, and to confirm that the current image is running properly.
While the firmware is being received on the target, it must be stored into the UPDATE partition. This can be done using existing drivers and support in the application or, alternatively, by using the same driver that wolfBoot uses to access non-volatile memory supports, which is made available through libwolfboot.
For an overview of the libwolfboot API, check out the documentation here.
Updating the process and automatic backup of last known working image
Once the image is stored at the designated position in the NVM of the target, the application calls the `wolfboot_update()` function to trigger the verification and the installation upon the next reboot. If the verification succeeds, a swap operation is initiated, which will replace the current running firmware with the newly received update and, at the same time, “will store a backup copy of the old firmware in the update partition”.
The swap operations implemented in wolfBoot are highly reliable and fail-safe. If the power is interrupted in the middle of the swap operation, wolfBoot will resume the swap from the last position. That is the reason behind the need of a SWAP partition in this process: two copies of the same page are always present during the swap, and the progress is tracked through flags indicating the last-known successful operation when moving the content across the two partitions.
Every time that the application starts properly, it should communicate to the bootloader that the execution of the firmware is successful. This is done by calling the `wolfBoot_success()` function after the initialization of the services in the application. If it’s the first time that this function is called for that specific version, the library will set a flag in a special position on the internal flash (only once). This way the bootloader knows that the update procedure is complete and that specific version is valid. If the `wolfBoot_success` function is never reached for any reasons, the bootloader will automatically perform a roll-back, restoring the backup of the previously working image that is stored in the NVM during the installation process.
If the new version is not confirmed by the application itself, or whenever the image installed is damaged or corrupt, the bootloader will restore the state of the system before the most recent
update.
Optional firmware image encryption on external FLASH
wolfBoot offers the possibility to encrypt the content of the entire UPDATE partition, by using a pre-shared symmetric key which can be temporarily stored in a safer non-volatile memory area.
SWAP partition is also temporarily encrypted using the same key, so a dump of the external flash won’t reveal any content of the firmware update packages to a potential attacker.
This feature requires to encrypt the firmware image by passing an extra option to the “sign” tool, specifying a temporary symmetric key used for encrypting the update bundle at the source.
On the device side, an additional function is available in the libwolfBoot API, `wolfBoot_set_encrypt_key()`, which must be used to set the temporary key used by wolfBoot to decrypt the content of the UPDATE partition stored on an external NVM.
Detailed information on this feature can be found in the wolfBoot documentation here.
Conclusion
Reliable and secure remote firmware updates are a requirement for modern embedded systems that must take into account vulnerability management and use the correct procedures to keep the target systems updated.
The highly-reliable, transport-agnostic firmware update mechanism implemented using wolfBoot is portable across different operating systems and target platforms from different vendors. The procedure described in this article is just one of the possibilities available to implement a custom secure boot and firmware update mechanism based on wolfBoot. At wolfSSL we are constantly working to improve our solutions and we can provide customizations and adaptations to a wide range of more complex scenarios, including specific NVM configurations, hardware crypto accelerators, secure trust anchors and key provisioning mechanisms that involve third party trusted providers.
We understand how important security is in your IoT project, and we are the only company to offer 24×7 support on secure boot solutions for remote firmware updates.
Contact us at facts@wolfssl.com with any SSL/TLS, crypto, or secure boot questions!