RECENT BLOG NEWS

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.

Watch the webinar here: FIPS Training Webinar

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.

Watch it 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

TLS provides end-to-end encryption on one connection. You are routing data in and out from one application. (Note, this application can be a tunneling utility, see Stunnel.) It authenticates the server with a certificate chain of trust going back to a root CA that you implicitly trust to sign identities. It can authenticate the client to the server the same way, or can keep the client anonymous. Many protocols used over TLS provide authentication, like putting up a webpage to sign in on for your bank.

SSH provides an end-to-end encryption for a collection of data channels on one connection. Each channel can be a shell, a pseudo-terminal, an application, port forwarding, etc. It is routing STDIN and STDOUT (and STDERR) over the channel for a command. (SFTP is just a command run in a channel over the connection. SCP is as well, but these days SCP is implemented in SFTP commands.) You may be connected to a shell and not realize you are running multiple channels over your connection. (You might have an ssh-agent channel over your connection. With the “-Y” option you’d have X11 forwarding in a channel or multiple channels.) It authenticates the server to the client by showing the human at the terminal a hash of the server’s key and asking them if they recognize it as being correct. (And we all just hit Y without looking. Ha ha. Just kidding.) The client user is authenticated (or not) by using a password, public key, or something else. (You can set up an SSH server to allow anonymous client access. A friend of mine did this on his text BBS; the connections were port forwarding to a telnet port where you’d then log in with a password.)

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

Download wolfSSL Now

We have notified the distros mailing list allowing the member distributions to prepare patches. (No one else gets details about these problems before October 11 without a support contract and a good reason.)

We are cutting the release cycle short and will release curl 8.4.0 on October 11, including fixes for a severity HIGH CVE and one severity LOW. The one rated HIGH is probably the worst curl security flaw in a long time.

The new version and details about the two CVEs will be published around 06:00 UTC on the release day.

• CVE-2023-38545: severity HIGH (affects both libcurl and the curl tool)
• CVE-2023-38546: severity LOW (affects libcurl only, not the tool)

There is no API nor ABI change in the coming curl release.

I cannot disclose any information about which version range that is affected, as that would help identify the problem (area) with a very high accuracy so I cannot do that ahead of time. The “last several years” of versions is as specific as I can get.

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

When it comes to edge computing devices, keeping secrets such as encryption keys or identifiable metadata from being tampered with or stolen is of the utmost importance and the TPM is an ideal facility for keeping such secrets.

WolfTPM already has facilities for storing secrets to the TPM, but we’ve recently added convenience functions for sealing secrets to the TPM using policy authorization tied to PCR values, wolfTPM2_SealWithAuthSig, wolfTPM2_SealWithAuthKey and wolfTPM2_UnsealWithAuthSig. These functions also have NV versions for keeping persistent secrets. wolfTPM2_SealWithAuthSig uses a premade signature to seal the secret instead of a signing key so that the signing key can be kept externally.

Sealing secrets using policy this way not only keeps the secret stored safely within the TPM, but also restricts internal access to the secret, requiring a valid signature of the policyDigest used to seal it and that the PCR value matches the value it had at the time of sealing. This means that an attacker would need the key used to seal the secret and would need to gain access to the system without modifying the PCR values, so tying the PCR values to things like expected log output or the firmware image would lock an attacker out of the secret if those elements were modified.

Try these new functions for yourself with wolfTPM, for examples on how to use these new policy sealing function check out https://github.com/wolfSSL/wolfTPM/tree/master/examples/seal and https://github.com/wolfSSL/wolfTPM/tree/master/examples/nvram.

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

Newly created container for wolfCLU (wolfSSL’s Command Line Utility) was added to wolfSSL’s repo: https://github.com/wolfSSL/wolfssl/tree/master/Docker/wolfCLU The idea is to be able to quickly get set up and start using the latest wolfCLU in your projects. You can get a prebuilt container from https://hub.docker.com/repository/docker/wolfssl/wolfclu/general or by simply running:

docker run -it –rm -v $(pwd):/ws -w /ws wolfssl/wolfclu

This command will run inside your current directory so you can create certificates or verify existing files using wolfCLU.

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

Download wolfSSL Now

Are you part of the Odette automotive networking platform community? Are you already using OFTP? Then we are here to help! As you might know, OFTP requires identity verification via specialized X.509 certificates issued by Odette, but the OFTP protocol depends on the underlying TLS protocol to handle the authentication, encryption and security aspects of the file transfer protocol. The overarching OFTP implementation is usually a separate library from the library that implements TLS. Have you considered using wolfSSL for your TLS and cryptography implementation?

