RECENT BLOG NEWS

We are excited to announce an important update for our Apple device users: wolfSSL’s support for installed system CA certificates now extends to Apple devices! This means that applications can now use the convenient wolfSSL_CTX_load_system_CA_certs() API to authenticate TLS connections against certificates installed to the system trust store.

Due to recently introduced OS changes around application sandboxing, applications running on non-macOS Apple platforms can no longer directly access trusted certificates installed on the system. This prevents these certificates from being enumerated and loaded into wolfSSL to use for authentication.

To accommodate this API restriction, we have introduced a new certificate verification routine that relies on Apple’s Security framework APIs to authenticate peer certificates. TLS peer certificates are first checked against the trusted CAs loaded into wolfSSL’s certificate manager, as they always have been. However, if this check is unsuccessful, wolfSSL will now attempt to validate the peer certificate chain using the system trust APIs. This new routine is only used when support for system CA certificates is enabled and when compiling for an Apple target.

If you are building wolfSSL for iOS using configure, this new feature will be on by default and no additional configuration is required by the user. If you are building with a user_settings.h file, you must define the WOLFSSL_SYS_CA_CERTS and WOLFSSL_APPLE_NATIVE_CERT_VALIDATION preprocessor macros, as well as ensure you are linking wolfSSL against the Apple CoreFoundation and Security frameworks. Calling wolfSSL_CTX_load_system_CA_certs() before creating a new TLS connection will now enable system CA certificates to be used for authenticating a peer connection.

To use this feature on MacOS, the steps are the same except that you must define the WOLFSSL_APPLE_NATIVE_CERT_VALIDATION preprocessor macro even when building with configure, as the feature is not on by default.

If you are using cURL + wolfSSL, ensure that the feature is enabled in your wolfSSL build as described above, then set the CURLSSLOPT_NATIVE_CA curlopt in your curl application to indicate the native certificate verification routines should be used.

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

Download wolfSSL Now

Designed by Freepik: www.freepik.com

We are adding 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. See our video series with ST for a tutorial on using wolfBoot.

See the STM32C0 announcement from ST.

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

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

If you are interested in trying our wolfBoot on the STM32C0, curious about post-quantum signature support in wolfBoot 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

How to access them, use them, and what sets them apart.

Join us for an informative webinar on the release of wolfSSL’s SM cipher implementations, presented by wolfSSL Senior Software Engineer Sean on November 3rd at 12pm AEST. This webinar is scheduled for Australian time to cater to our audience in the Asia Pacific region.

Save the date: 11/3/2023 at 12pm AEST

As many are aware, Chinese government regulators are now mandating use of SM2, SM3 and SM4 in critical systems, including automobiles, avionics, power systems, and communication systems. Since many of our customers are multinationals that conduct business in China, they have expressed the need for the inclusion of these algorithms in wolfSSL products.

We recently released our supported versions of SM2, SM3, and SM4, with the intention to release the ZUC stream cipher at some point this year to completely satisfy SM9. We are also in contact with labs regarding support of OSCCA certification at some point in the future.

This is truly exciting news for our customers in the Chinese markets!

For those considering using wolfSSL products, here are 6 key benefits you will gain:

1. The SM Ciphers are fully supported in wolfSSL’s TLS 1.3 and DTLS 1.3 implementations.
2. wolfSSH, wolfBoot and our other products will support ShangMi ciphers.
3. ARM, Intel, and RiscV assembly is in the works for our SM implementations for maximum performance
4. We support bare metal for SM2, SM3, and SM4.
5. We have maximized performance and minimized size, so the ShangMi algorithms will work well for embedded systems use cases on a wide variety of microcontrollers (MCU’s). They will be available for all of the MCU silicon that we currently support, including STM32, NXP i.MX, RISC-V, Renesas RA, RX, and Synergy, Nordic NRF32, Microchip PIC32, Infineon Aurix, TI MSP, and many others.
6. Our GPLv2 versions of the SM ciphers are available for download on GitHub

Commercially licensed versions are available.

