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. wolfSSL also has a support-specific blog page dedicated to answering some of the more commonly received support questions.

wolfSSL 5.8.0 Released

We are excited to announce that wolfSSL version 5.8.0 is now available. This release brings several important new features and improvements. Below are the key new additions:

New Features

  • Implemented various fixes to support building for Open Watcom, including OS/2 support and Open Watcom 1.9 compatibility (PR 8505, 8484).
  • Added support for STM32H7S (tested on NUCLEO-H7S3L8) (PR 8488).
  • Added support for STM32WBA (PR 8550).
  • Added Extended Master Secret Generation Callback to the –enable-pkcallbacks build (PR 8303).
  • Implemented AES-CTS (–enable-aescts) in wolfCrypt (PR 8594).
  • Added support for libimobiledevice commit 860ffb (PR 8373).
  • Initial ASCON hash256 and AEAD128 support based on NIST SP 800-232 IPD (PR 8307).
  • Added blinding option when using a Curve25519 private key by defining the macro WOLFSSL_CURVE25519_BLINDING (PR 8392).

ML-DSA and Post-Quantum Cryptography Enhancements

In line with NIST’s latest documentation, wolfSSL has updated its Dilithium implementation to ML-DSA (Module-Lattice Digital Signature Algorithm), which is fully supported in this release. Additionally, the release includes updates to further optimize ML-DSA and LMS (Leighton–Micali Signature) schemes, reducing memory usage and improving performance.

Linux Kernel Module (linuxkm) Updates

wolfSSL 5.8.0 expands support for the Linux Kernel Module (linuxkm), with several important enhancements to improve kernel-level cryptographic integration. This includes extended LKCAPI registration support for rfc4106(gcm(aes)), ctr(aes), ofb(aes), ecb(aes), and the legacy one-shot AES-GCM backend. Compatibility improvements have been added for newer kernels (?6.8), and calls to scatterwalk_map() and scatterwalk_unmap() have been updated for Linux 6.15. The release also registers ECDSA, ECDH, and RSA algorithms with the kernel crypto API and introduces safeguards for key handling, including forced zeroing of shared secrets. These changes make it possible to use more wolfSSL functionality in the kernel space.

For a full list of fixes and optimizations check out the ChangeLog.md bundled with wolfSSL. Download the latest release from the download page. 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

Securing UEFI with wolfSSL’s FIPS 140-3 Cryptography

One of the biggest strengths of the wolfSSL portfolio is its ability to adapt and run in the most diverse environments, whether it’s a minimal bare-metal deployment or a complex, multi-layered operating system.

This blog highlights recent improvements in the wolfSSL products regarding integration with the Unified Extensible Firmware Interface (UEFI)—the modern way to interface with hardware firmware during the initial steps after booting a machine (UEFI has replaced the legacy BIOS).

wolfSSL can already enhance UEFI firmware with component authentication and secure updates, as wolfBoot—our secure boot solution—can run as a UEFI application inside UEFI environments (Check out the build instruction).

Recently, wolfSSL has made it even simpler for other UEFI applications to access wolfSSL cryptographic services (using wolfCrypt). wolfSSL has improved its use of UEFI features, leveraging TRNG and crypto accelerators exposed by UEFI.

UEFI applications can now consume a FIPS 140-3 certified range of wolfSSL cryptographic algorithms (AES, RSA, DSA, ECDSA, SHA), key derivation functions, and secure communication protocols (D)TLS up to v1.3.

As a leader in embedded FIPS certificates, wolfSSL can assist you in the certifying of your UEFI based operating environments (OE’s) and assists you in the ACVP (Automated Cryptographic Validation Protocol).

The use cases are many: OS-agnostic secure communication, TPM attestation, disk encryption, and more.

If you are interested in using wolfSSL cryptography, wolfSSL TLS communication, any wolfSSL product inside a UEFI environment, or have questions about any of the above, please contact us at facts@wolfSSL.com or call us at +1 425 245 8247.

Download wolfSSL Now

wolfSSL Java JSSE Provider Supports DTLS 1.3

wolfSSL’s Java JSSE provider (wolfJSSE) now supports DTLS 1.3! This support includes DTLS 1.3 on both client and server side through the SSLEngine interface. This support can be found in the wolfssljni GitHub master branch, and will be included in the next stable release.

Benefits of DTLS 1.3

DTLS 1.3 (see RFC 9147) brings improved security and performance over DTLS 1.2, including:

  • Reduced handshake latency (fewer round trips)
  • Enhanced privacy (encrypted handshake messages)
  • Improved resilience against network attacks
  • Modern cryptographic algorithms

