CRL vs OCSP: Secure Certificate Revocation with wolfSSL

Ensuring your TLS certificates are still valid and haven’t been revoked is critical for secure communications. Two methods exist for this:

Certificate Revocation Lists (CRLs) are signed lists published by Certificate Authorities that clients download and check offline. They contain serial numbers of revoked certificates and must be regularly updated and cached by clients to remain effective. CRLs are simple and privacy-friendly but can become large over time and may not reflect revocations in real-time, leaving a window of vulnerability between updates.

Online Certificate Status Protocol (OCSP) lets clients query a CA’s responder in real-time to check if a certificate is revoked. It provides up-to-date, on-demand validation with lower bandwidth than downloading full CRLs. However, it requires an active network connection and can introduce latency or privacy concerns if the client queries the CA directly. OCSP Stapling addresses these issues by allowing the server to “staple” a recent OCSP response to the TLS handshake, improving performance and protecting client privacy.

wolfSSL supports both CRL and OCSP checking, plus OCSP stapling, giving you flexible, layered certificate validation that fits any use case. Enable CRL support to verify certificates against cached revocation lists, and OCSP for live, up-to-the-minute status checks. Use both together for maximum security—CRLs handle offline or initial checks, and OCSP keeps your system aware of recent revocations.

In wolfSSL, enabling these features is straightforward:

// Enable and load CRL
wolfSSL_CTX_EnableCRL(ctx, WOLFSSL_CRL_CHECKALL);
wolfSSL_CTX_LoadCRL(ctx, "crl.pem", WOLFSSL_FILETYPE_PEM, 0);

// Enable OCSP checking and stapling
wolfSSL_CTX_EnableOCSP(ctx, WOLFSSL_OCSP_CHECKALL);
wolfSSL_CTX_EnableOCSPStapling(ctx);

Check out our manual for more information on these APIs:

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

Protect TLS Secrets After the Handshake — Only with wolfSSL

Most TLS libraries leave your certificates and private keys sitting in RAM long after they’re used — a jackpot for attackers with memory access. wolfSSL is the only TLS library that gives you the power to erase them completely with the wolfSSL_UnloadCertsKeys API. This function doesn’t just free memory — it securely zeroes out every byte of your sensitive data, ensuring nothing remains to be stolen.

From IoT devices and payment terminals to aerospace, automotive, and defense systems, wolfSSL_UnloadCertsKeys helps you meet the toughest security and compliance requirements. Combined with wolfSSL’s FIPS 140-3 validated cryptography, you get end-to-end protection: strong encryption for data in transit, and proactive memory sanitization for keys at rest in RAM. This synergy reduces your attack surface, thwarts memory dump attacks, and helps satisfy stringent standards like GDPR, HIPAA, and PCI DSS.

With wolfSSL, you’re not just encrypting traffic — you’re safeguarding the secrets behind it.

You can find more information on the wolfSSL_UnloadCertsKeys API in our manual.

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: An introduction to Stateful Hash-Based Signature Schemes

Unlock the Next Era of Cybersecurity with Stateful Hash-Based Signatures!

Join “An Introduction to Stateful Hash-Based Signature Schemes” on September 11 at 9:00 AM PT, presented by Senior Software Developer Anthony Hu. Learn the fundamentals of these quantum-resistant signatures and their role in securing long-lived systems.

Stateful hash-based signature schemes use one-time signatures and Merkle trees to ensure strong security, but require careful state management. Anthony will guide you through the core concepts and share practical considerations for implementation.

Register Now: An introduction to Stateful Hash-Based Signature Schemes
Date: September 11 | 9 AM PT
Duration: 60 Minutes

This webinar will cover:

  • CNSA 2.0 and the move to post-quantum cryptography
  • One-Time Signatures (OTS)
  • Merkle trees for scalability and security
  • State management and common pitfalls
  • Advanced topics and implementation tips

Register now to stay ahead in the post-quantum cybersecurity landscape.

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 +1 425 245 8247.

Download wolfSSL Now

Keystores and Secure Elements supported by wolfSSL