Sean will delve into the insights of SM Ciphers and explain how you can effectively employ SM Ciphers with wolfSSL. Bring all your questions related to ShangMi Ciphers and algorithms; Sean is ready to answer them all.

Sneak peek of the SM Ciphers webinar:

• Background of the ShangMi Ciphers: SM2, SM3, SM4
• TLS and SM Ciphers
• When to Utilize SM Ciphers
• wolfSSL and SM Ciphers
• Building wolfSSL with SM Ciphers
• Using SM Ciphers in wolfSSL
• Future Developments

Seats are limited! Register Now

If you have questions about the ShangMi ciphers and algorithms, please contact us at facts@wolfSSL.com or call us at +1 425 245 8247.

Download wolfSSL Now

With our recent release of version 1.6, wolfSentry now natively supports CAN bus, with idiomatic bitmask-based address matching. Addresses and bitmasks can be supplied as hexadecimal, octal, or decimal numbers, supporting both 11 bit part A and 29 bit part B addresses.

Indeed, all address families now support bitmask matching, including user-defined address families, with computational overhead confined to bitmask-matched families. When using JSON configuration, bitmask matching is a simple matter of supplying a “bitmask” rather than a “prefix-bits” value for an endpoint. Bitmask-matched addresses can also be supplied directly through the API, using WOLFSENTRY_ROUTE_FLAG_REMOTE_ADDR_BITMASK and WOLFSENTRY_ROUTE_FLAG_LOCAL_ADDR_BITMASK. Consult the documentation for details.

Speaking of documentation, wolfSentry now includes a comprehensive developer’s manual, fully detailing the API, JSON configuration, build flags, and basic application integration in FreeRTOS-lwIP. The new API manual is available both as a bundled pregenerated PDF file at doc/wolfSentry_refman.pdf, and as Doxygen-generated HTML by running “make doc-html”.

Release 1.6 also includes additional portability improvements, allowing for full functionality in a newlib-nano runtime with a C89 toolchain. Callbacks are provided for all system facilities, assuring easy porting.

The latest wolfSentry release is available on GitHub, with native in-tree support for 32 and 64 bit targets and POSIX, DeOS, FreeRTOS, and MacOS X runtimes. Let us know if you would like it on another platform. Our current porting plans include Green Hills IntegrityOS, VxWorks, LynxOS, PetaLinux,TRON/ITRON/µITRON, QNX, PikeOS and NuttX. Clone it now, and make test!

Please contact us at facts@wolfSSL.com or call us at +1 425 245 8247 with any questions or for help getting started with wolfSentry in your project!

Download wolfSSL Now

wolfSSL is proud to announce that wolfCrypt is being used to secure Espressif ESP32 devices on the Apple ® HomeKit ecosystem. Use wolfSSL on your own ESP32 (or any other embedded device!) along with the many other commercially available Apple Home Accessories to control and monitor nearly anything. Use wolfSSL encryption to keep communication between devices secure.

We recently became aware of the popular open source Homekit project that [AchimPieters] is working on with the esp32-homekit-demo. See also the Espressif Homekit SDK and the Apple HomeKit ADK.

Any good demo starts with a Hello World application. In the world of embedded devices, that’s of course typically the blinking LED. Check out the Homekit LED Example. Special thanks to [Julien C] that helped test and fine-tune wolfSSL to work with the demo and his iPhone!

Which Espressif device do you have? The classic ESP32? The updated ESP32-S3? Perhaps the RISC-V ESP32-C3? We support them all.

Just getting started with wolfSSL? Check out our blog on wolfSSL as a Managed Component and the Preview Blog for wolfSSH and wolfMQTT Managed components. You can add wolfSSL support to your Espressif project with just one line:

idf.py add-dependency "wolfssl/wolfssl^5.6.0-stable"

If you have an ESP32 product idea for the Apple Homekit or some other platform, or questions about any of the above, please contact us at facts@wolfSSL.com or call us at +1 425 245 8247 to learn more. We work with any size organization from the smallest garage maker to the largest Fortune 500 companies.

Download wolfSSL Now

