Category: wolfCrypt FIPS

We’re excited to announce that wolfSSL is taking the next step in its journey to bring FIPS 140-3 compliance to the WireGuard ecosystem. Following our successful ports of our FIPS crypto into both WireGuard-linux and Wireguard-GO, we are setting our sights on a new target: BoringTun.

BoringTun is a popular, high-performance implementation of the WireGuard protocol written in Rust. It’s used by major players in the tech industry and as the demand for robust, certified cryptographic solutions grows — especially within government and highly regulated sectors — it is a logical next step to provide the same level of cryptographic assurance for this key WireGuard implementation.

wolfSSL has begun the process of integrating our FIPS 140-3 validated library wolfCrypt directly into BoringTun. This project will replace BoringTun’s existing cryptographic backend with a FIPS-compliant alternative, providing the same high-speed, modern protocol that WireGuard is known for, but with the added assurance of a government-certified cryptography module.

This will make BoringTun a viable option for organizations that have a CMMC 2.0, FEDRAMP, or FIPS 140-3 requirement. Are you interested in a FIPS certified BoringTun?

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

Download wolfSSL Now

We recently shared our top 15 FIPS acronyms and terms to help you get familiar with the basics. Now, let’s dive deeper into what each of these means and why they matter in the FIPS 140-3 certification process.

1. FIPS – Federal Information Processing Standards

   FIPS are standards published by the U.S. federal government that specify security requirements for cryptographic modules. FIPS 140-3 is the current standard for validating cryptographic modules, ensuring they meet strict security and implementation guidelines for use in government and regulated industries.

2. NIST – National Institute of Standards and Technology

   NIST develops and maintains FIPS standards. It also oversees the Cryptographic Module Validation Program (CMVP), coordinating with testing labs and vendors to ensure modules meet FIPS 140-3 requirements.

3. CMVP – Cryptographic Module Validation Program

   This is the official program, jointly run by NIST and Canada’s CCCS, that validates cryptographic modules against the FIPS 140-3 standard. Vendors submit their modules to CMVP-accredited labs, which test and verify compliance before issuing certificates.

4. CAVP – Cryptographic Algorithm Validation Program

   Before a cryptographic module can be validated, each cryptographic algorithm it uses (such as AES, SHA, ML-KEM, ML-DSA, RSA, ED25519, KDF’s for various protocols… etc.) must be validated under CAVP. This ensures the algorithms are correctly implemented and function as intended and guarantees interoperability with any other validated module(s).

5. ESV – Entropy Source Validation

   Entropy Source Validation is a separate validation process that verifies the quality and reliability of the randomness source used by the cryptographic module, crucial for secure key generation and other cryptographic operations that depend on high quality entropy to guarantee certain levels of bit-strength.

6. ACVP – Automated Cryptographic Validation Protocol

   ACVP is the automated system that facilitates cryptographic algorithm testing within the CAVP framework. It allows machine-to-machine communication between vendors and validation servers (DEMO), and labs and validation servers (PRODUCTION) speeding up the testing process and reducing errors.

7. NVLAP – National Voluntary Lab Accreditation Program

   NVLAP accredits independent labs authorized to perform FIPS 140-3 testing. Only NVLAP-accredited labs can conduct the official testing required for CMVP certification.

8. SP – Security Policy

   The Security Policy is a detailed document that describes the cryptographic module’s security features, intended use, and operational modes. It defines how the module should be configured and used to remain compliant and in the approved mode of operation.

9. UG – User Guide

   The User Guide provides instructions for deploying and operating the cryptographic module securely and in compliance with FIPS requirements. It ensures end users configure and use the module correctly so it is running the FIPS 140-3 approved mode of operation.

10. OE – Operational Environment

    The Operational Environment refers to the specific combination of hardware (chipset), operating system, and cryptographic module configuration used during testing. Different OEs require separate validation to ensure proper validation/certification.

11. Tested Configuration

    The Tested Configuration specifies the exact hardware and software setup (including form factor, OS version, chipset details) that was used during testing. Users must match this configuration to maintain FIPS 140-3 validation.

