RECENT BLOG NEWS

So, what’s new at wolfSSL? Take a look below to check out the most recent news.
Or sign up to receive weekly email notifications containing the latest news from wolfSSL.
In addition, wolfSSL now has a support-specific blog page dedicated to answering some of the more commonly received support questions.

Deprecation of FIPS v1

Here at wolfSSL, we have been supporting your FIPS needs for several years now with our FIPS Ready, certificate #2425 and certificate #3389 source bundles.  This support is going to continue with the soon to be granted FIPS 140-3 certificate. With the new certificate coming soon, we thought this might be a good time to do a bit of house cleaning.

As certificate #2425 has been added to the NIST sunset list as of June 2021, we will be removing the FIPS v1 feature from wolfSSL.

Customers who still need this feature are encouraged to move to the upcoming FIPS 140-3 certificate if timelines permit.  However, if customers need a solution in the near term, they can move to certificate #3389 which sunsets in 2024.  Customers who will be impacted by the removal of this feature for any reason are encouraged to get in touch with their account representative or email us at .

Top 10 wolfSSL Library Configurations

Here at wolfSSL, we strive to support our customers’ needs for customization and finding the right trade-offs. The following table is a list of the top 10 things you can do with wolfSSL’s configuration flags.

Task Configure Flag(s) Details
Get Ready for Your First FIPS Customer –enable-fips=ready You will need to have a fips-ready bundle which is available as both an open source code bundle or under a proprietary license.
Become DO-178 Compliant –enable-sp-math We have taken ECC in sp_c32.c in the SP-Math Library through DO-178C certification.
Make Your Application Secure from Side-Channel Attacks –enable-sp-math –enable-sp-math-all

CFLAGS=”WOLFSSL_SP_CACHE_RESISTANT”

or

–enable-fastmath –enable-harden 

Our SP-Math Library is always timing resistant and runs private key operations in constant time.  Our Fast Math Library can be made timing resistant by enabling the hardened build.
Reduce Your Stack Usage –enable-smallstack and –enable-smallstackcache Allocating memory on the heap will be favored over the stack.
Reduce Your Heap Usage –enable-static-memory All memory that wolfSSL LIbrary allocates will be on the stack as local variables.
Reduce Your Code Size –enable-sha3=small –enable-aesgcm=small –enable-lowresource

CFLAGS=”-DNO_ERROR_STRINGS -DNO_INLINE -DCURVED25519_SMALL -DUSE_SLOW_SHA” -DUSE_SLOW_SHA256 -DUSE_SLOW_SHA612”

This will come at a cost of algorithm speed and memory usage.
Make a Really Small PSK-Only wolfSSL Library –enable-leanpsk PSK stands for pre-shared key. Approximate build size for wolfSSL on an embedded system with this enabled is 21kB.
Make a Really Small Client-Only wolfSSL Library –enable-leantls This produces a small footprint TLS client that supports TLS 1.2 client only, ECC256, AES128 and SHA256.
Use Only wolfCrypt –enable-cryptonly This enables a wolfCrypt-only build, greatly reducing the size. No TLS, no SSL.
Figure Out What is Going on Under the Hood –enable-debug This will build the wolfSSL Library with debug symbols so you can use your debugger to step through the code as it executes.  Also, if you call wolfSSL_Debugging_ON() lots of debugging messages will be printed to stderr.

 

Note that some of these flags can be combined while others are mutually exclusive. Please feel free to experiment with different combinations.

Want more? You can see a full list of our configuration flags by downloading our latest release and executing the following command:  ./configure –help

Still hungry? You can get detailed documentation about our configuration flags from “Chapter 2: Building wolfSSL” in the wolfSSL  Manual which can be found here: https://www.wolfssl.com/documentation/wolfSSL-Manual.pdf.  Need some expert advice? You can get in touch with your sales representative or email us at facts@wolfssl.com to start a consulting session with the expert engineers on the wolfSSL Inc. team.

wolfSSL provider support for PKCS11

We now support wolfCrypt as a PKCS11 provider for applications to consume. The new wolfPKCS11 library adds a PKCS11 layer on top of the wolfCrypt API’s to enable customers who wish to standardize on an API interface or may already have developed code against PKCS #11.