Designed by @Noxifer81

In general, a “glitch” is a momentary fault that may happen on a system, preventing it from working properly, for a brief amount of time. The effects of a single glitch on proper software execution may be multiple, including catastrophic consequences that may prevent the system from continuing the execution.

Glitching attacks are complex and expensive to execute, but can be a real issue for secure boot mechanisms, and often very hard to prevent or mitigate. They aim at exploiting predictable consequences of single glitches in order to take control of the execution or the data contained in the system. The glitch can be injected using different techniques, which often rely on well known weaknesses of the specific microcontroller or CPU. The most common glitch injection consists in varying the voltage supplied to the chip at a specific time, or modifying the profile of the clock signal to mangle the timing of the execution of the instructions. More advanced attacks can rely on irradiating the device with strong electromagnetic interference.

In the specific context of secure boot, the goal for an attacker is to circumvent the security checks in those critical sections of the code, e.g. the code that performs verifications on the firmware authenticity, integrity or versioning. These attacks could eventually defeat the security checks, and take control of the system by uploading an unauthorized firmware image. While they require an accurate synchronization and several attempts, these attacks will eventually succeed in injecting a fault in the hardware at the required time in order to skip the verification.

Our secure bootloader, wolfBoot, follows the indication of RFC9019 to provide a secure, public key based verification of the integrity and authenticity of the firmware and its updates. It runs on several different architectures, from small microcontrollers up to x86_64 systems. wolfBoot is OS-agnostic and provides best-in-class security thanks to the FIPS 140-2 certified algorithms implemented in the wolfCrypt security engine.

wolfBoot already comes with plenty of unique features. Now it is also the first open source secure bootloader to implement mitigations against glitching attacks. Our development team has added an optional feature that can be activated at compile time, to reinforce the security of the critical variables and decision points in the code. This has required an evaluation of the code flow of wolfBoot from a point of view that includes the possibility for an attacker to skip single specific instructions. Introducing these mitigations has been tricky, because redundant code written in C is usually discarded by the compiler. For this reason the countermeasures must be programmed in assembly, which makes this code architecture specific.

Our latest release of wolfBoot v1.11 contains these countermeasures. Glitching support mitigation can be freely compiled and used in GPL projects for evaluation and auditing purposes.

To compile wolfBoot with glitching and side-channel attack mitigations turned on, it is sufficient to add ARMORED=1 to the configuration options (i.e. via command line when invoking make, or through the .config file). The ARMORED option is currently supported on ARM Cortex-M architecture. Support for other architectures will be added in the future.

You can download wolfBoot today from our download page or from our github repository

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

Designed by @Noxifer81

wolfBoot is known for being the universal secure bootloader for all types of embedded systems.

While initially targeting 32-bit microcontrollers, wolfBoot has grown into a full framework to implement secure boot solutions on a wide range of different systems and architectures.

This is mostly due to wolfBoot modularity and flexibility, which makes our solution easy to reshape and adapt to the most peculiar use cases. Here are a few examples of customizations we have facilitated in the past, taken from real-life use cases.

Update images stored on external devices

This type of customization is perhaps the most popular. wolfBoot offers an interface to interact with external storage devices or anything that can be abstracted as such: the “ext_flash” interface.

Ext_flash is an interface that connects wolfBoot to a driver that implements the following function calls, to access the content of specific storage devices

ext_flash_lock()

ext_flash_write()

ext_flash_read()

ext_flash_erase()

ext_flash_unlock()

On microprocessor-based embedded systems, ‘external’ devices are often the only solution, requiring specific drivers to access the kernel images on different supports (USB, SD, eMMC, SSD, etc.). Microcontroller architectures often integrate external NOR SPI/QSPI flash memories that can be used as persistent storage, where generally it’s not possible to execute code in place.

wolfBoot has an additional layer directly supporting several types of SPI flash memory chips. The SPI support is also implemented on top of the ext_flash API interface, and provides another level of abstraction. In this case porting to a new target with an SPI controller only requires to implement the following single SPI transfer functions, and the SPI layer will link the required functions to access the flash through this interface:

spi_init()

spi_cs_on()

spi_cs_off()

spi_read()

spi_write()

spi_release()

SPI access is just one of the possibilities available in wolfBoot to extend the support to any non-volatile memory, and beyond.

Update images downloaded on-demand from neighbor systems

By design choice, wolfBoot does not include any network stack or communication capabilities besides the access to storage devices and internal flash memory. This is an advantage both in terms of security because it makes the attack surface very small, and from the safety point of view keeping all the structures and code flow simple to follow and predictable.

In some cases it’s required to communicate with other systems during the boot stage, because the firmware image or the updates received may be stored elsewhere, avoiding to split the flash memory to make room for a second partition. In these cases, wolfBoot may be required to open a communication channel (usually through a serial bus such as UART or SPI) to retrieve the firmware images from a neighbor system. This is in fact a rather common requirement when wolfBoot is securing the boot procedure on asymmetric multiprocessor systems or in general systems with multiple heterogeneous cores.

The recommended way to access remote content from wolfBoot consists in defining a custom ext_flash driver that abstracts a virtual addressable memory space. wolfBoot codebase contains an example of ext_uart driver running the client endpoint connecting to the uart_flash_server POSIX application provided, that can export signed and encrypted files for wolfBoot to handle and stage. EXT_UART is yet again one of the possible modes to extend the external flash support to both physical storage supports and virtualized abstractions.

Third-party key provisioning

Provisioning keys is a process that may involve third party tools and entities that generate, store and use the main private key to sign the firmware images. Thanks to the flexibility of the key tools distributed with wolfBoot, keypairs can be both generated or imported (in their public format) within the signing process. While the public keys must all be available and accessible by wolfBoot at run time, the private keys are used to sign the header of each authentic firmware.

The actual signature operation can be detached from the manifest header composition, by splitting the two phases. This way the signing is performed by an external tool, and the private key does not need to be accessed during the operation.

For more information on the possibilities of customizing the signing procedure, please see wolfBoot signing tools documentation.

Storing keys in a secure vault

Storing the public keys used to authenticate the firmware in a secure, write-protected area of persistent memory is the most important security requirement for proper secure-boot mechanism. In many cases it is sufficient to execute wolfBoot from a write-protected area, and keep the keys stored along with the bootloader code, in a C array. This is the default mechanism implemented in wolfBoot.

When the keygen tool generates or imports public keys, it creates two copies of the local archive of the public keys needed at runtime for signature verification, in two different formats. The C array (keystore.c), to be built in the bootloader image, and a binary file (keystore.der) containing the same structure in binary format.

By excluding keystore.c, it is possible to upload the content of keystore.der into a dedicated secure or write-protected storage. A driver to access the secure vault at runtime must be provided, through an API exporting three functions for wolfBoot to retrieve the public keys, their sizes and their permissions mask. Using a separate abstraction layer for the keystore provides an interface that can be customized beyond classic secure element or TPM interactions, to design a more complex structure to handle keys at runtime. More information available in the wolfBoot documentation page about keystore structure.

Unique partition/images and keys combination

Multiple-stage boot layouts can get very complex. Our development team has learned a lot when designing the boot process involving a set of partitions and firmware images with different levels of access permissions for the first time. Since then, we have dealt with several scenarios where multiple actors had to be capable of updating only one subset of partitions with firmware authenticated with specific subsets of public keys.

Consider the following scenario: an embedded device with a secure bootloader and two partitions: a “system” partition (perhaps running in secure mode from a TEE) and an “application” partition, containing configurable software that can be uploaded by a registered user that owns or has access to the device. Two separate keys are needed in this case: the user should only be able to send signed updates for the application partition, while the manufacturer must be able to update the system software (and the bootloader itself, if needed). The two levels of privilege in this case require two separate keypairs, the first one can be associated with the user, and the second with more powers should be kept by the manufacturer.

The latest wolfBoot, thanks to the keystore structure, supports up to 15 target partitions, and each one of these can be authenticated using one or more public keys from the keystore.

