RECENT BLOG NEWS

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

If you follow us at wolfSSL, you’ll know we’re excited about post-quantum cryptography. For example, our recent DTLS 1.3 implementation supports post-quantum KEMs and signatures, and we just added support for post-quantum LMS/HSS signatures to wolfCrypt and wolfBoot. The latter was motivated particularly by the NSA’s CNSA 2.0 suite timeline, which specifies that adoption of stateful hash-based signature schemes (the kind recommended in NIST SP 800-208) should begin immediately. These signature schemes are valuable because they combine small public keys with relatively fast signing and verifying, and their signature sizes and key generation times are tunable via their different parameters.

You probably also know that both XMSS/XMSS^MT and LMS/HSS were recommended in NIST SP 800-208 and the NSA’s CNSA 2.0 suite. Hence, we are pleased to announce we are adding support for XMSS/XMSS^MT signatures to wolfCrypt, which will be accomplished by experimental integration with the xmss-reference implementation for RFC8391, similar to our previous post-quantum integrations with libOQS and hash-sigs LMS/HSS. You can read more about it in these XMSS pull request links:

• https://github.com/wolfSSL/wolfssl/pull/6840
• https://github.com/wolfSSL/wolfssl-examples/pull/403
• https://github.com/wolfSSL/documentation/pull/110

Our XMSS integration relies on a patch to xmss-reference that allows it to offload SHA operations to wolfCrypt, and thus allows it to leverage the same cryptographic hardware acceleration as wolfCrypt. The speedups improve performance for key generation, signing, and verifying. Another detail you might have noticed in our patch is that it includes wolfBoot XMSS support – for more information on that, please stay tuned!

If you are curious to learn more, or have questions about any of the above, please email us at facts@wolfSSL.com or call us at +1 425 245 8247.

Download wolfSSL Now

ExpressVPN has merged DTLS 1.3 support into their lightway-core library. This is the library that implements their modern Lightway VPN protocol. Lightway is a new protocol and built from the ground up with privacy, security, speed, and reliability in mind. Currently it depends on DTLS 1.2 and TLS 1.3 but with the addition of DTLS 1.3, it opens up a whole new set of possibilities. Lightway will be able to push what is possible in every aspect. The pull request implements new DTLS 1.3 API’s from wolfSSL.

wolfSSL is the first TLS library to adopt and implement DTLS 1.3. DTLS 1.3 has many improvements over DTLS 1.2 in areas of security and reliability. One of the biggest and most important changes is the addition of acknowledgements to the protocol. In DTLS 1.2, when a peer has detected a network failure (for example a packet was dropped or a timeout has been reached) it had no choice but to resend the entirety of its previous flight. In DTLS 1.3, the peer can just send a minimal acknowledgement packet that also specifies exactly which messages it is missing. It cuts down drastically on how much data has to be transmitted and saves both peers from having to resend entire flights if just a part is missing.

Another advantage of DLTS 1.3 over DTLS 1.2 is that it is based on the TLS 1.3 protocol. TLS 1.3 is currently receiving many exciting new additions and all this work benefits DTLS 1.3 as well. Post-quantum cryptography (PQC) ciphersuites are actively being researched in TLS 1.3 and it is unlikely they will be backported to TLS 1.2. DTLS 1.3 benefits from this research and wolfSSL can support arbitrarily large PQC keys in DTLS 1.3! One more example is the Encrypted Client Hello (ECH) which makes the connection fully private by not leaking any sensitive information (like the Server Name Indication extension) in plaintext. For a full description, please take a look at our ECH feature announcement.

DTLS 1.3 also benefits from the filtered list of available ciphers. Legacy and deprecated algorithms have been removed from the protocol and are no longer supported. All the ciphers are AEAD ciphers that provide increased security and performance.

For a full discussion of the differences between DTLS 1.2 and DTLS 1.3 please see our analysis blog. For any questions regarding DTLS 1.3 and wolfSSL please contact us at facts@wolfSSL.com or call us at +1 425 245 8247.

Download wolfSSL Now

wolfSSL and CodeSecure are partnering to host a webinar on October 19th at 10 AM PT, discussing the significance of testing in embedded software. wolfSSL Engineer Andras and CodeSecure VP of Global Solutions Engineering, Mark, will discuss how each company processes testing to deliver safe and secure embedded software that requires a rigorous focus on automated testing.

Save the Date: 10/19/2023 at 10 AM PT

You will gain insights into how wolfSSL will proceed with their testing mandate and how their focus on testing allows them to innovate with high quality, portable, embedded security software. CodeSecure will explain how Static Application Security Testing (SAST) is a crucial pillar in any automated testing workflow and how CodeSonar can be used both in developer pipelines as well as in daily testing cycles to find problems that dynamic testing may miss. Additionally, this webinar will review a few examples of defects that CodeSonar has detected and that were recently fixed in wolfSSL.