When looking to store your cryptographic secrets, it is important to have a good platform to store them on. Even more important is the ease of accessing and using those secrets.

With wolfTPM, we have support for all TPM 2.0 APIs. Additionally we provide the following wrappers:

  • Key Generation/Loading
  • RSA encrypt/decrypt
  • ECC sign/verify
  • ECDH
  • NV storage
  • Hashing/HMAC
  • AES
  • Sealing/Unsealing
  • Attestation
  • PCR Extend/Quote
  • Secure Root of Trust

Supported Platforms

In wolfTPM we already added support for the following platforms:

  • Raspberry Pi (Linux)
  • MMIO (Memory mapped IO)
  • MMIO (Memory mapped IO)
  • Atmel ASF
  • Xilinx (Ultrascale+ / Microblaze)
  • QNX
  • Infineon TriCore (TC2xx/TC3xx)
  • Barebox
  • Zephyr Project RTOS
  • U-Boot Bootloader
  • Microchip Harmony (MPLABX)

TPM 2.0 Modules

These TPM (Trusted Platform Module) 2.0 modules are tested and running in the field:

  • STM ST33TP* SPI/I2C
  • Infineon OPTIGA SLB9670/SLB9672/SLB9673
  • Microchip ATTPM20
  • Nations Tech Z32H330TC
  • Nuvoton NPCT650/NPCT750
  • Nations NS350

PKCS#11 Support

We have our own wolfPKCS11 with support for TPM 2.0 using wolfTPM. We also offer support for PKCS11 to interface to various HSMs like:

  • Infineon TriCore Aurix
  • Renesas RH850
  • ST SPC58

Direct Secure Element Access

For direct Secure Element access, we have ports in wolfSSL for:

Hardware Cryptographic Acceleration

Wolfcrypt has support for the following:

NXP Platforms

  • NXP CAAM (Cryptographic Acceleration and Assurance Module) on i.MX6 (QNX), i.MX8 (QNX/Linux), RT1170 FreeRTOS

Intel & ARM Security

Maxim Integrated

STM32 Platform Support

  • STM32MP135F – Complete hardware acceleration suite with STM32CubeIDE support, HAL support for SHA-2/SHA-3/AES/RNG/ECC optimizations
  • STM32H5 – Advanced performance microcontroller support
  • STM32WBA – Wireless connectivity focused platform
  • STM32G4 – General purpose microcontroller series
  • STM32U575xx – Ultra-low-power microcontroller boards
  • STM32 Cube Expansion Pack – Enhanced development support

Renesas Hardware Acceleration

  • Renesas TSIP – RSA Public Encrypt/Private Decrypt operations, AES-CTR mode support
  • Renesas SCE – RSA crypto-only support

Infineon Security Solutions

  • Infineon TriCore (TC2XX/TC3XX) – Hardware security module with TPM support
  • Infineon SLB9672/SLB9673 – Advanced TPM modules with firmware update capabilities
  • Infineon Modus Toolbox – Development environment integration
  • Infineon CyHal I2C/SPI – Hardware abstraction layer support

Development Board Support

  • Raspberry Pi RP2350 – Latest generation with enhanced RNG optimizations
  • Raspberry Pi RP2040 – Improved support with RNG optimizations
  • SiFive HiFive Unleashed Board – RISC-V development board support

Bootloader and OS Integration

  • U-Boot Bootloader – Secure boot integration with TPM support
  • Zephyr Project RTOS – Real-time operating system with TPM integration
  • Microchip Harmony (MPLABX) – Complete development ecosystem support

Advanced Features

  • Memory Mapped I/O (MMIO) TPMs – Direct memory access to TPM modules
  • Pre-provisioned Device Identity Keys – Support for manufacturer-provisioned security credentials
  • Firmware Update Support – Secure firmware update capabilities for supported TPM modules

For more detailed information on our supported hardware take a look at our Hardware Support list.

PSA (Platform Security Architecture)

Wolfcrypt also can make use of PSA (Platform Security Architecture). This includes the following algorithms:

  • Hashes: SHA-1, SHA-224, SHA-256
  • AES: AES-ECB, AES-CBC, AES-CTR, AES-GCM, AES-CCM
  • ECDH PK callbacks (P-256)
  • ECDSA PK callbacks (P-256)
  • RNG