Getting Started

wolfJSSE can be built on a number of platforms, including Unix/Linux, macOS, Windows, and Android. See the wolfSSL JNI/JSSE Manual for instructions on building the library.

Example Applications

wolfJSSE includes sample DTLS 1.3 client and server applications which can be used as a reference and to try out Java DTLS 1.3 functionality. To compile the examples run:

ant examples

The example client is located in “./examples/provider/DtlsClientEngine.java” and the server is located in “./examples/provider/DtlsServerEngine.java”. Each can be run from the root “wolfssljni” directory using the wrapper scripts that share the same name. Example output should be similar to:

./examples/provider/DtlsServerEngine.sh

DTLS 1.3 Server listening on port 11113
DTLS 1.3 Server Engine created
Waiting for client connection...
Client connected from /127.0.0.1:58703
DEBUG: Sent packet with 176 bytes
DEBUG: Received packet with 383 bytes
DEBUG: Sent packet with 176 bytes
DEBUG: Sent packet with 36 bytes
DEBUG: Sent packet with 69 bytes
DEBUG: Sent packet with 721 bytes
DEBUG: Sent packet with 109 bytes
DEBUG: Sent packet with 66 bytes
DEBUG: Received packet with 908 bytes
DEBUG: Received packet with 110 bytes
DEBUG: Received packet with 66 bytes
DEBUG: Sent packet with 72 bytes
DEBUG: Sent packet with 255 bytes
DTLS handshake completed successfully
Pausing briefly before processing application data...
DEBUG: Received packet with 40 bytes
DEBUG: Received packet with 49 bytes
Received from client: Hello from DTLS 1.3 Client!
Echoing message back to client
DEBUG: Sent packet with 49 bytes
Closing connection...
Connection closed

./examples/provider/DtlsClientEngine.sh
Client socket created, connecting to localhost:11113
DTLS 1.3 Client Engine created
Starting DTLS handshake...
DEBUG: Sent packet with 310 bytes to localhost/127.0.0.1:11113
DEBUG: Received packet with 176 bytes from /127.0.0.1:11113
DEBUG: Sent packet with 383 bytes to localhost/127.0.0.1:11113
DEBUG: Received packet with 176 bytes from /127.0.0.1:11113
DEBUG: Received packet with 36 bytes from /127.0.0.1:11113
DEBUG: Received packet with 69 bytes from /127.0.0.1:11113
DEBUG: Received packet with 721 bytes from /127.0.0.1:11113
DEBUG: Received packet with 109 bytes from /127.0.0.1:11113
DEBUG: Received packet with 66 bytes from /127.0.0.1:11113
DEBUG: Sent packet with 908 bytes to localhost/127.0.0.1:11113
DEBUG: Sent packet with 110 bytes to localhost/127.0.0.1:11113
DEBUG: Sent packet with 66 bytes to localhost/127.0.0.1:11113
DEBUG: Received packet with 72 bytes from /127.0.0.1:11113
DTLS handshake completed successfully
Processing post-handshake session tickets...
Received post-handshake packet of 255 bytes, processing...
Processed post-handshake packet: OK, consumed: 255, produced: 0
Pausing briefly before sending data...
Pausing after handshake to allow connection to stabilize...
Sending application data: Hello from DTLS 1.3 Client!
DEBUG: Sent packet with 40 bytes to localhost/127.0.0.1:11113
DEBUG: Sent packet with 49 bytes to localhost/127.0.0.1:11113
Waiting for server response (allowing time for processing)...
Now attempting to receive server response...
Waiting for application data packet from server...
Received packet of 49 bytes
Raw bytes: 2F DA 82 00 2C DB B7 A5 0D 19 31 20 68 A2 0C 1C 91 75 F6 65 ...
Unwrap result: OK, consumed: 49, produced: 27
Successfully decrypted data: Hello from DTLS 1.3 Client!
Closing connection...
Connection closed

If you have questions about using DTLS 1.3 from your Java application, please contact us at facts@wolfSSL.com or call us at +1 425 245 8247.

Download wolfSSL Now

Xilinx vs STM: wolfSSL Integration and Build Experience Compared

Selecting the right hardware for an embedded project can be a complex decision—but choosing a security library doesn’t have to be. wolfSSL offers broad platform support, running seamlessly on everything from bare-metal systems to full-featured operating systems. In this post, we’ll compare how wolfSSL integrates with two widely used embedded platforms: Xilinx and STM. While both are popular choices, they offer distinct differences in architecture, development tools, and integration workflows.