Is your implementation of TLS out of date? Is it even maintained and supported? Do you know if it has any active CVEs against it? Do you need further certifications for your cryptographic implementations such as AUTOSAR? Come talk to us here at wolfSSL; we can help you get your software stack in order!

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

Download wolfSSL Now.

We are thrilled to announce that wolfSSL training webinar is returning on October 5th at 10 AM CET presented by wolfSSL Engineer Daniele. If you are wanting to dive into the insight of wolfSSL embedded SSL/ TLS and expand your knowledge, this is the perfect opportunity.

Watch the training today!
Part 1
Part 2

Daniele will cover topics including library design, the process of building and starting with wolfSSL. He will feature portability, customizability, certificates and keys, SSL debugging and troubleshooting, wolfSSL best practices, and in-depth insights into the wolfCrypt cryptography library.

It is your chance to gain a deep understanding of SSL/ TLS protocols and enhance your knowledge of wolfSSL embedded SSL/ TLS library. Don’t miss this opportunity to gain the crucial knowledge of SSL/ TLS and wolfSSL.

As always, our webinar includes 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

Do you have a post-quantum secure-boot requirement from the looming CNSA 2.0 timeline? The timeline has stated that post-quantum signature schemes should be used exclusively by 2030, and adoption should begin immediately. To this end, a few months ago we hinted that plans were underway for post-quantum wolfBoot support, and just recently we added post-quantum LMS/HSS signatures to wolfCrypt.

Building on this, we are excited to announce we have added support for LMS/HSS post-quantum signatures to wolfBoot. LMS wolfBoot support includes keygen, signing, verifying, and importing public keys generated from e.g. an HSM. In fact, to demonstrate HSM interoperability, we recently tested an LMS firmware signature verification integration with Crypto4A’s QxEdge HSM, and showed a live demo at ICMC 2023! If you’re curious, you can read more about our support in our recently added wolfBoot PQ docs, and LMS example config. It describes the LMS/HSS parameters we support from RFC 8554, and the performance tuning and space/time tradeoffs they enable.

LMS/HSS is an example of a post-quantum stateful hash-based signature (HBS) scheme. The security of these signature schemes is based simply on their underlying hash functions and Merkle trees, and does not rely on the assumed mathematical hardness of, for example, prime factorization. This feature gives stateful HBS schemes time tested, tried and true post-quantum security, which is why they have been recommended by NIST SP 800-208 and the NSA’s CNSA 2.0 suite.

An astute reader might notice that both LMS/HSS and XMSS/XMSS^MT were recommended in NIST SP 800-208 and the NSA’s CNSA 2.0 suite. Should we add XMSS/XMSS^MT to wolfBoot as well? Let us know what you think.

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

In our ongoing quest to bring the power and capabilities of wolfSSL products to all Espressif ESP32 developers, we are proud to announce two new upcoming Managed Components in the ESP Registry: wolfMQTT and wolfSSH.

Earlier this year we announced the core wolfSSL availability on the Managed Component Registry. Having wolfSSL as a Managed Component lets you get started in just a few minutes.

We know that many of you are excited to get started as soon as possible. To meet this demand we are announcing the availability of the experimental staging site for wolfSSL components:

https://components-staging.espressif.com/components?q=namespace%3Agojimmypi+wolfssl

First up is wolfMQTT. Getting started with wolfMQTT is easier than ever. Now you can get an example running in about 3 minutes. In fact, in this YouTube video [gojimmypi] demonstrates how with only a few commands in the ESP-IDF, you can get the AWS IoT MQTT example working on your own ESP32:

Here are the steps shown in the video:

#!/bin/bash

. ~/esp/esp-idf/export.sh

# Needed for Staging site:
export IDF_COMPONENT_REGISTRY_URL=https://components-staging.espressif.com

idf.py create-project-from-example "gojimmypi/mywolfmqtt^1.0.14-test:AWS_IoT_MQTT"

cd AWS_IoT_MQTT

idf.py -p /dev/ttyS9 -b 921600 flash monitor -b 115200

Note that this is using the components-staging site, and as such the IDF_COMPONENT_REGISTRY_URL setting is very important. Clear the value when using the production components link.

As you can see, for this example, only one command is needed to create the AWS IoT example application:

If you already have an existing project, that too is just a single command:

Stay tuned for the wolfSSH component to also be added. Soon these will all be available on the production ESP Registry site:

https://components.espressif.com/components?q=wolfssl

Be sure to watch the recording from the recent webinar:

Getting Started with wolfSSL on the Espressif ESP32.

See also some of the recent ESP32 blogs such as the RISC-V ESP32-C3, running Linux on the ESP32-S3 and others.
There’s also support for wolfSSL on Espressif and more Espressif resources.