PKCS #11 is an OASIS standard for “Cryptographic Token Interface Base Specification” (A.K.A Cryptoki). It defines an API interface for communicating with Hardware Security Modules (HSM) to provide cryptography support such as RSA and ECC. It allows enumeration of devices and features using a shared or static library.

A good introduction to PKCS #11 can be found here: 

http://wiki.ncryptoki.com/introduction-to-pkcs-11-specifications.ashx

The source code is in a new GitHub repository here:

https://github.com/wolfSSL/wolfPKCS11

For questions please email facts@wolfssl.com

wolfCLU ‘ca’ Command Added

wolfCLU (wolfSSL command line utility) has seen many feature additions! One of the features added was support for the command ‘ca’. This command now can handle basic conf. files for use with signing certificates. It is useful in projects to make a quick certificate with a given CA while avoiding having to write the code and create an application. This feature was one of many that has recently been added. Check out the repository here for the current bleeding edge of wolfCLU (https://github.com/wolfSSL/wolfclu).

For questions about wolfCLU contact us at facts@wolfssl.com

wolfBoot 1.10 – Secure Bootloader with Unique Features

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!

Upcoming Webinar: Looking Under The Hood – wolfSSL Automotive Security

wolfSSL is holding an upcoming webinar on February 24th, 2022!  Join us for a comprehensive presentation on how to leverage wolfSSL for all of your automotive security needs. Out expert engineers will go through a variety of different use cases, stories, and examples, each with specific engineering details. Bring your questions for the Q&A session to follow!

When: Feb 24, 2022 10:00 AM Pacific Time (US and Canada)
Topic: Looking Under the Hood – Everything you need to know about automotive security that you’re too afraid to ask: wolfSSL Automotive Stories and Examples!

Register in advance for this webinar:
https://us02web.zoom.us/webinar/register/WN_xHQZNb6ARD-33EklTaWVbw

After registering, you will receive a confirmation email containing information about joining the webinar. We look forward to seeing you there!

Questions? Please contact us at facts@wolfssl.com.

What are the Advantages of wolfTPM?

At wolfSSL, we have been developing a TPM stack with customers for many years called wolfTPM, a portable, open-source TPM stack with backward API compatibility, designed for embedded use. It is highly portable, and has native support for Linux and Windows. RTOS and bare metal environments can take advantage of a single IO callback for SPI hardware interface, no external dependencies, and compact code size with low resource usage.

wolfTPM offers API wrappers to help with complex TPM operations like attestation and examples to help with complex cryptographic processes like the generation of Certificate Signing Request (CSR) using a TPM.

Due to wolfTPM’s portability, it is generally very easy to compile on new platforms.

Here are a few reasons to use wolfTPM over other secure elements:

1) It is based on a widely accepted standard TCG TPM 2.0.

2) There are many chip vendors options and they are pin compatible.

3) Support for RSA. All TPM’s support at least RSA 2048 (the STSAFE and ATECC do not).

4) More NV storage

5) Measured Boot (PCR’s)

6) Advanced Policy management

7) Seal/unseal data based on private key or PCR state.

Contact us at facts@wolfssl.com with any TPM, crypto questions!

Love it? Star wolfSSL on GitHub.

FIPS 140-3 and the TLS KDF

There has been a little turmoil between the CAVP and the FIPS community regarding the TLS KDF. The CAVP deprecated testing of the kdf-component-tls-1.0 at the beginning of the year. The community wasn’t ready and it was temporarily un-deprecated. wolfSSL and our wolfCrypt cryptography library are ready for the transition to the RFC7627 TLS KDF.

The kdf-component-tls-1.0 KDF is the standard TLSv1.2 KDF described in RFC5246. The preferred algorithm is the KDF described in RFC7627, also know as Extended Master Secret. This uses the TLSv1.2 KDF and replaces the client and master random values with hashes of the handshake messages up to the key exchange. This cryptographically ties the TLS master secret to the handshake. wolfSSL has enabled Extended Master Secret as a default since 2016.

If you want an up to date cryptography library and TLS stack that is ready for FIPS 140-3, send a message to fips@wolfssl.com for more information. 

 

wolfCrypt as an Engine for OpenSSL

As many people know, the OpenSSL project is struggling with FIPS. As of October 2020, OpenSSL has no active FIPS 140 validation. OpenSSL had plans to restore it’s FIPS validation with OpenSSL 3.0, however, they ran into significant delays, and since FIPS 140-2 testing ends September 2021, OpenSSL ultimately decided to focus their efforts on FIPS 140-3.