wolfBoot Integration

Another product of interest could be wolfBoot, which – as the name suggests – is a bootloader that can use an HSM (Hardware Security Module) for validation and verification. It also provides secure vaults accessible via PKCS#11 API and secured through the ARM TrustZone technology. WolfBoot also supports all of the TPMs and secure elements listed above, as it inherits all of wolfCrypt’s capabilities. WolfBoot can also be combined with wolfTPM to implement measured boot.

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

Deprecation Notice: TLS 1.3 Draft 18

The wolfSSL team is deprecating the following:

  • WOLFSSL_TLS13_DRAFT preprocessor macro
  • –enable-tls13-draft18 configure option

These components were originally introduced during the TLS 1.3 standardization process to support interoperability with implementations based on Draft 18 of the TLS 1.3 specification. During the multi-year standardization process (2014-2018), multiple draft versions were published before the final RFC 8446 was released in August 2018.

The –enable-tls13-draft18 configure option currently has no functional effect in the codebase and serves no purpose.

The WOLFSSL_TLS13_DRAFT macro, when defined, modifies version number handling in TLS handshakes to use draft-specific version numbers (TLS_DRAFT_MAJOR = 0x7f) instead of the final TLS 1.3 version numbers. This was designed to maintain compatibility with implementations during the transition period which ended long ago.

Maintaining compatibility with obsolete specifications introduces unnecessary complexity. The TLS ecosystem has fully migrated to the TLS 1.3 standard. For these reasons, we are eliminating draft compatibility.

This decision is not yet final. If you think you need these configuration flags to be available, please reach out to us at support@wolfssl.com and let us know.

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

SLIM: Securing AI Agent Communication with MLS

As artificial intelligence continues to evolve and transform industries, here at wolfSSL we are closely monitoring developments in Agent to Agent communication protocols such as A2A and SLIM. We recently wrote our blog post “A2A and wolfSSL” talking about how it is secured via TLS.

One particularly interesting development in this space is SLIM (Secure Low-Latency Interactive Messaging), a communication framework designed specifically for AI agents. What makes SLIM especially noteworthy from a security perspective is its choice of security protocol: Message Layer Security (MLS).

SLIM represents a new approach to AI agent communication, built on the gRPC framework and designed to provide secure, scalable messaging between multiple AI agents. SLIM addresses the unique challenges of group-based AI interactions where multiple agents need to communicate securely and efficiently.