A firmware package in wolfBoot is always associated with an identification number (id) from 0 to 15, indicating the partition where the firmware must be installed. In the scenario described above, the ‘system’ would have id=1 and the ‘application’ software is associated with id=2. wolfBoot reserves id=0 for self-update procedure, i.e. update packages containing a new (signed) version of wolfBoot itself.

This mechanism allows the update mechanism to use the same update partition as temporary storage for all the updates, because wolfBoot will parse the incoming package and parse the manifest header to process the package using the right keys. The public key object elements in the keystore described earlier contain a bit mask that associates each key to the single target partition ids.

“Non-secure” boot

wolfBoot supports many different combinations of public key algorithms and key sizes. However, In some cases, authenticating the firmware is not a requirement. wolfBoot works properly when compiled with SIGN=NONE, excluding only the signature verification part, and keeping all the other features to facilitate the update, roll back in case of failure and verify the integrity of the firmware image after the transfer using SHA. That is, wolfBoot can be used as a non-secure bootloader, with a footprint of a few KB and very little impact on boot time. Especially useful in very small low-power systems with a tight amount of resources and CPU cycles.

wolfBoot as library: adding secure boot to legacy bootloaders

Among our customers, many have been upgrading older products and devices, reusing legacy software from previous versions, while stepping ahead with the security requirements which usually means adding a secure boot solution.

While starting a new bootloader from scratch is often an underestimated task from the development and testing point of view, many development teams rely on existing solutions that have been maintained and deployed on the field for years. Some custom bootloader solutions include network communication, sometimes with proprietary protocols and data links which would require a major effort to integrate into a vanilla wolfBoot. On the other hand, most of these legacy solutions lack the needed security features to implement cryptographic secure boot.

For this reason we have introduced the possibility to build wolfBoot as a library. Instead of providing the entire bootloader implementation, including build-up, staging, specific hardware access and customized flows, ‘wolfBoot as library’ is completely portable anywhere and provides easy interfaces to parse the manifest header, check versioning, verify an image loaded or mapped in memory for integrity and authenticity against the provided keystore. The key tools on the hosts can be used exactly in the same way as with the full wolfBoot installation, as the format remains the same and it is completely independent from the hardware or the architecture. To learn more about using wolfBoot as a library, check the documentation page about the library API.

Find out more about wolfBoot! Download the source code and documentation from our download page, or clone the repository from github.

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

Secure Avionics Boot-up with wolfSSL & Intel & AFuzion

We are thrilled to announce that we are partnering with Intel and AFuzion to host a webinar this week. Join us for the Bootcamp: Is YOUR Avionics Boot-up Secure? on October 25th at 8 am PT.

Save the date: October 25th | 8 am PT

Safe, operational, and secure avionics systems are built upon a strong foundation of secure boot and secure firmware updates. Certifications such as DO-178C are oftentimes required, and finding solutions that bring this all together can be challenging. Learn how this foundation can be achieved by using a complementary combination of secure hardware solutions from Intel along with wolfBoot, a secure bootloader from wolfSSL. wolfBoot provides a portable, certifiable, bootloader and firmware update solution which is able to leverage Intel technologies such as AES-NI and AVX2 for improved boot performance and security.

Don’t miss out on this opportunity to learn how you can achieve maximum security in avionics from three top-notch companies. This is your chance to gain knowledge about our secure bootloader and enhance your technical skills.

Register now to secure your seat.

This webinar will include Q&A sessions throughout. If you have questions on any of the above, please contact us at facts@wolfSSL.com or call us at +1 425 245 8247.

Download wolfSSL

Designed by @Noxifer81

At wolfSSL, we have been developing secure boot solutions with customers for many years, and more recently we have released wolfBoot version 1.16, a secure bootloader designed for embedded systems.

wolfBoot provides reliable support to remote firmware updates on a wide range of devices, supporting the most common architectures (ARM TrustZone-M, ARM Cortex-M, ARM Cortex-A, ARM Cortex-R RISC-V RV32, PowerPC, and x86_64 via UEFI).