This means that OpenSSL users will not have a supported FIPS package for the indefinite future. This is a big issue for companies that rely on security. 

To fill this breach, wolfSSL has integrated our FIPS-certified crypto module (wolfCrypt) with OpenSSL as an OpenSSL engine. This means that:

  1. OpenSSL users can get a supported FIPS solution, with packages available up to the 24×7 level,
  2. The new wolfCrypt FIPS solution supports algorithms used in TLS 1.3, meaning your OpenSSL-based project can support TLS 1.3,
  3. You can support hardware encryption with your project, as the new wolfCrypt solution has full hardware encryption support, as provided by native wolfCrypt!

Additionally, should you be using one of the OpenSSL derivatives like BoringSSL, we can also support you.

wolfEngine is structured as a separate standalone library which links against wolfSSL (libwolfssl) and OpenSSL.  wolfEngine implements and exposes an OpenSSL engine implementation which wraps the wolfCrypt native API internally.  Algorithm support matches that as listed on the wolfCrypt FIPS 140-2 certificate #3389.

wolfEngine is compiled by default as a shared library called libwolfengine which can be dynamically registered at runtime by an application or by OpenSSL itself through a config file.  wolfEngine also provides an entry point for applications to load the engine when compiled in a static build.

wolfEngine has been tested on Linux with OpenSSL 1.0.2h and 1.1.1b inside OpenSSL apps (s_client, s_server, etc) and several popular Open Source packages – including cURL, stunnel, nginx, OpenLDAP, and OpenSSH!

 

Contact us at facts@wolfssl.com if you would like to learn more, or would like to use wolfEngine with other OpenSSL versions or Open Source projects!

Love it? Star wolfSSL on GitHub.

Top Ten Things you should know about Secure Boot

At wolfSSL, we have been developing secure boot solutions with customers for many years, and more recently we have released wolfBoot, 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 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.”

  1. 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.

  1. 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!

  1. 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.

  1. 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.

  1. 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.

  1. 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.

  1. 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).

  1. 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.

  1. 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.

Contact us at facts@wolfssl.com with any SSL/TLS, crypto, or secure boot questions!

Deprecation of FIPS v1

Here at wolfSSL, we have been supporting your FIPS needs for several years now with our FIPS Ready, certificate #2425 and certificate #3389 source bundles.  This support is going to continue with the soon to be granted FIPS 140-3 certificate. With the new certificate coming soon, we thought this might be a good time to do a bit of house cleaning.

As certificate #2425 has been added to the NIST sunset list as of June 2021, we will be removing the FIPS v1 feature from wolfSSL.

Customers who still need this feature are encouraged to move to the upcoming FIPS 140-3 certificate if timelines permit.  However, if customers need a solution in the near term, they can move to certificate #3389 which sunsets in 2024.  Customers who will be impacted by the removal of this feature for any reason are encouraged to get in touch with their account representative or email us at .

Top 10 wolfSSL Library Configurations

Here at wolfSSL, we strive to support our customers’ needs for customization and finding the right trade-offs. The following table is a list of the top 10 things you can do with wolfSSL’s configuration flags.

Task Configure Flag(s) Details
Get Ready for Your First FIPS Customer –enable-fips=ready You will need to have a fips-ready bundle which is available as both an open source code bundle or under a proprietary license.
Become DO-178 Compliant –enable-sp-math We have taken ECC in sp_c32.c in the SP-Math Library through DO-178C certification.
Make Your Application Secure from Side-Channel Attacks –enable-sp-math –enable-sp-math-all

CFLAGS=”WOLFSSL_SP_CACHE_RESISTANT”

or

–enable-fastmath –enable-harden 

Our SP-Math Library is always timing resistant and runs private key operations in constant time.  Our Fast Math Library can be made timing resistant by enabling the hardened build.
Reduce Your Stack Usage –enable-smallstack and –enable-smallstackcache Allocating memory on the heap will be favored over the stack.
Reduce Your Heap Usage –enable-static-memory All memory that wolfSSL LIbrary allocates will be on the stack as local variables.
Reduce Your Code Size –enable-sha3=small –enable-aesgcm=small –enable-lowresource

