Category: Uncategorized

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

wolfMQTT: Using wolfCrypts implementation of ML-KEM and ML-DSA

A long time ago, we added support for Kyber and Falcon in wolfMQTT. That support used an integration into liboqs for the Kyber and Falcon implementation.

Things have changed since then! Kyber is no longer Kyber, it is now ML-KEM. Falcon will soon become FN-DSA, but since then rock solid standards for ML-DSA have been released so a strong focus within the industry has been put on it. And now, wolfCrypt has its very own implementations of ML-KEM and ML-DSA.

As such, very recently, we updated our instructions for wolfMQTT to show how to do an interoperability demo against the OQS’s port of Mosquitto on top of OpenSSL3 and the OQS provider. The interoperability demo shows the Mosquitto broker and subscriber listening to the wolfMQTT publisher. Check out the the very simple and easy to follow instructions.

Please go ahead and try it out for yourself!

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

OpenSSL Compatibility Layer Additions in wolfSSL 5.8.2

The wolfSSL’s repo pull request #8897 adds significant OpenSSL compatibility layer enhancements across four key areas: RSA operations, big number mathematics, X.509 certificate extensions, and private key serialization.

RSA API Enhancements:

The PR introduces comprehensive RSA-PSS (Probabilistic Signature Scheme) support with enhanced OpenSSL compatibility. Key additions include:

  • wolfSSL_EVP_PKEY_CTX_set_rsa_pss_saltlen() for configuring salt lengths
  • wolfSSL_EVP_PKEY_CTX_set_rsa_mgf1_md() for setting MGF1 hash algorithms
  • wolfSSL_EVP_PKEY_CTX_set_rsa_oaep_md() for RSA-OAEP padding configuration
  • The existing wolfSSL_RSA_sign and wolfSSL_RSA_verify functions have been enhanced to support RSA-PSS with custom salt lengths and MGF1 hash types.
  • Additional functions include wolfSSL_RSA_padding_add_PKCS1_PSS_mgf1() and wolfSSL_RSA_verify_PKCS1_PSS_mgf1() for advanced PSS padding operations with MGF1 support.

Bignum API Additions:

A new wolfSSL_BN_ucmp() function has been added that compares the absolute values of two WOLFSSL_BIGNUM structures. This function provides OpenSSL-compatible behavior identical to BN_ucmp(). The implementation uses internal duplication to avoid modifying const input parameters, making the implementation compliant with the API.

X.509 Extensions API Additions:

Two X.509 certificate extension handling functions have been added. The wolfSSL_X509v3_get_ext_by_NID() function searches for extensions by their Numeric Identifier (NID) within a stack of extensions, supporting iterative searching with a “lastpos” parameter. The wolfSSL_X509v3_get_ext() function retrieves extensions by index position from an extension stack. Both functions enable programmatic certificate extension processing for PKI applications, policy enforcement, and extension data extraction.

Private Key DER Output API Additions:

The new wolfSSL_i2d_PrivateKey_bio() function provides private key serialization to DER format through BIO objects. This function performs a two-pass operation to determine buffer size and encode the key.

These additions collectively enhance wolfSSL’s OpenSSL compatibility layer, providing essential functionality for RSA-PSS operations, mathematical computations, certificate processing, and key management operations required by modern cryptographic applications.

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: WolfGuard: FIPS 140-3 Enabled WireGuard

WireGuard is known for its simplicity, speed, and modern cryptography, but what if your deployment requires FIPS 140-3 validated security? That’s where WolfGuard comes in.

Join wolfSSL Software Engineer Lealem Amedie as he introduces WolfGuard, a FIPS 140-3 enabled WireGuard solution optimized for speed and cryptographic agility. Built on the FIPS-certified wolfCrypt library, WolfGuard delivers all of WireGuard’s functionality with the assurance of FIPS-approved algorithms.

Register now: WolfGuard: FIPS 140-3 Enabled WireGuard
Date: August 27th | 9 AM PT

This webinar will cover:

  • WireGuard fundamentals and implementations (Linux, GO, BoringTun)
  • How WireGuard secures tunnels and encrypts data
  • FIPS 140-3, FedRAMP, and CMMC 2.0 compliance needs
  • How WolfGuard integrates FIPS into WireGuard with zero architectural changes
  • Real-world use cases + live demo with WolfGuard Go

If you need WireGuard with FIPS 140-3 compliance and zero complexity trade-offs, WolfGuard is your solution.

Register now to see WolfGuard in action and achieve compliance in your VPN deployments.

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 425 8247.

Download wolfSSL Now

How to Make Your TPM Talk PKCS11

TPM vs HSM, what’s the difference? Check out this blog post for more detailed.

In a nutshell, TPMs are typically a dedicated chip included along side a main (host) processor and used for securing a single consumer electronics device. HSMs are external devices that can be used across multiple devices and systems, offering advanced cryptographic operations and key management. For both of them, their main objective is to protect and store private key material. A TPM typically presents itself via the standardized TPM 2.0 API while an HSM presents itself via the standardized PKCS11 API.

If you think about it really, really carefully, the difference is just a matter of form factor, interfaces, and regulatory technicalities. So is it possible for a TPM to present itself as an HSM? The answer is most definitely YES! But how?

Here at wolfSSL we have our own PKCS11 provider library, wolfPKCS11, to leverage cryptographic hardware and keystores on various systems. A while ago, we added support for using TPM 2.0 modules via wolfTPM into wolfPKCS11. We believe that this functionality is particularly useful for users that have coded to the PKCS11 standard, but need to switch to a TPM or fTPM; there are many technical and business reasons to do so.

With that in mind, if you have been using an HSM and want to simplify to simply using a TPM with little to no code changes in your application, let us help you with that. Reach out to us to find out how your specific situation would work!

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’s Newest Offering for the Financial Vertical

Are you wondering what Microsoft’s roadmap for the IIS (Internet Information Services) webserver says about post-quantum cryptography? We’re not; read on to find out why.

Not everyone in the financial industry is old enough to remember what it was like to be in the trenches during the Y2K (Year 2000) era, but those that were around for it know that it was expensive both in dollar and human terms. Many dollars and man hours were spent converting years from two digits to four digits. In the end the endeavor to fix the Y2K bug was a victim of its own success. When January 1st, 2000 rolled around, everyone was fine and the financial system just went along all honky dory.

We here at wolfSSL are hoping for the same fate for Y2Q (Years To Quantum). Hopefully, when a cryptographically relevant quantum computer is finally built, everyone will have switched over to post-quantum algorithms. To ensure this is the case, we here at wolfSSL have been hard at work getting ahead of the curve.

That said, we feel your pain. We know that you’ve been conservatively using Microsoft products. Why wouldn’t you; who doesn’t trust Microsoft? Microsoft’s approach has been to prioritize stability over agility which makes sense for now. But you also know that there are timelines to move to post-quantum cryptography. So what are your options?

At wolfSSL, we are currently working on a product that is so new that it does not even have a name!! It will act as an alternative to Microsoft Windows SChannel Library. It will hook into the windows SSPI (Security Support Provider Interface). Why is this important? Because this is how network security is provided to the Windows IIS Webserver. Without even knowing it, IIS will seamlessly become quantum-safe when you pop in wolfSSL’s alternative to SChannel!

Let us know what you think of the concept around this new product. Are you interested in seeing the timeline accelerated and the priority raised? Let us know by reaching out to facts@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

MCP (Model Context Protocol) and FIPS-140-3 Requirements

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:

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

Posts navigation

1 2 3 4 … 208 209 210