This is your opportunity to learn about the importance of testing in embedded software and uncover the secrets behind high-quality software from two industry-leading companies.

Seats are limited, so register now!

As always, our webinars will include Q&A sessions throughout. 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

wolfSSL makes a great effort to support a variety of open-source projects and the latest addition to the list is the disk encryption utility, VeraCrypt. With our recent porting effort, users will be able to leverage the VeraCrypt application with our cutting-edge crypto library, wolfCrypt.

VeraCrypt is packed with highly customizable security features employed to create and mount encrypted virtual disks as real disks, in addition to supporting entire/partial partition encryption and hidden volumes. Plugging wolfCrypt into the project makes VeraCrypt the ideal solution for users with performance and FIPS validation requirements.

Follow the instructions here to set up VeraCrypt with wolfCrypt.

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

Here at wolfSSL, we’ve got a new product that should interest you! We love it when we can help make potentially painful decisions easier for our customers.

Have you switched over to the 3.x series of releases on OpenSSL? It was likely a very large investment in time and human resources, but you needed to because the 1.1.1 series of releases recently went EOL (End of Life) in early September. Congratulations if you successfully completed your migration.

If after that migration you suddenly have a new FIPS 140-3 requirement, you’re probably wondering what a FIPS canister is going to look like for the the 3.x series of releases of OpenSSL. You’re likely aware that they are no longer supporting the “engine” interface and have moved to the “provider” model. There is a fips-provider, but if you look at the documentation you’ll note that it only provides FIPS 140-2. What about FIPS 140-3? Unfortunately, there is no support for it. When will OpenSSL’s certification for FIPS-140-3 be ready? No one knows; not even the OpenSSL Team.

What about wolfSSL? Our wolfCrypt FIPS product is right on the cusp of being granted FIPS 140-3 certification. How does that help you? Well, we have a wolfProvider product that provides the glue between OpenSSL 3.x series of releases and wolfCrypt FIPS. To use wolfProvider and wolfCrypt FIPS you don’t even need to recompile OpenSSL nor your applications. Just specify where wolfProvider is located via configuration file, install the wolfssl library to the default system location and you’re good to go!

Go ahead and take it for a spin! You can find wolfCrypt FIPS as part of the wolfssl fips-ready release which you can download and wolfProvider in its github repo all under GPL licensing terms until you want to use it for commercial purposes.

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 excited to announce that wolfCrypt now supports the EAX mode of operation for AES!

AES EAX is a two-pass authenticated encryption scheme that is optimized for simplicity and efficiency. More details about the algorithm can be found in EAX: A Conventional Authenticated-Encryption Mode, by M. Bellare, P. Rogaway, and D. Wagner.

To enable AES EAX in your wolfSSL build, simply pass the –enable-aeseax flag to configure. If you are building without autotools, you must define the WOLFSSL_AES_EAX preprocessor macro, as well as enable support for the AES CTR and CMAC algorithms by defining WOLFSSL_AES_COUNTER, WOLFSSL_AES_DIRECT, and WOLFSSL_CMAC.

The AES EAX API and a brief usage example can be found in the wolfCrypt AES API documentation. For a complete example, please refer to the aes_eax_test() function in wolfcrypt/test/test.c.

Please contact us at facts@wolfSSL.com or call us at +1 425 245 8247 with any questions, comments, or suggestions.

Download wolfSSL Now

Are you interested in integrating wolfSSL into OpenSC for smart card support?

We’ve been pondering this idea as well, especially after hearing from a few customers. But, we’re eager to know if there’s a broader interest out there and would greatly appreciate your feedback.

If the prospect of using wolfSSL within OpenSC intrigues you, we’d love to hear from you! Please don’t hesitate to reach out to us at facts@wolfssl.com. Your insights and input can play a crucial role in making this integration a reality. Let’s explore the potential together!

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

The FIPS Training Webinar returns on October 12th at 10 AM PT, presented by wolfSSL Senior Software Engineer Kaleb. Join us for an exciting opportunity to enhance your understanding of FIPS and gain valuable insights into its implementation from wolfSSL as the current leader in embedded FIPS certificates.

Save the date: 10/12/2023 at 10 AM PT

Sneak peek of the webinar:

• Public resources for the FIPS module
• The Security Policy
• Locating and using the User Guide or Cryptographic Officer Manual
• Quick recap of the material
• Best Security Practices at the application level

Kaleb will provide in-depth insights of FIPS. This is your exclusive opportunity to expand your knowledge and familiarity with FIPS. Bring all your FIPS-related questions; Kaleb is ready to answer them all.

Seats are limited! Register Now

As always, our webinars will include Q&A sessions throughout. 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