Do you have any questions related to using wolfSSL in your next project? Contact us at facts@wolfSSL.com or call us at +1 425 245 8247 to learn more.

Download wolfSSL Now

Using wolfBoot as PKCS#11 secure supervisor

Today, we’re introducing an exciting feature from wolfBoot that makes use of TrustZone-M technology to enhance safe and monitored access to cryptographic operations. By exposing a complete set of standard cryptographic APIs to the application, wolfBoot provides controlled access to the wolfCrypt crypto engine running in the secure domain.

TrustZone-M and domain separation

TrustZone-M essentially creates a secure memory and IO domain within your microcontroller , where system supervision software can execute and provide controlled access to resources to its non-secure counterpart. The secure domain in TrustZone-M is similar to a controlled-access area where only trusted software can be executed. Software running in this domain is usually responsible for enforcing the separation of access permissions for all memory areas and peripherals. It may then optionally assume the role of a passive supervisor by providing special cross-domain API functions (non-secure callables), for a supervised and controlled access to specific functionality otherwise only available in the secure world. This hardware assisted feature is available on most microcontrollers in the ARMv8-M family.

Built-in, hardware assisted security module

Combining this feature with a cryptography engine running in secure mode is an ideal way to create a hardware-assisted separation for secrets and private keys from the application software. It is like having an advanced HSM that can perform crypto operations and store secrets in a security vault, where sensitive information is kept protected. This feature ensures that even if the rest of the system is compromised, the critical information stored in the vault remains secure based on hardware-enforced techniques.

Bootloader supervision

To ensure a trusted boot sequence, the requisite place to set up TrustZone-M, define the separation between the domains, and start the non-secure code execution is, of course, the bootloader. Older versions of wolfBoot were already capable of providing this type of isolation between the two domains, by using a tightly tailored wolfCrypt to verify the authenticity of the application code before staging into non-secure execution mode. We decided to further explore the potential of this integration by adding a fully-equipped wolfCrypt library to wolfBoot, running as a bootloader in the secure domain, and providing a standard way to access cryptographic functions and secure vault to the non-secure application.

The wolfCrypt library is embedded in the bootloader code, and can be used by both the applications/OS, through non-secure callable functions, as well as by wolfBoot itself for its everyday tasks of firmware authentication and integrity verification for securing the boot process.

Resources separation

The first important task to fulfill when preparing a system with TrustZone-M to run non-secure software is to set up and associate each memory segment and peripheral to either domain.
wolfBoot provides configuration options to delimit the areas in the internal flash memory of the microcontroller and separate its own non-volatile memory space from the one dedicated to running the application and receiving the updates in non-secure domain. The example configuration shown in the picture below demonstrates a possible way to divide the internal flash space. The initialization routines in wolfBoot ensure that such a segmentation is enforced through the TrustZone manager embedded in the chip. This configuration implies that the secure and non-secure flash space are logically mapped to different memory locations. A special section is reserved for non-secure callable objects exporting the API for applications to call exposed API functions from the secure domain.

Example flash memory segmentation in an embedded system using wolfBoot as TrustZone-M supervisor

RAM can also be separated by the global trustzone controller (GTZC) in the MCU. This is also enforced at runtime by the microcontroller once the zones have been set up by wolfBoot. The picture below shows an example separation between secure and non-secure RAM sections on a STM32L552 microcontroller, offering a total of 256KB of SRAM in two separate but contiguous banks. In this configuration, half of the total SRAM is dedicated to cryptographic and vault operations in the secure domain. Also in this case, once the GTZC is configured, the RAM is mapped into two separate virtual addresses, starting at 0x3000 0000 and 0x2000 0000 for secure and non-secure domain access, respectively.

Example segmentation of RAM in an embedded system using wolfBoot as TrustZone-M supervisor

PKCS#11

What has been described so far is the infrastructure that wolfBoot is capable of supporting when running on microcontrollers supporting TrustZone-M. All we need at this point is a valid API to access the cryptographic resources offered by wolfBoot running as a TrustZone-M supervisor.

Introduced by RSA laboratories in 2004, PKCS#11 sets the path for vendor-neutral cryptographic token interface (CTI). The standard consists of a well-defined and widely accepted API for the interaction between software and hardware components accessing cryptographic functionality. The use of PKCS#11 for interactions among components in a security infrastructure simplifies the development process, as engineers can rely on standardized interfaces, ultimately reducing development time and risk.