12. OEUP – Operational Environment Update

    An OEUP is a process to add a new Operational Environment (new chipset or OS) to an existing FIPS certificate without undergoing full revalidation. This allows validated modules to support more platforms efficiently over time.

13. UPDT – Module Update

    A Module Update (UPDT) applies when there are security-relevant changes to the cryptographic module, such as updates to code, algorithms, or key management. It requires a new certificate and resets the module’s sunset date.

14. PAA – Processor Algorithm Acceleration

    Processor Algorithm Acceleration refers to hardware-assisted cryptographic acceleration features, like AES-NI or Arm Crypto Extensions, which improve performance and efficiency of cryptographic operations within validated modules.

15. RBND – Rebrand

    Rebranding (RBND) lets a company apply its own branding and logo to an existing FIPS 140-3 certified module, often referred to as white-labeling. This helps companies market validated products without needing to repeat the entire certification process or point to a third-party certificate for their products.

Understanding these terms is critical whether you’re developing, integrating, or managing FIPS 140-3 validated cryptographic modules. At wolfSSL, we leverage this knowledge to help customers navigate complex validation requirements and deliver secure, compliant solutions.

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

Working with FIPS 140-3 can get confusing fast, especially with all the acronyms involved. To help cut through the noise, here are our top 15 FIPS-related terms:

• FIPS – Federal Information Processing Standards
• NIST – National Institute of Standards and Technology
• CMVP – Cryptographic Module Validation Program
• CAVP – Cryptographic Algorithm Validation Program
• ESV – Entropy Source Validation (separate from but complimentary to a FIPS certificate)
• ACVP – Automated Cryptographic Validation Protocol
• NVLAP – National Voluntary Lab Accreditation Program
• SP – Security Policy
• UG – User Guide
• OE – Operational Environment (Chipset + OS + Cryptographic module)
• Tested Configuration – OE description including form factor used for testing
• OEUP – Operational Environment Update (add an OE to an existing FIPS certificate)
• UPDT – Module Update (Security relevant changes to an existing FIPS module, results in a new certificate # and new sunset date)
• PAA – Processor Algorithm Acceleration (Hardware assisted cryptographic acceleration)
• RBND – Rebrand an existing FIPS certificate into your company’s own letter/logo-head for marketing purposes (often referred to as a white-label)

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

Are you one of our customers tasked by the US federal government to implement their newly minted AI initiatives? Then go get a cup of coffee and sit down because you are going to want to hear what we have to say about the MCP (Model Context Protocol) and how it relates to FIPS 140-3.

The Model Context Protocol (MCP) is a framework that provides AI models with relevant, structured context to improve efficiency and accuracy around how the data is used. It ensures AI agents receive pertinent data and environmental cues for optimal performance, reducing ambiguity, enhancing decision-making, and streamlining AI-environment interaction.

The protocol works on a client-server model. The servers are, generally speaking, data and service providers while the clients are the AI agents. MCP servers can provide real-time sensor data, historical archives, structured databases (CRM, ERP), knowledge bases, and external API access (weather, mapping, translation). MCP clients are AI entities, from chatbots to complex autonomous systems, needing external data/services. Examples include, LLMs, decision-making AIs and robotics/autonomous vehicles.

Here are just a few examples of servers within agencies of the US Federal Government:

• NASA
• Department of Veterans Affairs (VA)
• Department of Commerce (U.S. Census Bureau)

The messages are formatted as JSON with some predefined fields. The important part is that these messages need to be authenticated, encrypted, and integrity checked. From the https://modelcontextprotocol.io/docs/concepts/transports:

> Always use TLS/HTTPS for production deployments

So if the US federal government is going to be contracting you to create an AI MCP client to leverage these servers, then you can bet your bottom dollar that it needs to be using FIPS 140-3 certified cryptography.

Want to learn more about our laddered-approach to FIPS 140-3 certifications and our evergreen licensing model? Send a message to fips@wolfssl.com or facts@wolfssl.com and we’ll be happy to explain it all to you!

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

EDMONDS, Wash., Aug. 4, 2025 /PRNewswire-PRWeb/ — wolfSSL Inc., a globally renowned leader in cryptography and network security solutions, announces the latest milestone in its FIPS strategy with the issuance of FIPS 140-3 Validated Certificate #5041 for the wolfCrypt cryptographic module. This marks yet another step forward in wolfSSL’s long-term strategy to deliver agile, secure, and compliant cryptography across embedded and enterprise environments.

Evergreen FIPS 140-3 Subscription Program

FIPS 140-3 Validated Certificate #5041, effective through July 2030, extends the life cycle of wolfSSL’s industry-first SP800-140Br1 FIPS 140-3 Validated Certificate #4718, providing customers with flexibility, long-term assurance, and uninterrupted compliance under evolving FIPS 140-3 requirements.

This new certificate represents more than just continuity, it’s a reflection of our unwavering commitment to security leadership and customer success, said Todd Ouska, wolfSSL CTO. With our Evergreen Certificate Subscription, organizations using wolfSSL maintain continuous compliance, seamlessly transitioning to the latest validations without disruption or compliance gaps.

wolfSSL’s Evergreen Certificate Subscription eliminates expiration gaps for FIPS 140-3 validations. Customers purchasing an Evergreen FIPS Subscription automatically transition from Certificate #4718 to #5041 upon #4718’s expiration. With three more certificates already in the queue, each with rolling expiration dates, wolfSSL’s customers can easily maintain continuous FIPS coverage at an economic price.

Full Linux FIPS 140-3

wolfSSL’s Full Linux FIPS offering simplifies FIPS compliance for operating systems that host a variety of cryptography libraries. This solution is for NVIDIA Open GPU, Alpine, Dynebolic, Debian, Alma, Yocto, Rocky,Gentoo, KALI and other Linux distributions that don’t have a current FIPS solution. By patching key libraries, including GnuTLS, OpenSSL, NSS, libgcrypt, and the Linux kernel, wolfSSL enables FIPS 140-3 compliance without modifying application code. This solution can also be made available for BSD. Linux consumers will no longer be burdened with leaving their favorite distro to go to an expensive per cpu subscription to get to FIPS compliance.

This integration simplifies the lives of maintainers that need to get to FIPS 140-3 for government use. It provides immediate access to wolfCrypt’s validated algorithms, cutting down the time and complexity of certification from years to months.

Post Quantum FIPS 140-3 support

wolfSSL stays ahead of FIPS 140-3 certification with two additional certifications in process:

• Our next cert adds SRTP and XTS to support secure real-time communications and encrypted storage
• Post-Quantum FIPS 140-3 Certification: Aligned with CNSA 2.0 guidance and kicking off this year, this certification will feature quantum-resistant algorithms such as ML-KEM ML-DSA, LMS, and XMSS

These upcoming certifications reinforce wolfSSL’s reputation as the most agile and forward-compatible cryptographic provider on the market.

Contact us at: fips@wolfssl.com

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

Space missions require strong security to guard against cyber threats. The wolfCrypt cryptography library meets all encryption requirements in NASA’s Space System Protection Standard (NASA-STD-1006A), providing lightweight cryptography suited for resource-constrained secure command communications.

Understanding NASA-STD-1006A

NASA-STD-1006A, titled “Space System Protection Requirements,” establishes agency-level guidelines to make NASA missions resilient against cyber threats. Approved in 2019 and updated as needed, the standard focuses on safeguarding command stacks, backup links, and critical program information (CPI). Key encryption mandates include protecting command paths with cryptography that meets or exceeds Federal Information Processing Standard (FIPS) 140 Level 1.

You can access the full standard on NASA’s official standards portal: NASA-STD-1006A.

How wolfCrypt Meets These Requirements

wolfCrypt is a lightweight, ANSI C-based crypto library designed for embedded and RTOS environments, making it ideal for space applications where size, speed, and power efficiency are critical. With a small footprint and royalty-free licensing, it’s deployed in millions of devices worldwide.

At the heart of its compliance is wolfCrypt’s FIPS 140-3 validation (Certificate #4718), which meets the standard’s FIPS 140 Level 1 requirement. This validation confirms that wolfCrypt’s implementations are secure and reliable. wolfCrypt’s validated algorithms can be directly used to address NASA-STD-1006A’s core requirements, such as encrypting command stacks (SSPR 1) and supporting authentication for backups (SSPR 2). For CPI protection (SSPR 3), wolfCrypt integrates seamlessly with NIST SP 800-171 practices, ensuring data confidentiality at rest and in transit.

Additionally, wolfCrypt supports progressive ciphers, post-quantum options (ML-KEM, ML-DSA, LMS, XMSS), and assembly optimizations for a variety of architectures.

If needed, wolfSSL also offers a secure bootloader for microcontrollers (wolfBoot), a software HSM library (wolfHSM), a secure SSL/TLS implementation (wolfSSL), and more!

wolfCrypt in Space: Real-World Applications

wolfSSL has a proven track record in high-stakes environments, including aerospace and defense. Our recent collaboration with Frontgrade Gaisler enhances cybersecurity for space applications by integrating wolfCrypt into radiation-hardened processors, ensuring secure communications in harsh orbital conditions. Read more about this partnership: Frontgrade Gaisler and wolfSSL Collaboration.

wolfCrypt’s modular design also supports DO-178C DAL A certification for avionics, further demonstrating its suitability for space systems. If you’re working on NASA-compliant projects, wolfCrypt provides the tools to build resilient, threat-resistant architectures.

Why Choose wolfCrypt for Your Space System?

• Lightweight and Efficient: Minimal runtime memory and build size, perfect for embedded space hardware.
• Comprehensive Support: Backed by wolfSSL’s expert team, with resources like benchmarks, hardware integration guides, and an OpenSSL compatibility layer.
• Future-Proof Security: Includes post-quantum cryptography to guard against emerging threats.
• Easy Integration: Simple API, extensive documentation, and examples available in our GitHub repository: wolfSSL Examples.

Ready to Secure Your Mission?

If you’re ready to integrate wolfCrypt into your space system, need support, or have questions about any of the above, please contact our team at facts@wolfssl.com, call +1 425 245 8247, or visit our support page: wolfSSL Support.

Download wolfSSL Now

We’re proud to announce that our copy of wolfCrypt has officially again received FIPS 140-3 validation, listed under certificate #5041, posted on July 18, 2025 by NIST. This validation reflects our continued commitment to building secure, standards-compliant products using rigorously tested cryptography.

This FIPS 140-3 version of wolfCrypt improves on the earlier 140-2 validation in several key ways:

• Faster boot times: Self-tests are deferred until the first use of each algorithm, rather than running all at startup.
• Optimized for embedded systems: Minimal footprint, low power consumption, and efficient performance for real-time and resource-constrained environments.
• Expanded algorithm support, including:
  • AES-OFB mode
  • RSA 3072, 4096, and PSS
  • TLS 1.2 and TLS 1.3 key derivation functions (KDF)
  • SSH KDF
• New degraded mode: If an algorithm self-test fails, others can remain available, improving system resilience.

We selected Acumen Security as our FIPS lab partner for this effort and sincerely appreciate their professionalism and expertise throughout the validation process.

wolfCrypt’s FIPS-validated module can be used as a drop-in OpenSSL engine or provider, making it easy to integrate into existing applications. It’s ideally suited for embedded use cases like secure networking, medical devices, and industrial control systems.

Certificate #5041 offers all the same algorithms as certificate #4718, but will sunset on July 17, 2030. After that, continued use will require revalidation or transition to a newer certificate.

To learn more about FIPS 140-3 and the transition from 140-2, wolfSSL has published helpful resources:

• What is FIPS? (Short version)
• Differences between FIPS 140-2 and 140-3
• FIPS 140-3 Certificate #5041

For questions or integration support for FIPS, contact us at fips@wolfssl.com

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

What is 802.1AE?

802.1AE (MACsec) is a network layer 2 protocol for protecting ethernet frames with encryption and authentication across ethernet links. It introduces a new MACsec ethernet frame format, which carries an additional security tag (SecTAG) field inserted between the ethernet header and payload, as well as an integrity check value (ICV) trailer field at the end.

MACsec is built on the Galois/Counter Mode (GCM) construction, and uses AES-GCM to encrypt and integrity check ethernet payloads. It also supports an integrity-only mode of operation, where payloads are sent cleartext and GMAC is used for the ICV. It should be noted there is no “encrypt-only” MACsec mode, as integrity checks and origin authentication are fundamental to its design and choice of AES-GCM/GMAC.

Hop-by-hop vs end-to-end

The network topology of MACsec is fundamentally different from that of TLS or IPsec. MACsec protects data “hop-by-hop” along individual ethernet links, and does not have a concept of larger scale “end-to-end” protection as is the case between IP addresses in IPsec, or between network sockets in TLS.

There are benefits to this narrower scope. By protecting data only along individual ethernet links, there is no need to manage connection or session state across an entire network, which means latency is low. Also, the hop-by-hop scope allows for incremental deployment of MACsec, and utilization of device hardware acceleration along individual links.

This difference in scope means that MACsec is purely complementary to TLS and IPsec, and typically will be used in layered topologies (IPsec over MACsec, TLS over MACsec, etc). Furthermore, 802.1AE specifies nothing about key management and establishing MACsec, and typically will rely on higher level constructions such as EAP over TLS for provisioning.

Because MACsec happens hop-by-hop along ethernet links, it is typically implemented at a lower level by specialized devices and drivers: e.g. MACsec PHY hardware, or in the linux kernel as a specialized MACsec network driver. These will utilize hardware acceleration, and will have the added benefit of isolating key material to the device or kernel. The linux kernel is an especially interesting case that we’ll consider next.

MACsec in the linux kernel with wolfCrypt

The kernel MACsec driver itself does not contain any cryptographic implementations. Instead, it utilizes the kernel crypto API to allocate transforms for performing AES-GCM and GMAC on ethernet payloads. The kernel crypto API functions similar to a provider framework: different kernel modules register their cryptographic drivers, which in turn are used by device drivers for e.g. filesystem and network encryption. This makes sense, as cryptography in kernel-space has a number of strong advantages over user-space.

wolfSSL’s kernel module now supports registering wolfCrypt algorithms in the kernel crypto API (e.g. they will become listed in /proc/crypto). This means when kernel device drivers allocate cryptographic transforms for e.g. encrypted filesystems, IPsec, or MACsec, they are getting wolfCrypt’s registered implementations! In the case of wolfCrypt FIPS, one now has a very simple recipe for getting FIPS crypto into the linux kernel.

There are interesting possibilities with this. One could hypothetically have triple-layered network protection (TLS over IPsec over MACsec), with each utilizing wolfCrypt FIPS at different OSI layers!

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

As WireGuard continues to grow in popularity for its simplicity and efficiency in VPN deployments, security-conscious organizations are increasingly demanding solutions that adhere to stringent security standards, such as FIPS 140-3 or CMMC 2.0. FIPS certification is a key requirement for governmental agencies and industries like defense and healthcare, where secure cryptographic implementations are mandatory and or in spaces where CMMC 2.0 compliance is a must. However, WireGuard’s default cryptographic implementations, while highly secure, are not FIPS-certified.

This is where wolfCrypt steps in. wolfCrypt is a lightweight, portable, and highly optimized cryptographic library that offers FIPS 140-3 certification, making it an ideal partner for users seeking FIPS compliance in their WireGuard deployments.

wolfCrypt FIPS integrates seamlessly with both the C and Go implementations of WireGuard, offering developers flexibility in choosing their preferred solution. For those using the C version of WireGuard, wolfCrypt can also be directly employed in kernel space via the wolfSSL kernel module.

So by leveraging our integration, users can gain access to a VPN solution that is both secure and FIPS-compliant. The performance of WireGuard, combined with the certified cryptographic operations of wolfCrypt, ensures that you don’t sacrifice speed or security. In fact, with wolfCrypt’s ability to utilize hardware acceleration, you might end up with a much faster WireGuard. Additionally, wolfCrypt’s small footprint makes it a practical choice for deployments in constrained environments, including IoT devices, embedded systems, and edge computing setups. You get a robust, certified security layer without bogging down performance.

Are you interested in WireGuard with wolfCrypt FIPS?

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

Download wolfSSL Now

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