wolfBoot supports all types of RTOS and embedded operating systems, so it can be used to boot FreeRTOS, Contiki, RIOT-OS, ChibiOS, ThreadX, VxWorks, QNX, TRON/ITRON/uITRON, Micrium’s uC/OS, FreeRTOS, SafeRTOS, Freescale MQX, Nucleus, TinyOS, TI-RTOS, uTasker, embOS, INtime, MbedOS, Linux, and many more…

Here is our list of the top ten interesting facts about secure boot.

1. Trusted firmware updates have become a requirement for IoT projects

IoT devices are not immune to cyber attacks, and many real-life cases have proven that misconfigured systems may even be an easier challenge for an attacker, and sometimes even compromise the entire distributed system from a single vulnerability in one software component.

Vulnerabilities happen. No matter whether the software is completely written from scratch or depends on third party components, defects in the implementation may surface at the worst time possible for the project timeline, and critical systems cannot afford to keep vulnerable versions running. At wolfSSL we know that security software development never sleeps. As soon as new vulnerabilities are discovered, the entire team immediately switch their focus on delivering a fix, launch all the tests and release a new version of the software.

IT services may already benefit of continuous deployment mechanisms to ensure that new versions of the software components are available to run just after they have been updated and delivered. This is a good way to reduce risks related to running outdated software in production.

Why should similar mechanisms not be widely available on embedded systems? Well, the question is complicated, due to a few aspects. The diversity of microcontrollers available on the market poses quite a few challenges for embedded systems developers to provide a unified mechanism that fits all the scenarios, use cases, platform specific hardware and sometimes unique communication interfaces and protocols. Moreover, embedded software is generally installed from a monolithic

binary file, containing a 1:1 match to the physical content of the non-volatile memory onboard. Updating a single component may be tricky unless there has been some specific partitioning mechanism in place.

The effort for defining the guidelines for a secure and safe firmware update mechanism have been lead by the SUIT group within IETF, which has studied the problem and has produced a standard RFC9019. “The document […] lists the requirements and describes an architecture for a firmware update mechanisms suitable for IoT devices.”

2. Updates are verified using public-key signature authentication

The key feature offered by a secure bootloader following the SUIT definition is the use of state-of-the-art cryptography to guarantee the authenticity of the current firmware and the updates that are coming from a remote source. By using public-key based authentication it is possible to verify that all the software on board before running it.

The mechanism is quite simple: the owner of the device creates a key pair. The private key is secret, it is never revealed or stored on the device itself. The private key is used by a script or a program to sign the manifest header, which is transmitted alongside with the binary image of the new software. The manifest header contains all the meta-data associated to the firmware image.

The bootloader can access a copy of the public key, as it is stored on the non-volatile memory on board, or on a specific hardware secure vault. The public key is not a secret, and even if revealed, it does not pose any risk for the secure boot process.

When the bootloader receives the update package, it uses the public key to initiate the verification. Only software that contains valid metadata, including a verifiable signature, will be allowed to run on the target.

3. Operating with small bootloaders

The secure bootloader is, in many cases, the only immutable part of an embedded system. SUIT specifications assume that in general the bootloader itself will not be uploaded because this may pose a risk in reliability. For this reason, one of the requirements for the implementation of a secure bootloader is to keep the bootloader small, and dedicate other components in the system to the task of transferring the firmware images and initiating the update.

This also means that code safety is critical in bootloader context, to guarantee the required level of reliability and minimize the attack surface. SUIT in particular mandates the use of small parsers in the code, since parsers are described as a “known source of bugs”.

One step further in this direction is to completely avoid dynamic memory allocations in the bootloader code. Measuring the memory usage at compile time and allocating static buffers for all the data structures significantly reduce the chance of memory management bugs such as overlapping of sections or heap-stack collisions when inappropriate memory mappings are configured.

A secure bootloader implementation cannot ignore resources and safety related requirements, or the risk is to create bigger issues than what it is expected to fix!

4. Rollback attacks