MLS (Message Layer Security) is a relatively new cryptographic protocol standardized in RFC 9420 (https://datatracker.ietf.org/doc/rfc9420/). MLS is specifically designed for secure group messaging scenarios, making it an ideal choice for AI agent communication where multiple participants need to exchange information securely.

MLS provides several key security features that make it well-suited for AI agent communication:

  • Quantum-safe end-to-end encryption ensures that communications between AI agents remain secure even against future quantum computing threats. MLS already incorporates ML-KEM and ML-DSA; NIST standardized post-quantum algorithms for key establishment and authentication.
  • Dynamic group membership management allows AI agents to join and leave communication groups seamlessly. This is particularly important in distributed AI systems where agents may come online and offline dynamically based on computational needs or system requirements.
  • The scalable key management system in MLS uses a tree-based structure that efficiently handles groups ranging from just a few agents to thousands of participants. This scalability is essential for large-scale AI deployments where numerous agents need to coordinate their activities.
  • Allows the use of FIPS 140-3 approved algorithms such as AES-GCM, ECDSA and ECDHE; well-established, modern cryptographic primitives.

At wolfSSL, we recognize the importance of MLS in the evolving landscape of secure communications. We are actively working on an MLS implementation and have detailed our progress in our recent blog post about how MLS is on track for broader adoption (https://www.wolfssl.com/mls-messaging-layer-security-is-on-track/). Notably, wolfSSL will be the first to bring post-quantum algorithm implementations to MLS and therefore to SLIM, ensuring that AI agent communication remains secure even in the face of future quantum computing threats. Our commitment to supporting emerging security protocols ensures that developers building the next generation of secure applications, including AI agent communication systems like SLIM, have access to robust, well-tested cryptographic implementations. Moreover, with our multiple FIPS 140-3 certificates, we can provide cryptographic implementations that are tested and trusted within the federal government.

While wolfSSL does not currently implement MLS itself, our ongoing work continues to move forward. Want to see this effort accelerated? The best way to raise the priority is to let us know you’re interested. Send a message to facts@wolfssl.com to register your interest in SLIM and MLS.

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

DICE Boot Chain Via wolfCrypt’s Minimal Binary Footprint

Device Identifier Composition Engine (DICE) represents a fairly simple approach to hardware-based device identity and secure boot. DICE creates Cryptographic Device Identities (CDIs) through a blockchain-like verification process, where each boot stage measures the next component and derives unique Compound Device Identifiers using the following formula:

CDI_n = HMAC(CDI_n-1, Hash(program))

CDI_0 = UDS

The formulas mean that each element of the bootchain cryptographically verifies the previous CDI and then generates its new CDI to be passed on to the next stage boot loader. Of course the initial CDI is not a CDI at all, but a UDS (Unique Device Secret). This could be supplied by a PUF (Physically Unclonable Function) but does not need to be; as long as it is unique. wolfHSM is an excellent platform to securely store and sign this secret data. The same process is recursively repeated up the bootchain.

This creates an immutable chain of trust from hardware root secrets through firmware verification, enabling remote attestation and secure key provisioning for IoT devices. The observant reader will note that this differs from a conventional boot chain in that it allows for firmware later in the bootchain to verify the integrity of all the entities in the bootchain before it. Normally, entities in the boot chain only verify software images AFTER them in the boot process.

The specification supports and allows for a plethora of algorithms, notably DICE-compatible algorithms including ECDSA P-256, SHA-256, and Hash DRBG, making it ideal for resource-constrained embedded systems. For system integrators who have minimal binary footprint requirements, wolfCrypt can be built for Bare Metal ARM to support these algorithms within 30KB.

wolfBoot serves as an ideal secure bootloader for DICE-enabled systems, providing memory-efficient firmware authentication and update capabilities. The bootloader’s minimalist design and tiny HAL API also provides secure firmware update mechanisms.

Beyond wolfBoot, custom bootloaders can leverage the same optimized cryptographic implementations to build DICE-compatible secure boot solutions tailored to specific hardware platforms and security requirements.

Are you interested in seeing this work as part of your DICE bootchain? There is no need to wait any longer! Send a message to facts@wolfssl.com to register your interest in DICE with our team and raise the priority in our roadmap for wolfBoot and wolfHSM!

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: Everything You Need to Know About Medical Device Cybersecurity – Tailored for the Asia-Pacific Time Zone

Elevate your cybersecurity strategy with proven solutions built for connected care.

Join us on September 4th at 5 PM PT / September 5th at 9 AM JST for a live webinar led by wolfSSL Senior Software Engineer Eric Blankenhorn. We’ll cover how to strengthen cybersecurity across the entire medical device ecosystem from implantables and patient monitors to bedside devices and cloud platforms. This session will highlight regulatory requirements, key security challenges, and how wolfSSL’s embedded solutions can help you address them.

Register now: Everything You Need to Know About Medical Device Cybersecurity
This webinar is tailored for the Asia-Pacific Time Zone
Date: September 4th | 5 PM PT / September 5th | 9 AM JST

In this webinar, Eric will dive into current cybersecurity threats in healthcare, industry trends, and the growing regulatory pressure on connected devices. Learn how wolfSSL’s lightweight, FIPS 140-3 validated cryptography and secure boot technology can help prevent tampering, conserve power, and support compliance with HIPAA, VA, and other mandates.

Register now to strengthen your security posture in connected healthcare.

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

Top 15 FIPS Terms You Should Know – The Full Breakdown

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

Top 15 FIPS Terms You Should Know

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

Posts navigation

1 2 3 4 5 6 211 212 213