CFLAGS=”-DNO_ERROR_STRINGS -DNO_INLINE -DCURVED25519_SMALL -DUSE_SLOW_SHA” -DUSE_SLOW_SHA256 -DUSE_SLOW_SHA612”

This will come at a cost of algorithm speed and memory usage.
Make a Really Small PSK-Only wolfSSL Library –enable-leanpsk PSK stands for pre-shared key. Approximate build size for wolfSSL on an embedded system with this enabled is 21kB.
Make a Really Small Client-Only wolfSSL Library –enable-leantls This produces a small footprint TLS client that supports TLS 1.2 client only, ECC256, AES128 and SHA256.
Use Only wolfCrypt –enable-cryptonly This enables a wolfCrypt-only build, greatly reducing the size. No TLS, no SSL.
Figure Out What is Going on Under the Hood –enable-debug This will build the wolfSSL Library with debug symbols so you can use your debugger to step through the code as it executes.  Also, if you call wolfSSL_Debugging_ON() lots of debugging messages will be printed to stderr.

 

Note that some of these flags can be combined while others are mutually exclusive. Please feel free to experiment with different combinations.

Want more? You can see a full list of our configuration flags by downloading our latest release and executing the following command:  ./configure –help

Still hungry? You can get detailed documentation about our configuration flags from “Chapter 2: Building wolfSSL” in the wolfSSL  Manual which can be found here: https://www.wolfssl.com/documentation/wolfSSL-Manual.pdf.  Need some expert advice? You can get in touch with your sales representative or email us at facts@wolfssl.com to start a consulting session with the expert engineers on the wolfSSL Inc. team.

wolfSSL provider support for PKCS11

We now support wolfCrypt as a PKCS11 provider for applications to consume. The new wolfPKCS11 library adds a PKCS11 layer on top of the wolfCrypt API’s to enable customers who wish to standardize on an API interface or may already have developed code against PKCS #11.

PKCS #11 is an OASIS standard for “Cryptographic Token Interface Base Specification” (A.K.A Cryptoki). It defines an API interface for communicating with Hardware Security Modules (HSM) to provide cryptography support such as RSA and ECC. It allows enumeration of devices and features using a shared or static library.

A good introduction to PKCS #11 can be found here: 

http://wiki.ncryptoki.com/introduction-to-pkcs-11-specifications.ashx

The source code is in a new GitHub repository here:

https://github.com/wolfSSL/wolfPKCS11

For questions please email facts@wolfssl.com

wolfCLU ‘ca’ Command Added

wolfCLU (wolfSSL command line utility) has seen many feature additions! One of the features added was support for the command ‘ca’. This command now can handle basic conf. files for use with signing certificates. It is useful in projects to make a quick certificate with a given CA while avoiding having to write the code and create an application. This feature was one of many that has recently been added. Check out the repository here for the current bleeding edge of wolfCLU (https://github.com/wolfSSL/wolfclu).

For questions about wolfCLU contact us at facts@wolfssl.com

wolfBoot 1.10 – Secure Bootloader with Unique Features

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!

Upcoming Webinar: Looking Under The Hood – wolfSSL Automotive Security

wolfSSL is holding an upcoming webinar on February 24th, 2022!  Join us for a comprehensive presentation on how to leverage wolfSSL for all of your automotive security needs. Out expert engineers will go through a variety of different use cases, stories, and examples, each with specific engineering details. Bring your questions for the Q&A session to follow!

When: Feb 24, 2022 10:00 AM Pacific Time (US and Canada)
Topic: Looking Under the Hood – Everything you need to know about automotive security that you’re too afraid to ask: wolfSSL Automotive Stories and Examples!

Register in advance for this webinar:
https://us02web.zoom.us/webinar/register/WN_xHQZNb6ARD-33EklTaWVbw

After registering, you will receive a confirmation email containing information about joining the webinar. We look forward to seeing you there!

Questions? Please contact us at facts@wolfssl.com.

What are the Advantages of wolfTPM?

At wolfSSL, we have been developing a TPM stack with customers for many years called wolfTPM, a portable, open-source TPM stack with backward API compatibility, designed for embedded use. It is highly portable, and has native support for Linux and Windows. RTOS and bare metal environments can take advantage of a single IO callback for SPI hardware interface, no external dependencies, and compact code size with low resource usage.

wolfTPM offers API wrappers to help with complex TPM operations like attestation and examples to help with complex cryptographic processes like the generation of Certificate Signing Request (CSR) using a TPM.

Due to wolfTPM’s portability, it is generally very easy to compile on new platforms.

Here are a few reasons to use wolfTPM over other secure elements:

1) It is based on a widely accepted standard TCG TPM 2.0.