Platform High Level Overview

Xilinx

  • Primarily FPGA-based (Zynq, Zynq Ultrascale+, Versal)
  • Offers ARM Cortex-A cores alongside programmable logic
  • Development environment: Xilinx Vitis / Petalinux
  • OS: Often uses Linux (Yocto or Petalinux), FreeRTOS or bare-metal

STM (STMicroelectronics)

  • Microcontroller-focused (e.g., STM32 family)
  • Most are based on ARM Cortex-M cores, with some series using Cortex-A cores
  • Development environment: STM32CubeIDE, Makefiles, or bare-metal toolchains
  • OS: Often bare-metal or FreeRTOS

wolfSSL Build Process

Xilinx

  • Autotools or CMake to build wolfSSL in userspace
  • Cross-compilation with Petalinux SDK or Vitis toolchain
  • Hardware acceleration via Xilinx’s crypto engine, ARM assembly optimizations or custom logic in the PL with crypto callbacks

STM (STMicroelectronics)

  • Predefined example configuration files in wolfSSL/IDE/STM32Cube
  • Integration with STM32CubeMX-generated projects
  • Support for HAL/LL drivers, and FreeRTOS (if applicable)

Cryptographic Acceleration

Xilinx

  • Advanced FPGAs allow for hardware acceleration of cryptographic primitives
  • Can use custom IP cores or external crypto accelerators
  • wolfSSL’s ARM assembly optimizations
  • Potential for extreme performance gains, but at the cost of complexity

STM (STMicroelectronics)

  • Some STM32 parts support hardware ECC, AES, SHA, and RNG
  • wolfSSL can use these via direct calls to HAL drivers
  • Easier to configure and use but offers less flexibility compared to FPGAs and on average has a less powerful CPU
  • wolfSSL’s ARM assembly optimizations

Some Use Cases We See

  • Xilinx if:
    • You need programmable logic and customizable crypto acceleration
    • Your application runs Linux and demands high throughput
    • You have a complex security architecture
  • STM if:
    • You want quick integration for a bare-metal or FreeRTOS-based project
    • Your focus is low power and minimal footprint
    • You need an edge microcontroller

Both Xilinx and STM platforms are well-supported by wolfSSL, but the experience differs significantly. Xilinx generally offers power and flexibility—ideal for high-performance secure systems—while STM excels in simplicity and efficiency, making it perfect for lightweight, resource-constrained designs.

Whether you’re targeting a Linux-based Zynq application or a real-time STM32 sensor node, wolfSSL provides the building blocks you need to implement robust embedded security.

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

Download wolfSSL Now

Secure Your Oracle Linux 8 Deployment with wolfSSL’s FIPS 140-3 Validated Module

If you’re stuck on OL8 for some reason, have no desire to migrate to OL9 or later, and still need FIPS support for OpenSSL 1.x, then we can help with our FIPS 140-3 module, which plugs into the OpenSSL 1.x engine interface.

If you have questions about FIPS, please reach out to us at fips@wolfssl.com. For any other inquiries, contact us at facts@wolfssl.com or call us at +1 425 245 8247.

Download wolfSSL Now

Live webinar: Open Source Secure Boot Meets Open Hardware: wolfBoot Integration with TROPIC01 Secure Element

Join us for an exciting webinar showcasing the integration of the TROPIC01 secure element with wolfBoot, bringing open source secure boot down to the hardware level.

Register Now: Open Source Secure Boot Meets Open Hardware: wolfBoot Integration with TROPIC01 Secure Element
Date: June 25th | 9 AM PT

The Tropic Square team has integrated support for the TROPIC01 secure element into wolfBoot, using it as a hardware Root-of-Trust for the secure boot process. This integration is a milestone because it extends wolfBoot’s open source transparency right down to the hardware, enabling users and security researchers to audit the entire security chain—from software to hardware.

This approach aligns with Kerckhoff’s principle, which states that a cryptosystem should remain secure even if everything about it, except the secret key, is publicly known. By opening the design and implementation, users don’t have to blindly trust that the secure element is free from vulnerabilities or backdoors.

This webinar will cover:

  • An overview of the TROPIC01 open architecture secure element and wolfBoot
  • A demo of TROPIC01 integrated into the secure boot process
  • Why “security by obscurity” fails—and how Tropic Square and wolfSSL deliver transparent, Open Source security that builds trust