In the perspective of continuous vulnerability management, new updates are released and made available often. Unless the firmware images are transferred using a secure channel, such as TLS, there is always a risk that an old update is intercepted by an attacker, or anyone who is sniffing the traffic towards the firmware consuming device. This is particularly true in those broadcast-friendly environments, e.g. if the firmware images are distributed through a local mesh network that does not support secure socket communication.

An attacker may know about a vulnerability in a previous version, and attempt to downgrade the firmware on the target device to that specific version, by repeating the transmission of the firmware image previously recorded by wiretapping on the network.

A secure boot mechanism must retain the information about the firmware version alongside with all the other information in the manifest header. The version number, like the rest of the meta data, is enclosed in the envelope together with the firmware image during the signing process, which means that the version cannot be altered by an attacker without compromising the validity of the signature for the update package. The bootloader will not allow to install packages with a version number that is older than the one that is currently running on the system.

Rollback attacks are very easy to perform and preventing them is a key task for the secure bootloader.

5. Power failures and high reliability

According to Murphy’s law “anything that can go wrong will go wrong”. In the case of remote updates installation, the worst point to lose the power or having any kind of hardware glitch that results in a system reset is when the content of the non-volatile memory is altered during the installation of firmware updates. If a power cut occurs in the middle of a FLASH sector copy operation, the state of the destination sector is unpredictable upon the next boot.

A mechanism that can prevent this situation, like the one implemented in wolfBoot, consists in keeping always two copies of the same sector, and using a mechanism based on flags to confirm that each step has been completed. Upon reboot, the operation can be resumed from the last successful operation, so there is no risk of leaving the system in an unrecoverable state.

6. Secure boot and secure update transfers

Downloading the new version is a task for the embedded application, or a thread running on top of a real-time operating system. As indicated by SUIT, including the responsibility of transferring the firmware image in the bootloader code

would result in a bigger, more complex secure bootloader with external dependencies on protocol stack implementations and platform-specific device drivers. Embedded systems may in fact access the network picking from a variety of different connectivity technologies available. Not all of these technologies share the same protocol families or transport mechanisms. Some low power communication protocol such as LPWAN may even have stricter requirements on bandwidth or network availability.

wolfSSL is the embedded SSL/TLS library targeted for embedded systems. Being transport-layer agnostic that can provide secure socket communication on top of all kinds of data transfer technologies and operating system or bare metal applications.

Using the latest standard (TLS 1.3) to secure your connections means that devices can communicate to each other and to the back-end on end-to-end secured channels, using the best cryptography available as standard to date.

Some of the benefits of securing all the data in motion using TLS include of course encryption of all the data transferred between two endpoints, and optionally server-side identification for clients that access data, services or remote firmware updates.

On systems where the entire stack is deployed, including TLS socket communication, transferring the firmware images can be done over the same channel so that the update package can travel the network to the firmware consumer securely.

As TLS may not be an option for a subset of device with a very limited amount of resources available, at least encryption should be considered on such devices. wolfCrypt is a crypto engine targeted for embedded, RTOS and resource constraint environments, which is the core component of wolfSSL, but can as well used as standalone library to access the implementation of the most popular algorithms and cyphers.

7. Key management and trust anchors

In a distributed system architecture designed for remote firmware updates, key management is a critical task. The back-end system is in charge of keeping the private key (or keys) safe, and generating signed packages to distribute to firmware consumers when a new version is available.

wolfBoot is distributed with a toolbox of key management scripts and utilities that can be easily integrated on server side to facilitate these tasks. In the simplest case, the signature that is included in update packages is obtained using a private key which is accessible by the owner of the device. In some cases, a more elaborated key provisioning system is in place. When a separate software or hardware component is performing the signature step, the package creation process can be split to redirect and delegate the DSA step to another component.

The public key that is stored inside the embedded system is considered a ‘trust anchor’, because the trust in the validity of the remote firmware updates depends on the integrity of the public key used for digital authentication.

Trust anchor management is in general outside the generic scope of a bootloader itself because it depends on the hardware platform. However, it is of primary importance to include adequate protections against the risk of compromising the public key stored on the device and used by the bootloader to validate the authenticity of the firmware. A trust anchor store should be protected against write access using the available countermeasures available in hardware.

