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
wolfSSL on Altera’s Cyclone V SoC FPGA
The Cyclone V, a cost-effective System-on-Chip (SoC) FPGA from Altera, combines a dual-core ARM Cortex-A9 processor (Hard Processor System, HPS) with a range of FPGA fabric configurations, tailored to specific family SKUs.
It can be used with a variety of Real-Time Operating Systems (RTOS), including VxWorks, FreeRTOS, and Azure RTOS, as well as embedded Linux distributions like Yocto and Buildroot. wolfSSL is optimized for these platforms, offering secure communication with TLS v1.3 and DTLS v1.3, secure boot capabilities with wolfBoot, and FIPS 140-3 cryptography. It can fully replace cryptographic operations in embedded Linux, providing a comprehensive FIPS-approved solution for both user space and kernel space.
Additionally, wolfSSL can provide a Hardware Security Module (HSM) solution with wolfHSM on the Cyclone V. By leveraging the Nios II or RISC-V-based Nios V soft-core processor in the FPGA fabric, wolfHSM can be used to provide a dedicated fabric based security module for the Cyclone V.
Cyclone V Cortex-A9 @ 800 MHz on Yocto Linux Scarthgap Benchmarks
Benchmarks are collected from our public benchmarking tool and compiled with -O2 optimization for both the benchmarking app and wolfSSL library. C benchmarking results are collected using a standard ./configure build of the wolfSSL library, and ARM Assembly results benchmarks are collected with a ./configure –enable-armasm build of the library.
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
CMMC 2.0, NIST 800-171, FIPS 140-3, CUI, FCI and DIB
This post will be about what all these acronyms mean, how they are all related to each other and the purpose they serve. Let’s begin with a few definitions:
- CMMC 2.0 – Cybersecurity Maturity Model Certification: A set of cybersecurity best practices and assessments mandated by the US federal government.
- NIST 800-171: A NIST special publication titled “Protecting Controlled Unclassified Information in Nonfederal Systems and Organizations”. It gives guidance to commercial entities that are handling data on behalf of the US federal government.
- FIPS 140-3: federal Information Processing Standard 140-3; a NIST standard and certification regime that specifies requirements for cryptographic modules.
- CUI: Controlled Unclassified Information; sensitive information used by the US federal government but is not considered classified. Examples include personal identification information such as social security numbers, medical records and tax records.
- FCI: Federal Contract Information; non-public data generated by or for the US federal government under contract and protected under confidentiality guarantees. Examples include statements of work and internal process documentation.
- DIB: Defence Industrial Base; the collection of commercial entities that works together with the US federal government to perform research and development of defense technologies and systems to strengthen national security.
CMMC 2.0 is a model designed to use the guidance in NIST 800-171 to get DIB entities to enact a set of practices and assessments that achieve standard levels of cybersecurity maturity. This model and these practices apply to CUI and FCI when at rest and during transmission. The cryptographic modules used as part of these practices to protect the CUI and FCI are certified under the FIPS 140-3 program.
It is important to note that the CMMC 2.0 model includes assessments, audits and certifications that are done both internally by an entity as well as by independent 3rd party auditors and labs. For example, cryptographic modules are certified by NIST’s CMVP (Cryptographic Module Validation Program) under FIPS 140-3.
Do you have CMMC 2.0 requirements? Were you confused about CMMC 2.0 before reading this post? Feeling better? Good!
Here at wolfSSL, we want you to understand that if CMMC 2.0 applies to you, we can help you with your FIPS 140-3 requirements. Our wolfCrypt library is already certified under FIPS 140-3 with a 5-year validity window. Send a message to facts@wolfssl.com or fips@wolfssl.com to find out how we can help.
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