Register now to learn how to build transparent, auditable, open source secure boot solutions from silicon to software.

As always, our webinar will include Q&A 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

wolfTPM Support for Das U-Boot

wolfTPM now includes support for Das U-Boot, extending TPM 2.0 access to early boot stages in secure embedded systems. This port enables direct TPM communication in U-Boot environments using software SPI and provides both native and high-level APIs for flexibility.

Key Features

  • SOFT SPI Driver
  • Full TPM 2.0 command set
  • Both native API and wrapper APIs for complex TPM operations
  • Two integration paths:
    • __linux__: Uses tpm2_linux.c to communicate via standard Linux TPM interfaces
    • __UBOOT__: Direct SPI communication via tpm_io_uboot.c

U-Boot TPM Commands

The wolftpm command interface in U-Boot offers a rich set of TPM 2.0 operations. including:

  • Basic TPM control: init, startup, self_test, info
  • PCR management: pcr_extend, pcr_read, pcr_allocate, pcr_print
  • Security features: clear, change_auth, dam_reset, dam_parameters
  • Firmware management: firmware_update, firmware_cancel
  • Capability reporting: caps, get_capability

These commands allow developers to initialize, configure, and query TPM state from within U-Boot, enabling security features even before the OS loads.

Extended Functionality

While U-Boot includes basic TPM 2.0 command support through its native library, wolfTPM extends this functionality with the ability to manage firmware updates.

Firmware Management Support

wolfTPM includes dedicated commands for managing TPM firmware, allowing users to directly perform updates and control firmware behavior from the U-Boot shell:

  • firmware_update <manifest_addr> <manifest_sz> <firmware_addr> <firmware_sz>
    Performs a full firmware update on the TPM by providing a signed manifest and firmware image.</styel=”font-family:courier>
  • firmware_cancel
    Allows users to cancel or abandon an ongoing firmware update process. 

These capabilities are not present in U-Boot’s built-in TPM stack, which lacks any mechanism for managing TPM firmware or triggering a reboot of the TPM device. With wolfTPM, developers gain direct control over the TPM lifecycle, supporting scenarios like:

  • Field upgrades of TPM firmware
  • Factory provisioning with verified firmware images
  • TPM resets and recovery via startup/shutdown sequences

By leveraging wolfTPM in U-Boot, embedded developers and security teams can take full advantage of the TPM 2.0 specification—including lifecycle and provisioning flows that go beyond what standard U-Boot TPM implementations provide.

Getting Started

For detailed build instructions, configuration options, and sample usage:

Conclusion

wolfTPM’s U-Boot support is ideal for securing early boot environments with TPM 2.0 features. With a rich command-line interface, flexible APIs, and tested support for QEMU and swtpm, it’s a robust solution for TPM integration in embedded platforms.

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

wolfTPM Support for Zephyr RTOS

wolfSSL now has support for Zephyr RTOS through a newly added wolfTPM Zephyr port. This enables easy integration of TPM 2.0 functionality in embedded projects using Zephyr, expanding the flexibility and portability of secure applications.

Below is a summary of the key features introduced in the PR#395:

Key Changes and Features

Zephyr Module Integration

wolfTPM has been added as a Zephyr module, complete with CMake and Kconfig support. This makes it simple to include TPM functionality in any Zephyr-based project using standard module inclusion through west.

Sample Applications

Two test/sample applications are included in the port:

  • wolftpm_wrap_test – tests core TPM wrapper functionality
  • wolftpm_wrap_caps – displays TPM capabilities

Both examples build and run successfully on qemu_x86, providing developers with a solid foundation to build on.

Custom Configuration Support

The module uses a user_settings.h configuration file, which can be customized or replaced as needed by developers to match project-specific requirements.

CI Integration

A new zephyr.yml GitHub CI workflow has been added to automatically build and verify the wolfTPM Zephyr samples, ensuring continued build stability and integration with upstream Zephyr changes.

Device Tree Integration

Communicating with your TPM in zephyr is as simple as setting WOLFTPM_ZEPHYR_I2C_BUS in user_settings.h to the node describing the i2c bus on your device. You can also set the speed of the i2c line with WOLFTPM_ZEPHYR_I2C_SPEED.

Getting Started

To learn more about using wolfTPM with Zephyr and how to set it up in your project, see:

Conclusion

wolfTPM now supports Zephyr RTOS, enabling robust TPM 2.0 integration in lightweight embedded systems. With CI coverage, modular design, and working samples, developers can confidently build secure applications using wolfTPM on Zephyr.

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