8. Secure elements and trust anchor stores

The best way of protecting trust anchors and other cryptographic material is using a hardware component that is designed for this purpose. Hardware security module (HSM, CAAM, etc.) usually offer both key storage and cryptographic operation acceleration in the same module. wolfCrypt, our crypto engine that powers wolfBoot, supports all possible schemes from a wide range of manufacturer-specific API to access this functionality, such as Microchip ATECC608A, ARM CryptoCell, NXP CAU/mmCAU/LTC, STMicroelectronic PKA, Infineon-Cypress PSoC6 and many others. Find the exhaustive list of hardware crypto we support here.

More recently, an effort of agreeing on the protocols used to the access to security cryptoprocessors, ISO/IEC standardized the TPM (Trusted Platform Module) format, which is in use nowadays in nearly all personal computers and notebooks. The same technology is now available for embedded systems thanks to wolfTPM, a library providing APIs to access TPM 2.0 compatible secure element. Popular TPM devices supported by wolfTPM include the ST33 and the Infineon 9670.

wolfBoot can as well be optionally compiled together with wolfTPM to make use of secure key storage and cryptography acceleration provided by these devices. It also support measured boot, storing the firmware hash into a TPM Platform Configuration Register(PCR).

9. Updating the bootloader

The SUIT proposed standard recommends that the small bootloader is immutable, due to the intrinsic complexity for the bootloader to implement a reliable way to update itself. However in some cases it is useful to have the possibility to update the bootloader code itself.

Consider for example a situation where the public key is built-in the bootloader code, key provisioning relies on a single private key and this key gets compromised on the back-end.

Another case is a long life product, where the algorithms or the key length in use by the bootloader code today may become obsolete, or compromised, by many years of research. In a few years it may become a requirement to update the bootloader code to match new requirements.

For these reasons we think that giving the possibility to update the bootloader code is important. wolfBoot can be optionally compiled to support this option. A special update package that is marked as wolfboot self-update will cause the bootloader to overwrite its own code after a successful validation of the package itself.

The bootloader update process is not completely fail-safe due to intrinsic hardware constraints, but it is sufficiently reliable to be used for those emergency cases described above.

10. Estimating the development effort

When approaching secure boot and remote updates, it is often too easy to underestimate the impact of this single task on the development cycle of the entire project. A large amount of effort is spent on guaranteeing the reliability of the system in all the possible cases that could occur when the device is deployed.

The bootloader is perhaps the most critical part of the system. Everything else in your application can break, as long as there is still a way to update it from a remote location. Implementing a secure bootloader from scratch for a specific project is a tough task which in some cases may require as much development and testing as all the rest of the software components in the system.

At wolfSSL we have several years of experience in supporting our customers to build secure boot and remote updates solutions, and we have designed wolfBoot to provide a solid platform that can be used as the fundamental building block that can fit any secure boot architectural requirements.

We are available to talk with you about your design and we are happy to provide design and development services to complete the integration with any custom embedded system.

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.

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

We are delighted to announce that the creator of cURL, Daniel Stenberg, will be hosting a libcurl training webinar in November. Libcurl is a free and user-friendly client-side URL transfer library that supports various protocols, including DICT, FILE, FTP, and FTPS, making it one of the most outstanding and widely used libraries for URL-based data transfer.

During the libcurl training webinar, you will have the opportunity to dive deep into libcurl and gain a comprehensive understanding of its applications. Daniel will showcase best practices and various use cases for libcurl, demonstrating how to utilize it in applications.

More details about the webinar will be provided soon, so please keep an eye out for updates. This promises to be one of the most exclusive events of the year, and it’s an opportunity you won’t want to miss.

For the latest updates and exclusive content, be sure to follow us on Twitter. You’ll be the first to receive updates about the webinar, ensuring you stay informed and prepared for this exciting event.

Get ready to learn and enhance your skill sets with Daniel Stenberg in November!

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