wolfSSL products already support both endpoints for PKCS#11 interoperability. wolfCrypt can be compiled on any platform with built-in support to access a PKCS#11 engine, using the compile time flag –enable-pkcs11, or the equivalent preprocessor definition HAVE_PKCS11. The other side of the communication is provided via a separate library, wolfPKCS11. This module provides the implementation of the API using wolfCrypt as its crypto engine.

When wolfBoot is installed as TrustZone-M secure supervisor, it integrates wolfPKCS11 in its secure domain executable code, which can be accessed by any application in the non-secure domain by calling the corresponding NSC wrappers.

Securing the embedded system architecture

Thanks to the separation between the domains and the integration of a PKCS#11 engine in the secure world, applications can not directly access sensitive cryptographic information such as private keys any more, and rely on the crypto engine under the hood to use these keys when needed. For example, a TLS connection may require the endpoint running on the microcontroller to authenticate itself using a public key mechanism. The private key to generate the signature can be pre-provisioned in the secure vault and used by the TLS to confirm the identity of its local endpoint. Applications already using wolfCrypt APIs to secure data at rest don’t need any adaptations to fit in this new model, because wolfCrypt calls will be translated internally through the wolfCrypt PKCS#11 connector in the non-secure area before calling the actual algorithm implementation in the secure domain, through the NSC API. Finally, any third party application or RTOS integrating a generic PKCS#11 connector can be linked to the NSC API layer and start using the secure, supervised crypto engine right away.
By default all the cryptography functions are implemented in software by wolfCrypt. However, wolfCrypt is very versatile and can make use of hardware security modules or external secure components. This makes this design extendable when more hardware components are in the picture. Compliant usage of some of the functions in wolfCrypt requires a good quality entropy source, which is why we also introduced a secure-world driver for the TRNG of the microcontroller to feed wolfCrypt PRNGs.

Software architecture of an embedded system using wolfBoot as TrustZone-M supervisor. Applications access wolfCrypt in secure world through the PKCS#11 NSC interface

Common use cases

There may be several reasons for a system architect to consider the adoption of wolfBoot as TrustZone-M supervisor in their projects. Some projects rely on two different layers of distribution for the software that eventually runs on target. The owner of the system, who controls the execution of secure and non-secure software on board, may decide to export a SDK to allow customization of the applications. Applications running in the non-secure domain can be mistrusted and sandboxed thanks to the flexibility of the wolfBoot interface to exclude memory sections and peripherals from the non-secure world visibility. In other cases, designers may just be searching for a stable, certified, rock-solid security engine for diverse applications, to facilitate monitoring, updating and managing vulnerabilities through a centralized point. Other scenarios may be simply looking for strong separation of key management, enforced provisioning and avoiding direct interaction between non-secure software and sensitive information, achieved thanks to the policies in place in PKCS#11 for accessing the same tokens with different capabilities and permission masks.

Example on Cortex-M33

As usual, wolfBoot is distributed with example applications to demonstrate the features through real-life porting for evaluation boards for the relevant CPU or microcontrollers in play. For this development, we focused on the STM32L552-Nucleo (Nucleo-L552ZE-Q) board, where all the features needed are accurately documented, which resulted in a smooth integration. A command line tool provided by STMicroelectronics allows users to check and modify the non-volatile registers containing the options for activating and using the TrustZone feature at hardware level. Once the option bytes are correctly configured on the board, wolfBoot can be built using the options WOLFCRYPT_TZ=1 and WOLFCRYPT_TZ_PKCS11=1 to enable wolfCrypt in TrustZone-M with its PKCS#11 interface. The test application that runs in this case initializes a token by creating a new ECC keypair and storing it in the vault. The application then uses the keypair to sign and verify a payload, checking the functionality through the validation of the signature obtained. The file docs/STM32-TZ.md included in wolfBoot provides detailed information on how to build and run the example on the target.

Further research

At wolfSSL we are committed to implement the best solutions for securing your embedded systems. The new wolfBoot feature introduced here is already being expanded to support more hardware platforms, also across different architectures providing hardware-assisted trusted execution environments. Cryptographic APIs between isolated domains can be customized and extended to integrate different interaction models. Moreover, we are looking for the best strategies to extend the wolfCrypt in trustZone-M support with post-quantum cryptography algorithms available in wolfCrypt.

Resources

wolfBoot is available in source code format. The features described in this post will be included in the upcoming version distributed through our download page (https://www.wolfssl.com/download/), and they are already available in the upstream version on our github repository (https://github.com/wolfssl/wolfboot).

If you want to receive more information on wolfBoot running in TrustZone, or if you want to chat with us about secure boot and trusted execution on embedded systems, please contact us at facts@wolfSSL.com or call us at +1 425 245 8247.

Download wolfSSL Now