Building Secure Embedded Systems: wolfSSL’s Comprehensive Yocto Support for FIPS-Certified Applications
Building FIPS-certified embedded systems just got easier. wolfSSL provides comprehensive Yocto Project support through the meta-wolfssl layer, enabling developers to integrate FIPS-validated cryptography into embedded Linux builds with reproducible, cross-platform consistency. Whether you’re developing medical devices, industrial controllers, defense systems, or IoT products, this combination delivers the security compliance regulators demand with the flexibility embedded developers need, and all in a lightweight package that’s up to 20 times smaller than alternatives.
In the world of embedded systems and IoT devices, security isn’t just a feature, it’s a fundamental requirement. For organizations building products that handle sensitive data or operate in regulated industries, FIPS (Federal Information Processing Standards) certification is often mandatory. But achieving FIPS certification while maintaining the flexibility and efficiency needed for modern embedded development can be challenging. This is where the combination of wolfSSL and the Yocto Project becomes a powerful solution.
Understanding the Challenge: Why Embedded Security Matters
Embedded systems are everywhere. They’re in medical devices monitoring patient health, industrial controllers managing critical infrastructure, automotive systems ensuring vehicle safety, and defense systems protecting national security. When these systems communicate over networks or store sensitive data, they need robust cryptographic protection. However, embedded devices face unique constraints that make security implementation challenging:
- Limited Resources: Many embedded devices have constrainedmemory, processing power, and storage capacity
- Long Lifecycles: Embedded products often remain in service for years or decades, requiring long-term security maintenance
- Regulatory Requirements: Industries like healthcare, finance, defense, and government require FIPS 140-2 or FIPS 140-3 validated cryptography
- Custom Hardware: Embedded systems run on diverse processor architectures and hardware platforms
- Build Complexity: Creating reproducible, maintainable builds across different hardware targets is essential
What is Yocto and Why Does It Matter?
The Yocto Project is an open-source collaboration that provides templates, tools, and methods to create custom Linux-based systems for embedded products, regardless of the hardware architecture. Think of it as a flexible framework that lets you build exactly the Linux distribution you need for your specific hardware and application requirements.
For companies developing FIPS-certified embedded systems, Yocto offers several critical advantages:
Reproducible Builds
FIPS certification requires demonstrating that the cryptographic module is built consistently and correctly. Yocto’s build system ensures that every build is reproducible, meaning you can recreate the exact same binary from the same source code and build configuration. This reproducibility is essential for maintaining FIPS validation across product lifecycles.
Cross-Platform Consistency
Whether you’re targeting ARM or x86, Yocto provides a consistent build environment. This means you can develop and test your FIPS-certified cryptography on one platform and deploy it confidently across multiple hardware targets.
Dependency Management
FIPS-certified cryptographic modules have specific dependencies and build requirements. Yocto’s recipe system manages these dependencies automatically, ensuring that all required libraries, tools, and configurations are present and correctly versioned.
Long-Term Maintenance
Embedded products often have support lifecycles measured in years or decades. Yocto’s layered architecture and version management make it possible to maintain and update systems over extended periods while preserving FIPS validation.
Integration with Existing Ecosystems
Many embedded developers already use Yocto or OpenEmbedded for their Linux-based products. Having FIPS-certified cryptography available as a Yocto recipe means it integrates seamlessly into existing development workflows without requiring major toolchain changes.
wolfSSL: Purpose-Built for Embedded FIPS Requirements
wolfSSL is a lightweight SSL/TLS library specifically designed for embedded and resource-constrained environments. Unlike general-purpose cryptographic libraries that were designed for servers and desktops, wolfSSL was built from the ground up with embedded systems in mind. The library typically requires only 20-100KB of memory, making it up to 20 times smaller than alternatives, while still providing comprehensive cryptographic functionality.
What makes wolfSSL particularly valuable for FIPS-certified applications is its proven track record of validation. The wolfCrypt cryptographic library that powers wolfSSL has achieved multiple FIPS certifications.
These certifications aren’t just checkboxes, they represent rigorous third-party testing and validation of the cryptographic implementations, key management, and security boundaries. For organizations in regulated industries, using a FIPS-validated cryptographic module is often a legal requirement, not just a best practice.
wolfSSL’s Comprehensive Yocto Integration
wolfSSL provides first-class support for Yocto through the meta-wolfssl layer, a dedicated OpenEmbedded/Yocto layer that makes integrating wolfSSL products into embedded Linux builds straightforward and maintainable.
The meta-wolfssl Layer
The meta-wolfssl repository (https://github.com/wolfssl/meta-wolfssl) is a complete Yocto layer that provides recipes for the entire wolfSSL product family:
- wolfSSL: The core SSL/TLS library with FIPS-validated cryptography
- wolfSSH: Lightweight SSH library for secure remote access
- wolfMQTT: MQTT client library for IoT messaging
- wolfTPM: Portable TPM 2.0 library for hardware security modules
- wolfCLU: Command-line utilities for cryptographic operations
- wolfPKCS11: PKCS#11 implementation for cryptographic token interfaces
The layer has been tested and verified across multiple Yocto releases, from older versions like Sumo (v2.5) and Zeus (v3.0) through current releases like Kirkstone (v4.0), Langdale (v4.1), Nanbield (v4.3), and Scarthgap (v5.0). This broad compatibility ensures that whether you’re maintaining legacy systems or developing new products, wolfSSL’s Yocto support will work with your chosen Yocto version.
Simple Integration Process
Adding wolfSSL to a Yocto build is straightforward. After cloning the meta-wolfssl repository, developers simply add the layer to their bblayers.conf configuration file and specify which wolfSSL products they want to include in their image. For example, to include wolfSSL with FIPS support, wolfSSH, and wolfMQTT, you would add to your local.conf:
IMAGE_INSTALL:append = " wolfssl wolfssh wolfmqtt "
The Yocto build system then handles downloading the source code, applying any necessary patches, configuring the build with appropriate options, compiling the libraries, and installing them into the target image—all automatically.
FIPS-Ready and Commercial Bundle Support
For organizations pursuing FIPS certification, the meta-wolfssl layer provides dedicated support for both FIPS-Ready and fully validated FIPS bundles. The FIPS-Ready configuration allows developers to build and test with the FIPS-validated cryptographic boundary before obtaining the commercial FIPS bundle, streamlining the development process.
The layer includes detailed documentation for building FIPS configurations, including the critical hash verification step required for FIPS integrity checking. This process ensures that the cryptographic module hasn’t been tampered with and maintains its validated state.
To use FIPS-Ready builds, developers set the WOLFSSL_TYPE variable:
WOLFSSL_TYPE = "fips-ready"
For commercial FIPS bundles, the layer supports password-protected archives and automated hash verification, ensuring that the validated cryptographic module is correctly integrated into the build.
Customization and Flexibility
Different embedded applications have different security requirements. A medical device might need TLS 1.3 with specific cipher suites, while an industrial controller might require hardware cryptographic acceleration. The meta-wolfssl layer supports extensive customization through bbappend files.
For example, if your application needs TLS 1.3 support, you can create a wolfssl_%.bbappend file that adds:
EXTRA_OECONF += "--enable-tls13"
This flexibility extends to all of wolfSSL’s configuration options, allowing you to enable or disable features, select cryptographic algorithms, configure hardware acceleration, and tune memory usage—all through the familiar Yocto configuration system.
Integration with Open Source Projects
The meta-wolfssl layer goes beyond just providing wolfSSL libraries. It includes bbappend files for popular open source projects, enabling them to use wolfSSL as their cryptographic and TLS provider. This includes:
- curl: The ubiquitous data transfer tool, configured to use wolfSSL for HTTPS
- OpenSSH: Secure shell implementation with wolfSSL cryptography
- strongSwan: IPsec VPN solution with wolfSSL support
- libssh2: SSH2 client library using wolfSSL
- tcpdump: Network packet analyzer with wolfSSL decryption support
These integrations mean that developers can build complete embedded systems with FIPS-validated cryptography throughout the software stack, not just in their custom applications.
Continuous Integration and Quality Assurance
wolfSSL’s commitment to Yocto support extends beyond just providing recipes—it includes comprehensive testing and continuous integration to ensure reliability.
Docker-Based Testing
The wolfSSL repository includes Docker configurations specifically for Yocto testing. The Docker/yocto directory contains a Dockerfile that sets up a complete Yocto build environment, clones the Poky reference distribution, integrates the meta-wolfssl layer, and builds a minimal image with wolfSSL products included.
This Docker-based approach serves multiple purposes. It provides a reproducible test environment for continuous integration, offers developers a quick way to experiment with wolfSSL on Yocto without setting up a full build environment, and serves as a reference implementation for integrating wolfSSL into custom Yocto builds.
The buildAndPush.sh script automates building Docker images for multiple Yocto versions (Kirkstone, Langdale, and Scarthgap), ensuring that wolfSSL’s Yocto support is tested across different releases. These images are published to DockerHub, making them available for developers to use as base images or reference implementations.
GitHub Actions Workflows
wolfSSL maintains an extensive suite of GitHub Actions workflows that test the library across numerous platforms, configurations, and integration scenarios. The comprehensive testing across different Linux distributions, compilers, and configurations ensures that wolfSSL builds reliably in the diverse environments that Yocto targets.
The packaging workflow tests creating Debian packages, which shares many of the same concerns as Yocto packaging: dependency management, installation paths, and configuration file handling. The multi-architecture workflow tests ARM, x86, and other processor architectures, ensuring that wolfSSL works correctly on the diverse hardware platforms that Yocto supports.
Platform-Specific Testing
The wolfSSL repository includes extensive documentation for cross-compiling to embedded platforms using Yocto-based SDKs. For example, the STM32MP13 and STM32MP25 documentation shows how to use the OpenSTLinux SDK (which is Yocto-based) to cross-compile wolfSSL with hardware cryptographic acceleration support.
These platform-specific guides demonstrate that wolfSSL’s Yocto support isn’t just theoretical—it’s actively used and tested on real embedded hardware platforms. The documentation includes performance benchmarks showing the benefits of hardware acceleration, configuration examples for different use cases, and troubleshooting guidance for common issues.
Real-World Use Cases: Where Yocto and FIPS Meet
The combination of wolfSSL’s FIPS-validated cryptography and Yocto’s flexible build system addresses real-world challenges across multiple industries:
Medical Devices
Medical devices that transmit patient data must comply with HIPAA regulations and often require FIPS-validated cryptography. A medical device manufacturer building a patient monitoring system on a custom ARM-based platform can use Yocto to create a minimal Linux distribution with exactly the components needed, including wolfSSL for FIPS-validated TLS connections to hospital networks. The reproducible build system ensures that every device ships with the same validated cryptographic implementation.
Industrial Control Systems
Industrial IoT devices and SCADA systems often operate in harsh environments with limited connectivity and must maintain security over decades of operation. Using Yocto with wolfSSL allows manufacturers to build hardened Linux systems with FIPS-validated cryptography for secure remote access and data transmission. The long-term support model of both Yocto and wolfSSL ensures that security updates can be maintained throughout the product lifecycle.
Defense and Government Systems
Military and government systems have strict security requirements, including mandatory FIPS 140-2 or 140-3 validation. These systems often use custom hardware platforms and require extensive customization. Yocto’s flexibility combined with wolfSSL’s FIPS-validated cryptography provides a path to meeting these requirements while maintaining the ability to customize and optimize for specific mission requirements.
Automotive Systems
Modern vehicles are increasingly connected, with requirements for secure over-the-air updates, vehicle-to-vehicle communication, and cloud connectivity. Automotive-grade Linux distributions built with Yocto can incorporate wolfSSL’s FIPS-validated cryptography to meet emerging automotive security standards while maintaining the real-time performance and resource efficiency required in automotive environments.
Financial Services
Point-of-sale terminals, ATMs, and payment processing devices must comply with PCI-DSS requirements and often require FIPS-validated cryptography. These devices typically run on embedded Linux systems built with Yocto. Using wolfSSL provides the required FIPS validation while maintaining the small footprint and performance needed for payment processing applications.
Getting Started: A Practical Path Forward
For organizations considering wolfSSL and Yocto for their FIPS-certified embedded systems, the path forward is well-documented and supported:
Step 1: Evaluate with Open Source
Start by experimenting with the open-source wolfSSL library and meta-wolfssl layer. Clone the repositories, build a test image with Yocto, and evaluate whether wolfSSL meets your functional requirements. The open-source version includes all the cryptographic functionality (though without FIPS validation) and allows you to test integration with your hardware platform and application.
Step 2: Prototype with FIPS-Ready
If FIPS certification is required, download the FIPS-Ready bundle from wolfSSL’s website. This bundle allows you to develop and test with the FIPS cryptographic boundary before purchasing the commercial FIPS bundle. The meta-wolfssl layer includes detailed instructions for building FIPS-Ready configurations with Yocto, including the hash verification process.
Step 3: Deploy with Commercial FIPS
Once your design is validated and you’re ready for production, obtain the commercial FIPS bundle from wolfSSL. This bundle includes the FIPS-validated cryptographic module with the necessary documentation and support for maintaining FIPS compliance. The meta-wolfssl layer supports commercial bundles with automated build integration.
Step 4: Maintain and Update
Throughout your product lifecycle, leverage Yocto’s layer system and wolfSSL’s long-term support to maintain security updates while preserving FIPS validation. The meta-wolfssl layer is actively maintained and updated to support new Yocto releases and wolfSSL versions.
Why This Combination Works
The synergy between wolfSSL and Yocto isn’t accidental, it reflects a deep understanding of embedded systems development challenges:
Size Matters: wolfSSL’s small footprint (20-100KB) aligns perfectly with the resource-constrained environments that Yocto targets. You can build secure systems without requiring excessive memory or storage.
Flexibility Without Fragmentation: Yocto provides flexibility to customize your Linux distribution, while wolfSSL’s extensive configuration options allow cryptographic customization. Together, they enable tailored solutions without creating unmaintainable custom code.
Standards Compliance: Both projects prioritize standards compliance. Yocto follows Linux and open-source best practices, while wolfSSL implements current TLS standards and maintains FIPS validation. This alignment simplifies compliance efforts.
Long-Term Support: Embedded products have long lifecycles. Both Yocto and wolfSSL provide long-term support and maintenance, ensuring that products can be supported throughout their operational life.
Active Communities: Both projects have active, responsive communities. When issues arise, there are knowledgeable developers and users who can provide assistance.
Conclusion: Security Without Compromise
Building secure embedded systems shouldn’t require choosing between security, performance, and maintainability. The combination of wolfSSL’s FIPS-validated cryptography and Yocto’s flexible build system provides a proven path to creating embedded products that meet stringent security requirements while remaining practical to develop, deploy, and maintain.
For organizations in regulated industries, healthcare, finance, defense, government, and critical infrastructure, this combination offers a clear path to FIPS compliance without sacrificing the flexibility and efficiency needed for modern embedded development. The comprehensive Yocto support through the meta-wolfssl layer, combined with extensive testing and documentation, means that developers can focus on their application logic rather than wrestling with cryptographic integration.
Whether you’re building medical devices that protect patient privacy, industrial systems that secure critical infrastructure, or defense systems that protect national security, wolfSSL and Yocto provide the foundation for embedded security done right.
Resources and Next Steps
To learn more about wolfSSL’s Yocto support:
- meta-wolfssl Repository
- wolfSSL Main Repository
- wolfSSL FIPS Information
- Yocto Project
- wolfSSL Documentation
For questions about FIPS certification, commercial licensing, or technical support, contact wolfSSL at:
The future of embedded security is built on strong cryptography, flexibility developement tools, and proven validation. With wolfSSL and Yocto, that future is available today.
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
Introducing wolfIP — a tiny, safe TCP/IP stack for embedded and safety‑critical systems
If you’ve ever tried to drop a full‑blown networking stack into a deeply embedded target, you know the drill: memory budgets get tight, timing gets squirrely, and dynamic allocation can turn certification efforts into a slog. wolfIP is our answer: a compact TCP/IP stack built with embedded systems in mind, that favors determinism over surprise. No malloc. No hidden threads. Just pre‑allocated buffers, a fixed number of sockets, and a BSD‑like non‑blocking socket API that’s easy to integrate.
wolfIP delivers a small, predictable networking core that pairs naturally with wolfSSL for end‑to‑end secure connectivity — and its static memory model makes it attractive for safety‑critical projects aiming at standards like DO‑178C.
Why wolfIP
Determinism by design. wolfIP allocates all working memory at compile time. That means you size your RX/TX pools and socket table up front and the runtime footprint never drifts. For developers working under tight RAM constraints — or subject to verification artifacts — this is a big deal.
Tiny, embedded‑first footprint. The stack targets microcontrollers and resource‑constrained systems. It currently supports endpoint mode (host only, no routing) with a single network interface, which is exactly what most MCUs need.
Safety‑friendly. Eliminating dynamic allocation and using pre‑defined buffer counts helps with worst‑case analysis and stack/heap audits. Combined with wolfSSL’s history of safety and security certifications, wolfIP gives you a clean path toward high‑assurance designs.
By design, it plays great with wolfSSL. The socket and callback model map cleanly to wolfSSL’s I/O hooks, making it straightforward to add TLS 1.3 on top of wolfIP for secure transport.
What’s inside (today)
- IPv4 host stack (endpoint mode)
- ARP, ICMP (echo replies), DHCP client, DNS client
- UDP (unicast)
- TCP (RFC 793) with support for Timestamps and MSS options
- BSD‑like, non‑blocking sockets with custom I/O callbacks
- No dynamic memory allocation
- Fixed number of concurrent sockets
- Pre‑allocated RX/TX packet buffers in static memory
This mix keeps the stack small while covering the embedded sweet spot: device discovery, basic IP services, UDP telemetry/command channels, and reliable TCP streams for control or TLS.
How small code base and static memory help safety certification
Safety standards such as RTCA DO‑178C reward designs that are predictable and analyzable. When your network stack:
- does not allocate at runtime,
- uses fixed‑size, pre‑allocated pools,
- exposes clear execution paths and bounded resources,
you basically simplify your worst‑case memory and timing analysis and reduce the effort to demonstrate determinism. In short: fewer surprises, more artifacts you can point to. wolfIP’s design aligns with these expectations and pairs naturally with wolfSSL / wolfCrypt, which already offers DO‑178C (up to DAL-A) artifacts for specific use-case scenarios.
A natural fit with wolfSSL
Need TLS on top of TCP? You can layer wolfSSL directly over wolfIP sockets using the familiar wolfSSL I/O callbacks. The result is a compact, all‑wolf stack that scales from tiny MCUs to robust RTOS and MPU environments — with a single vendor and API style end‑to‑end.
Getting started
- Clone the repository and build the provided examples/targets.
- Size your stack: edit the configuration header to set the maximum number of sockets and RX/TX buffer sizes according to your use case.
- Hook up your NIC/driver by implementing the simple callback interface for transmit/receive and link status.
- No drivers? Use our tap interface support, to test how the stack communicates with your POSIX system.
- (Optionally) Add TLS: bind your wolfIP socket to a WOLFSSL object and use wolfSSL’s send/recv callbacks to secure the connection with TLS 1.3.
- Check the provided https examples, tested with curl.
Because wolfIP is single‑interface and endpoint‑only, bring‑up is quick: DHCP + DNS for client use cases, or static IP for fixed installations. ICMP echo replies are built in, so you can ping your device as soon as the link is up.
Who should consider wolfIP
- MCU and bare‑metal projects that need predictable RAM and code size
- RTOS deployments where you want fine‑grained control over memory and scheduling
- Safety‑critical systems (avionics, industrial, medical) that benefit from static memory and bounded resources
- Teams who want a tight TLS integration with wolfSSL from a single vendor
Roadmap towards a stable release
wolfIP is active and evolving. Here are a few items recently developed, which are currently under review:
- Multiple datalink interfaces: support for an array of interfaces, with legacy APIs defaulting to the first (non‑loopback) interface; adds a loopback device and simple traffic forwarding between interfaces.
- IPsec ESP (transport mode): initial ESP encrypt/decrypt path to enable network‑layer protection for selected flows, plus packet debugging helpers (Ethernet/IP/TCP/ESP)
If you have a platform, NIC, or feature you’d like to see prioritized, drop us a line at facts@wolfssl.com.
Try it now
If you’re evaluating TCP/IP stacks for resource-constrained embedded or safety‑critical systems and want deterministic memory, strong TCP, and seamless TLS, give wolfIP a spin. We think you’ll like how small and predictable networking can be.
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
curl Award Month: Global Impact and Innovation
By 2020, curl’s reach extended far beyond the developer community, with its reliability and security earning international recognition. That year, Daniel Stenberg received a Google Patch Grant to further improve libcurl’s security, highlighting the importance of his work in safeguarding one of the most widely used software components in the world.
In 2021, curl’s contributions were recognized in an extraordinary way: Daniel was listed as a Mars 2020 Helicopter Contributor on GitHub, a badge awarded to developers whose projects were used in the Mars mission. This remarkable recognition illustrated the breadth of curl’s impact, extending from billions of devices on Earth to interplanetary exploration.
The same year, Daniel became a GitHub Star, a distinction honoring influential developers whose work inspires and supports the global developer community. He continued to receive this recognition annually through 2025, further reflecting curl’s critical role in shaping open-source development.
In 2024, Daniel was named a Microsoft Most Valuable Professional (MVP) in C++ and web development, a recognition of his outstanding contributions to the broader software community. While this program spans thousands of recipients, it underscores the continued relevance and influence of curl in both open-source and enterprise environments.
Together, these honors demonstrate curl’s evolution from a groundbreaking open-source tool to a globally recognized project. They reflect not only Daniel’s expertise and dedication but also curl’s enduring role in advancing technology and enabling developers worldwide.
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
PDF Signing Meets FIPS-Capable PKCS#11: pdfsig + wolfPKCS11 + NSS
We’re excited to announce that the widely-used PDF signature tool pdfsig can now be used with wolfPKCS11 and NSS!
This integration allows you to digitally sign PDF documents using PKCS#11 keys using software tokens, HSMs, or secure elements, through the NSS framework. All powered by the FIPS-ready wolfCrypt engine.
Why This Matters
For many applications – document workflows, certification, legal-signing chains – the ability to sign PDF files in a standards-compliant way is essential. pdfsig is a command-line tool (part of Poppler/NSS toolset) that supports PDF digital signatures, verifying them and creating them (when used with proper PDF fields). FreeBSD Manual Pages+1
With wolfPKCS11 acting as a full PKCS#11 provider for NSS, you can now:
- Bring in a FIPS 140-3 validated cryptographic engine (wolfCrypt) under the covers via wolfPKCS11 for high-assurance signing.
- For embedded Linux applications, use a TPM along with wolfTPM to securely store signing keys, or leverage the secure domain when using wolfBoot.
How It Works
pdfsig (part of Poppler’s tools) supports digital signatures when NSS provides the signing backend.
By loading wolfPKCS11 as a PKCS#11 module in NSS, the signing key and certificate can come from any token accessible via the wolfPKCS11 provider.
Here’s what happens under the hood:
- NSS loads the wolfPKCS11 shared library as a PKCS#11 provider.
- NSS accesses the token (software, TPM, or HSM) for the private key.
- pdfsig signs the PDF via NSS, which routes cryptographic operations through wolfPKCS11 and wolfCrypt.
- The resulting PDF contains a standards-compliant signature validated by any conformant PDF viewer.
Example: Signing a PDF via NSS and wolfPKCS11
Once you have compiled wolfPKCS11 with NSS, the wolfPKCS11 backend module is used instead of NSS’s built-in one (a small patch to NSS is needed), this ensures that wolfCrypt is used for all cryptographic operations. You can then run:
# 1. Create a new NSS database mkdir ~/nssdb echo "mypassword" > ~/nssdb/password.txt certutil -N -d $HOME/nssdb -f ~/nssdb/password.txt # 2. Import a certificate and private key into the token pk12util -i mycert.p12 -d $HOME/nssdb -W mypassword # 3. Verify that NSS can see the token and key certutil -L -d $HOME/nssdb # 4. Sign a PDF file using pdfsig via wolfPKCS11 + NSS pdfsig input.pdf signed.pdf \ -add-signature \ -d $HOME/nssdb \ -nss-pwd mypassword \ -nick "pkcs11:token=mytoken;object=mykey;type=private" \ -reason "Approved using wolfPKCS11" # 5. Verify the signature pdfsig signed.pdf
This creates a signed PDF that includes the proper signature field and certificate chain, validated by most PDF viewers.
Benefits
- Hardware-Backed Security: Supports HSMs, TPMs, and other secure key stores via PKCS#11.
- FIPS-Ready Cryptography: Leverages wolfCrypt’s FIPS 140-3 validated algorithms.
- Automation Friendly: Perfect for document signing pipelines and CI/CD workflows.
- Interoperable: Works with standard NSS tooling — no vendor lock-in.
Getting Started
- Install wolfPKCS11 and wolfSSL from GitHub.
- Patch and compile NSS with the patch in GitHub.
- Import your signing key and certificate into the NSS token.
- Use pdfsig to sign and verify PDF files directly through NSS.
Alternatively, our wolfPKCS11 examples repository has a Dockerfile which can build everything and will run an example sign and verify.
Find out more
If you’d like to integrate wolfPKCS11 with your document signing, HSM, or workflow automation system, contact us at facts@wolfssl.com or call us at +1 425 245 8247 for guidance or evaluation support.
Download wolfSSL Now
Benchmarking Memory Usage in wolfCrypt Bench: New Heap and Stack Tracking Support
During a recent industry expo, the wolfSSL team demonstrated the wolfCrypt benchmark and received frequent questions about memory usage, particularly for post-quantum algorithms.
We happened to be working on a feature which would provide exactly what was being asked for at the time, and I’m happy to report that it is wolfSSL’s GitHub repository now and will be included in the next wolfSSL release.
How it works
When building wolfSSL, memory and stack tracking can be enabled via ./confgure options –enable-memory –enable-trackmemory=verbose –enable-stacksize=verbose, or by adding the following macro definitions:
#define WOLFSSL_TRACK_MEMORY #define WOLFSSL_TRACK_MEMORY_VERBOSE #define HAVE_STACK_SIZE #define HAVE_STACK_SIZE_VERBOSE
These options activate both heap allocation tracking and detailed stack usage reporting within the wolfCrypt benchmark.
This allows the benchmark to track the peak and total memory usage during the benchmark for each algorithm, as well as totals for the entire application at the end.
Unlike the regular performance benchmark recording, this mode also tracks memory during the setup phase of each algorithm so that you can see how much RAM is used for the entire initialization and execution of an algorithm.
Example
This example is with an STM32U585 compiled with hardware acceleration for RNG, AES and SHA-256, demonstrating how memory tracking behaves on a resource-constrained embedded system. It is using the small memory model for the post-quantum algorithms:
wolfCrypt Benchmark (block bytes 1024, min 1.0 sec each) RNG 425 KiB took 1.039 seconds, 409.047 KiB/s [heap 494 bytes (8 allocs), stack 1448 bytes] AES-128-CBC-enc 9 MiB took 1.000 seconds, 8.521 MiB/s [heap 312 bytes (1 allocs), stack 736 bytes] AES-128-CBC-dec 8 MiB took 1.000 seconds, 8.472 MiB/s [heap 312 bytes (1 allocs), stack 736 bytes] AES-256-CBC-enc 8 MiB took 1.000 seconds, 7.910 MiB/s [heap 312 bytes (1 allocs), stack 736 bytes] AES-256-CBC-dec 8 MiB took 1.000 seconds, 7.861 MiB/s [heap 312 bytes (1 allocs), stack 736 bytes] AES-128-GCM-enc 8 MiB took 1.000 seconds, 7.935 MiB/s [heap 344 bytes (3 allocs), stack 992 bytes] AES-128-GCM-dec 8 MiB took 1.000 seconds, 7.886 MiB/s [heap 312 bytes (1 allocs), stack 984 bytes] AES-256-GCM-enc 7 MiB took 1.000 seconds, 7.397 MiB/s [heap 344 bytes (3 allocs), stack 976 bytes] AES-256-GCM-dec 7 MiB took 1.000 seconds, 7.349 MiB/s [heap 312 bytes (1 allocs), stack 984 bytes] AES-128-GCM-enc-no_AAD 8 MiB took 1.000 seconds, 7.983 MiB/s [heap 344 bytes (3 allocs), stack 976 bytes] AES-128-GCM-dec-no_AAD 8 MiB took 1.000 seconds, 7.935 MiB/s [heap 312 bytes (1 allocs), stack 944 bytes] AES-256-GCM-enc-no_AAD 7 MiB took 1.000 seconds, 7.422 MiB/s [heap 344 bytes (3 allocs), stack 976 bytes] AES-256-GCM-dec-no_AAD 7 MiB took 1.000 seconds, 7.397 MiB/s [heap 312 bytes (1 allocs), stack 944 bytes] GMAC Small 14 MiB took 1.000 seconds, 14.154 MiB/s [heap 0 bytes (0allocs), stack 1536 bytes] CHACHA 6 MiB took 1.000 seconds, 5.688 MiB/s [heap 68 bytes (1 allocs), stack 624 bytes] CHA-POLY 4 MiB took 1.004 seconds, 3.623 MiB/s [heap 232 bytes (4 allocs), stack 672 bytes] POLY1305 16 MiB took 1.000 seconds, 15.918 MiB/s [heap 40 bytes (1 allocs), stack 800 bytes] SHA-256 14 MiB took 1.000 seconds, 14.429 MiB/s [heap 344 bytes (2 allocs), stack 624 bytes] SHA-384 1 MiB took 1.012 seconds, 1.158 MiB/s [heap 400 bytes (3 allocs), stack 624 bytes] SHA-512 1 MiB took 1.016 seconds, 1.153 MiB/s [heap 416 bytes (3 allocs), stack 658 bytes] SHA-512/224 1 MiB took 1.012 seconds, 1.158 MiB/s [heap 380 bytes (3 allocs), stack 624 bytes] SHA-512/256 1 MiB took 1.012 seconds, 1.158 MiB/s [heap 384 bytes (3 allocs), stack 624 bytes] SHA3-224 1 MiB took 1.003 seconds, 1.290 MiB/s [heap 436 bytes (2 allocs), stack 656 bytes] SHA3-256 1 MiB took 1.000 seconds, 1.221 MiB/s [heap 440 bytes (2 allocs), stack 656 bytes] SHA3-384 975 KiB took 1.016 seconds, 959.646 KiB/s [heap 456 bytes (2 allocs), stack 656 bytes] SHA3-512 675 KiB took 1.008 seconds, 669.643 KiB/s [heap 472 bytes (2 allocs), stack 656 bytes] SHAKE128 2 MiB took 1.012 seconds, 1.496 MiB/s [heap 576 bytes (2 allocs), stack 672 bytes] SHAKE256 1 MiB took 1.003 seconds, 1.217 MiB/s [heap 544 bytes (2 allocs), stack 656 bytes] HMAC-SHA256 14 MiB took 1.000 seconds, 14.014 MiB/s [heap 768 bytes (1 allocs), stack 784 bytes] HMAC-SHA384 1 MiB took 1.008 seconds, 1.138 MiB/s [heap 896 bytes (2 allocs), stack 840 bytes] HMAC-SHA512 1 MiB took 1.008 seconds, 1.138 MiB/s [heap 896 bytes (2 allocs), stack 784 bytes] RSA 2048 public 58 ops took 1.000 sec, avg 17.241 ms, 58.000 ops/sec [heap 6725 bytes (6 allocs), stack 1040 bytes] RSA 2048 private 2 ops took 2.047 sec, avg 1023.500 ms, 0.977 ops/sec [heap 2860 bytes (4 allocs), stack 1096 bytes] DH 2048 key gen 3 ops took 1.278 sec, avg 426.000 ms, 2.347 ops/sec [heap 7752 bytes (10 allocs), stack 1072 bytes] DH 2048 agree 4 ops took 1.706 sec, avg 426.500 ms, 2.345 ops/sec [heap 10428 bytes (9 allocs), stack 1376 bytes] ML-KEM 512 128 key gen 290 ops took 1.004 sec, avg 3.462 ms, 288.845 ops/sec[heap 1530 bytes (2 allocs), stack 1096 bytes] ML-KEM 512 128 encap 278 ops took 1.004 sec, avg 3.612 ms, 276.892 ops/sec[heap 3578 bytes (2 allocs), stack 1088 bytes] ML-KEM 512 128 decap 206 ops took 1.000 sec, avg 4.854 ms, 206.000 ops/sec[heap 4346 bytes (3 allocs), stack 1088 bytes] ML-KEM 768 192 key gen 176 ops took 1.000 sec, avg 5.682 ms, 176.000 ops/sec[heap 2042 bytes (2 allocs), stack 1096 bytes] ML-KEM 768 192 encap 164 ops took 1.008 sec, avg 6.146 ms, 162.698 ops/sec[heap 5114 bytes (2 allocs), stack 1792 bytes] ML-KEM 768 192 decap 128 ops took 1.012 sec, avg 7.906 ms, 126.482 ops/sec[heap 6202 bytes (3 allocs), stack 1792 bytes] ML-KEM 1024 256 key gen 108 ops took 1.004 sec, avg 9.296 ms, 107.570 ops/sec[heap 2554 bytes (2 allocs), stack 1096 bytes] ML-KEM 1024 256 encap 102 ops took 1.008 sec, avg 9.882 ms, 101.190 ops/sec[heap 6650 bytes (2 allocs), stack 1792 bytes] ML-KEM 1024 256 decap 84 ops took 1.019 sec, avg 12.131 ms, 82.434 ops/sec[heap 8218 bytes (3 allocs), stack 1792 bytes] ECC [ SECP256R1] 256 key gen 12 ops took 1.008 sec, avg 84.000 ms, 11.905 ops/sec [heap 4628 bytes (6 allocs), stack 1080 bytes] ECDHE [ SECP256R1] 256 agree 12 ops took 1.004 sec, avg 83.667 ms, 11.952 ops/sec [heap 9393 bytes (15 allocs), stack 1416 bytes] ECDSA [ SECP256R1] 256 sign 58 ops took 1.023 sec, avg 17.638 ms, 56.696 ops/sec [heap 308 bytes (5 allocs), stack 1112 bytes] ECDSA [ SECP256R1] 256 verify 54 ops took 1.000 sec, avg 18.519 ms, 54.000 ops/sec [heap 152 bytes (2 allocs), stack 1432 bytes] CURVE 25519 key gen 3 ops took 1.086 sec, avg 362.000 ms, 2.762 ops/sec [heap 119 bytes (3 allocs), stack 1000 bytes] CURVE 25519 agree 4 ops took 1.447 sec, avg 361.750 ms, 2.764 ops/sec [heap 119 bytes (3 allocs), stack 1768 bytes] ED 25519 key gen 3 ops took 1.102 sec, avg 367.333 ms, 2.722 ops/sec [heap 128 bytes (3 allocs), stack 1136 bytes] ED 25519 sign 4 ops took 1.494 sec, avg 373.500 ms, 2.677 ops/sec [heap 256 bytes (4 allocs), stack 1792 bytes] ED 25519 verify 2 ops took 1.538 sec, avg 769.000 ms, 1.300 ops/sec [heap 128 bytes (1 allocs), stack 1792 bytes] ML-DSA 44 key gen 66 ops took 1.000 sec, avg 15.152 ms, 66.000 ops/sec [heap 26531 bytes (6 allocs), stack 1072 bytes] ML-DSA 44 sign 16 ops took 1.051 sec, avg 65.688 ms, 15.224 ops/sec [heap 15528 bytes (3 allocs), stack 1416 bytes] ML-DSA 44 verify 62 ops took 1.027 sec, avg 16.565 ms, 60.370 ops/sec [heap 8104 bytes (1 allocs), stack 1416 bytes] ML-DSA 65 key gen 38 ops took 1.016 sec, avg 26.737 ms, 37.402 ops/sec [heap 31651 bytes (6 allocs), stack 1040 bytes] ML-DSA 65 sign 8 ops took 1.008 sec, avg 126.000 ms, 7.937 ops/sec [heap 20648 bytes (3 allocs), stack 1416 bytes] ML-DSA 65 verify 38 ops took 1.039 sec, avg 27.342 ms, 36.574 ops/sec [heap 9128 bytes (1 allocs), stack 1416 bytes] ML-DSA 87 key gen 24 ops took 1.079 sec, avg 44.958 ms, 22.243 ops/sec [heap 37795 bytes (6 allocs), stack 1072 bytes] ML-DSA 87 sign 6 ops took 1.146 sec, avg 191.000 ms, 5.236 ops/sec [heap 26792 bytes (3 allocs), stack 1416 bytes] ML-DSA 87 verify 22 ops took 1.024 sec, avg 46.545 ms, 21.484 ops/sec [heap 11432 bytes (1 allocs), stack 1416 bytes] Benchmark complete
Better rendering
If you find this data a little complicated to read at a glance, there are two things that can help you. The first is that the wolfCrypt benchmark can be configured to output CSV data; this additional memory tracking will appear in the CSV results. Alternatively, we have a Python script which can reinterpret the benchmark data into a nice table format. Currently, the Python rendering script targets the STM32U585 demo, but it can be easily adapted for other platforms upon request.
Conclusion
With this new enhancement, wolfCrypt users can now quantify both performance and memory footprint under different compile-time configurations. This is especially valuable for post-quantum cryptography and embedded use cases where memory efficiency is critical.
For now this works with bare-metal and POSIX systems, but we intend to adapt it to work with other operating systems, including RTOSs, in the future.
If you have questions about any of the above, please contact us at facts@wolfssl.com or call us at +1 425 245 8247.
Download wolfSSL Now
wolfSSL at MilCIS 2025: Our First Trade Show in Australia
wolfSSL is excited to attend MilCIS 2025 in Canberra, Australia, from November 18–20 for the very first time! MilCIS is Australia’s leading event for military communications, information systems, and defense cyber, making it a perfect match for wolfSSL’s mission of delivering secure, high-performance encryption for mission-critical systems.
Our Lead Engineer, Sean Parkinson, will be on site at Booth M10 to meet attendees, discuss secure communications, and showcase how wolfSSL supports modern defense programs with FIPS 140-3-validated cryptography and DO-178C DAL A-compliant solutions for embedded and safety-critical systems.
Complimentary registrations are available! Stop by to talk to us and learn how we can help strengthen your defense communication systems, or email us in advance to schedule a meeting with our team.
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
Coming Soon: wolfSSL Takes PQC Toward FIPS Certification
wolfSSL is taking proactive steps to get our PQC implementations for FIPS 203 (ML-KEM), FIPS 204 (ML-DSA) LMS (verify-only) and XMSS (verify-only) validated through NIST. These standards define quantum-resistant key exchange and digital signature algorithms that meet the CNSA 2.0 transition requirements for government and regulated industries.
FIPS certification is the gold standard for cryptographic compliance in government and regulated industries. Achieving FIPS validation ensures wolfSSL’s PQC remains secure, standards-based, and ready for deployment in real-world systems as quantum-safe adoption accelerates.
wolfSSL is actively advancing its post-quantum validation efforts and will share updates as the process evolves.
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: Post-Quantum TLS 1.3 with wolfSSL on NXP FRDM-MCXN947
Secure the Future of Embedded Connectivity.
Join our upcoming partner webinar with NXP and wolfSSL to explore how to defend connected devices from the emerging threat of quantum computing. See how to deploy post-quantum cryptography (PQC) with wolfSSL on the NXP FRDM-MCXN947 platform — and see a live quantum-safe TLS 1.3 demo.
Register Now: Post-Quantum TLS 1.3 with wolfSSL on NXP FRDM-MCXN947
Date: November 19 | 9 AM PT
The FRDM-MCXN947 development board from NXP is designed for high-performance, intelligent edge applications with demanding security and connectivity requirements. Built around dual Arm® Cortex-M33 cores and offering rich on-board expansion and debugging tools, it provides a solid foundation for evaluating next-generation cryptography in embedded environments.
wolfSSL’s post-quantum solution is built for real-world deployment. The wolfCrypt Post Quantum stack offers fully integrated support for TLS 1.3, enabling quantum-safe key encapsulation (ML-KEM) and digital signatures (ML-DSA) that meet CNSA 2.0 compliance.
What you’ll learn:
- Introduction to wolfSSL and NXP
- Overview of the FRDM-MCXN947 platform
- Why PQC matters now
- Technical deep dive: TLS 1.3 and wolfCrypt PQC implementations
- How ML-KEM and ML-DSA reinforce security
- Demo on the FRDM-MCXN947 + performance benchmarks
Register today to see PQC in action on real hardware.
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
curl Award Month: Recognition in Sweden and Beyond
By 2016, curl had firmly established itself as an indispensable tool for developers worldwide. Its impact was no longer just technical; it was being recognized nationally for its significance and influence.
In 2016, Daniel Stenberg was named Second Best Developer in Sweden, an award that highlighted not only his coding expertise but also his commitment to fostering the open-source community in meaningful ways.
The following year, Daniel received the prestigious Polhem Prize (2017), awarded by the Royal Swedish Academy of Engineering Sciences. This accolade celebrated the engineering excellence behind curl, noting its widespread use across billions of devices and the immense societal value of making robust, reliable software freely available to all. The award ceremony even included a personal presentation by the King of Sweden, underscoring the national significance of his achievement.
In 2019, curl’s legacy was further cemented when Daniel was honored as an Internet Pioneer by Sweden’s Internetmuseum. This recognition highlighted curl’s historical and cultural impact, celebrating Daniel’s role in shaping the digital landscape and inspiring future generations of developers.
Together, these honors illustrate curl’s rise from a powerful technical tool to a symbol of open-source innovation and influence. They underscore the importance of community, collaboration, and vision in creating software that not only works but also transforms the way we connect and communicate.
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
Coming Soon: wolfHSM Integration for NXP S32G & S32N Processors
wolfHSM is expanding to support NXP’s S32G and S32N processors. That means hardware-rooted cryptography and high-performance HSM capabilities are coming to even more automotive and industrial platforms.
This expansion means stronger security, faster cryptographic operations, and seamless integration for embedded developers looking to protect critical systems. Built for flexibility, wolfHSM continues to deliver trusted, scalable security across platforms.
Stay tuned! Support is rolling out soon! We’ll share updates on availability and integration guides here on our blog.
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