2) There are many chip vendors options and they are pin compatible.

3) Support for RSA. All TPM’s support at least RSA 2048 (the STSAFE and ATECC do not).

4) More NV storage

5) Measured Boot (PCR’s)

6) Advanced Policy management

7) Seal/unseal data based on private key or PCR state.

Contact us at facts@wolfssl.com with any TPM, crypto questions!

Love it? Star wolfSSL on GitHub.

FIPS 140-3 and the TLS KDF

There has been a little turmoil between the CAVP and the FIPS community regarding the TLS KDF. The CAVP deprecated testing of the kdf-component-tls-1.0 at the beginning of the year. The community wasn’t ready and it was temporarily un-deprecated. wolfSSL and our wolfCrypt cryptography library are ready for the transition to the RFC7627 TLS KDF.

The kdf-component-tls-1.0 KDF is the standard TLSv1.2 KDF described in RFC5246. The preferred algorithm is the KDF described in RFC7627, also know as Extended Master Secret. This uses the TLSv1.2 KDF and replaces the client and master random values with hashes of the handshake messages up to the key exchange. This cryptographically ties the TLS master secret to the handshake. wolfSSL has enabled Extended Master Secret as a default since 2016.

If you want an up to date cryptography library and TLS stack that is ready for FIPS 140-3, send a message to fips@wolfssl.com for more information. 

 

wolfCrypt as an Engine for OpenSSL

As many people know, the OpenSSL project is struggling with FIPS. As of October 2020, OpenSSL has no active FIPS 140 validation. OpenSSL had plans to restore it’s FIPS validation with OpenSSL 3.0, however, they ran into significant delays, and since FIPS 140-2 testing ends September 2021, OpenSSL ultimately decided to focus their efforts on FIPS 140-3.

This means that OpenSSL users will not have a supported FIPS package for the indefinite future. This is a big issue for companies that rely on security. 

To fill this breach, wolfSSL has integrated our FIPS-certified crypto module (wolfCrypt) with OpenSSL as an OpenSSL engine. This means that:

  1. OpenSSL users can get a supported FIPS solution, with packages available up to the 24×7 level,
  2. The new wolfCrypt FIPS solution supports algorithms used in TLS 1.3, meaning your OpenSSL-based project can support TLS 1.3,
  3. You can support hardware encryption with your project, as the new wolfCrypt solution has full hardware encryption support, as provided by native wolfCrypt!

Additionally, should you be using one of the OpenSSL derivatives like BoringSSL, we can also support you.

wolfEngine is structured as a separate standalone library which links against wolfSSL (libwolfssl) and OpenSSL.  wolfEngine implements and exposes an OpenSSL engine implementation which wraps the wolfCrypt native API internally.  Algorithm support matches that as listed on the wolfCrypt FIPS 140-2 certificate #3389.

wolfEngine is compiled by default as a shared library called libwolfengine which can be dynamically registered at runtime by an application or by OpenSSL itself through a config file.  wolfEngine also provides an entry point for applications to load the engine when compiled in a static build.

wolfEngine has been tested on Linux with OpenSSL 1.0.2h and 1.1.1b inside OpenSSL apps (s_client, s_server, etc) and several popular Open Source packages – including cURL, stunnel, nginx, OpenLDAP, and OpenSSH!

 

Contact us at facts@wolfssl.com if you would like to learn more, or would like to use wolfEngine with other OpenSSL versions or Open Source projects!

Love it? Star wolfSSL on GitHub.

Top Ten Things you should know about Secure Boot

At wolfSSL, we have been developing secure boot solutions with customers for many years, and more recently we have released wolfBoot, 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 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.”

  1. 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.

  1. 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!

  1. 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.

  1. 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.

  1. 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.

  1. 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.

  1. 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).

  1. 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.

  1. 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.

Contact us at facts@wolfssl.com with any SSL/TLS, crypto, or secure boot questions!

Posts navigation

1 2 3 4 5 6 7 8 9 150 151 152

Weekly updates

Archives

Latest Tweets