FIPS 140-3 Compliance for GnuTLS

We’re excited to announce the next phase in our wolfCrypt-GnuTLS integration: full FIPS 140-2 Level 2 compliance and FIPS 140-3 validation capabilities! This enhancement builds directly on our ongoing work to bring wolfCrypt’s powerful cryptographic capabilities to GnuTLS.

Unlike traditional approaches that require extensive application rewrites, our solution continues to operate entirely behind the scenes. By patching GnuTLS at the library level, we’ve created a seamless path for applications to leverage wolfCrypt’s FIPS-certified cryptographic capabilities without changing a single line of application code.

What makes this integration particularly significant is GnuTLS’s central role in secure communications infrastructure. Our approach transforms what would typically be a massive certification challenge into a straightforward library update, allowing organizations to achieve FIPS compliance without disrupting their existing architecture.

For Linux distribution maintainers, this integration eliminates the traditional compromise between security and compatibility when deploying certified cryptography. Certificate validation and protocol handling will continue through the familiar GnuTLS interface while benefiting from wolfCrypt’s certified implementation underneath.

For teams working in regulated environments requiring FIPS certification, this integration offers a remarkable advantage: immediate access to wolfCrypt’s FIPS 140-3 validated algorithms without the typical development and certification marathon. Our goal is to help reduce the time needed for certification processes, enabling organizations to more efficiently deploy secure communications in regulated environments without compromising on compatibility or performance.

Take a more in-depth look here: https://github.com/wolfssl/gnutls-wolfssl

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

Open Source Secure Boot Meets Open Hardware: Announcing wolfBoot Integration with TROPIC01 Secure Element

We are excited to announce our new partnership with Tropic Square and the integration of wolfBoot with their TROPIC01 secure element. Tropic Square has developed an open architecture hardware secure element for applications, including IoT devices, crypto wallets, or any modern application that prioritizes security.

Unlike most hardware secure elements, the TROPIC01 solution is built with an open-architecture. The TROPIC01 implementation is auditable, allowing engineers to review the design to verify the security implementations and ensure there are no hidden features or backdoors.

The Tropic Square team has integrated wolfBoot with the TROPIC01 secure element, using the secure element as hardware Root-of-Trust for the secure boot process. The TROPIC01 chip provides:

  • Storage of ECC public keys for verification operation
  • Enabling secure provisioning of ECC (verification) keys
  • Enabling secure provisioning of AES (decryption) keys
  • Storing “associated” data (key values and other secrets)

What makes this integration particularly significant is that it extends the open nature of the wolfBoot solution down to the hardware level. This transparency allows users and security researchers to audit the security of the design and implementation of the solution. This approach follows Kerckhoff’s principle that a cryptosystem should be secure even if everything about it, except the secret key, is known to the attacker: As a result, users no longer have to blindly trust that the secure element is free from vulnerabilities or back doors.

The pull request adding TROPIC01 support can be found here: https://github.com/wolfSSL/wolfssl/pull/8812
The solution is available here: https://github.com/wolfssl/… or https://github.com/tropicsquare/

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

Live Webinar: How to get FIPS 140-3 for YOUR Linux Distro

If your product is built on Linux and targets government or regulated industries, FIPS 140-3 compliance is essential.

Join us for a webinar to learn how to bring your Linux-based system into compliance using wolfCrypt, the world’s first SP800-140Br1 FIPS 140-3 validated cryptographic module.

Register Now: How to get FIPS 140-3 for YOUR Linux Distro
Date: June 18th | 9 AM PT

wolfSSL Senior Software Engineer Anthony Hu will walk through real implementation paths, challenges, and solutions highlighted by a case study on IGEL, which is integrating wolfCrypt FIPS 140-3 validated crypto into its secure Linux-based endpoint OS.

This webinar will feature implementation stories and real-world application examples, including integration strategies for OpenSSL, NSS, Libgcrypt, gnuTLS, and the Linux Kernel.

What you’ll learn:

  • Why organizations are investing in FIPS 140-3 now
  • Who benefits most from a validated crypto module
  • How to integrate wolfCrypt into common crypto backends
  • A detailed case study of IGEL’s journey to FIPS 140-3 compliance

If your team is considering FIPS 140-3 or is already deep into Linux crypto architecture, this session is for you. We’ll help you cut through the confusion and give you a concrete path forward.

Register now to secure your spot!

As always, our webinar will include Q&A 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

Posts navigation

1 2 3 4 … 203 204 205

Weekly updates

Archives