What is FIPS? (Quick Overview)
Doing FIPS responsibly since 2014! The wolfCrypt module now holds the world’s first SP800-140Br1 FIPS 140-3 Validated Certificate #4718.
FIPS is a set of standards, detailed in Special Publications, that need to be met in order to be awarded a FIPS validation/certification published on the NIST website.
A FIPS certificate, with the product listed in the certificate, is required to sell product(s) to medical, federal or military agencies and often required by some private sector entities as well.
The typical FIPS certification process is as follows:
- You send us your hardware and toolchain
- We run the initial tests which ensure the cryptography module behaves according to specification given your specific hardware and OS
- The CMVP certified lab runs and verifies the tests and their documentation
- The test results are submitted to NIST for review
- Your specific operating environment is added to our certificate
- You are FIPS 140 compliant in 60-90 days
For more information, please see the ‘What is FIPS (In-Depth Overview)‘.
If you have any questions about FIPS or the process of being awarded a FIPS validation/certificate, please contact us at fips@wolfSSL.com or facts@wolfSSL.com, or + 1 425 245 8247. We offer free pre-sales customer support, we have FIPS evaluation options and our staff are knowledgeable and eager to help!
Download wolfSSL Now
Live Webinar: Reasons to migrate from OpenSSL to wolfSSL
If you’re looking for a superior alternative to OpenSSL that offers better support and a smoother workflow, wolfSSL is the solution you need. It not only addresses the gaps you may encounter with OpenSSL but also boasts the world’s first SP800 140Br1 FIPS 140-3 validated certificate (#4718) for its wolfCrypt module. Join our upcoming webinar, where wolfSSL senior software developer Anthony will highlight the benefits of transitioning to wolfSSL and show how choosing wolfSSL over OpenSSL can transform your projects.
Register Today: Reasons to migrate from OpenSSL to wolfSSL
Date: August 21st | 10 AM PT
During this webinar, Anthony will cover…
- Certified FIPS 140-3 Provider: wolfSSL is now FIPS 140-3 certified, ensuring the highest security standards.
- Support for the QUIC Protocol: Enhance your network performance with QUIC support (–enable-quic).
- Post-Quantum Integration: Stay ahead with post-quantum cryptography capabilities.
- Exceptional Support Services: Experience top-notch customer support and service.
Anthony will delve into what sets wolfSSL apart from OpenSSL, offering a comprehensive overview of the potential benefits for your projects. Don’t miss this opportunity to discover solutions that best fit your needs!
Seats are limited. Register now for this informative webinar!
As always, our webinars will include Q&A sessions throughout. If you have questions on any of the above, please contact us at facts@wolfssl.com or +1 425 245 8247.
Download wolfSSL Now
What is FIPS? (In-Depth Overview)
Doing FIPS responsibly since 2014!
The wolfCrypt module now holds the world’s first SP800-140Br1 FIPS 140-3 Validated Certificate #4718.
INTRO (wolfSSL FIPS service(s)):
(skip to next paragraph for “What is FIPS”)
FIPS is rightly viewed as a complex process with a steep entry learning curve. Lucky for customers of wolfSSL Inc. our management and engineering team have taken the time to learn the documentation surrounding the topic and developed all the tooling necessary to complete FIPS validation testing of the wolfCrypt cryptographic module in coordination with an NVLAP accredited FIPS lab. In order to FIPS validate a new product or operating environment (OE), wolfSSL asks for simply a customer’s hardware, compiler/toolchain (IDE etc), and a guide such that one of our FIPS developers can sit down with nothing but a laptop and achieve compiling and running a hello-world.c application on the target product to be FIPS validated. Yes you read that right, wolfSSL does not need your proprietary application software, just a hello-world.c application to get started. The CMVP validates the cryptographic module running on the target, not the applications that are consuming that cryptographic module. The wolfSSL team will standup the wolfCrypt module on your target product using your own tooling (Compiler, Linker, Assembler) and take it through the certification process as quickly as possible leaving your dev team free to focus on preparing the end product while FIPS certification is taking place simultaneously! At the end wolfSSL staff will deliver highly detailed instructions on re-creating the exact same FIPS approved binary from the source code we deliver given all work was completed with your own tooling in keeping with ISO/IEC 19790:2012 B.2.5 as applied to open source software.
HISTORY (What is FIPS):
Since there are so many options for securing information, the U.S. and Canadian governments recognized in the 1990’s a need to standardize those algorithmic methods deemed to be the most secure and enforce use of only those algorithms in critical government systems. To “encourage” adoption of the requirements by the two governments, the organizations NIST (National Institute of Standards and Technology)¹ and the CCCS (Canadian Centre for Cyber Security)² were called upon to fulfill that mission. The two agencies were to collaboratively:
- Decide which algorithms were the best/strongest
- Evaluate: If an algorithm had multiple modes or key lengths which modes or key lengths (if any) were considered too weak and should be excluded?
- Determine if there were other requirements aside from just having the algorithms implemented correctly
- Did the algorithms NEED to be re-tested periodically? (IE as the device was powering up)
- Did the module need to be checked periodically to see if it had been tampered with since the factory? (IE an integrity check, etc)
- Finally to enforce/encourage adoption of these standards by federal agencies belonging to either government. (Eventually expanded to include medical and some private entities as well)
These standards were called the “Federal Information Processing Standards” or FIPS. These standards were documented in a series of “Special Publications” (SP’s).
Out of a need to document which cryptographic modules and vendors were abiding by the standards set forth, a “certification” program was decided as the best approach. Vendors who made cryptographic modules could submit for and be awarded a certificate if their module was found to be compliant with all standards applicable to that module. The certificates would be hosted on the U.S. based NIST website so that federal agencies (or the public) could “browse” the available FIPS certified modules.
It was a big job for the two agencies to handle alone, so in 1995 NIST and CCCS established two organizations called the “CMVP” (Cryptographic Module Validation Program)³ and CAVP (Cryptographic Algorithm Validation Program)4 to handle testing Cryptographic modules for compliance with the standards. These two organizations would also handle issuing the certificates for vendors and products that passed algorithm testing and were found to meet all applicable standards outlined in the SP’s.
The CAVP issues algorithm certificates (which are a prerequisite to submitting a module for FIPS certification to the CMVP). The CMVP issues FIPS certificates for “tested configurations” or “operating environments” found to pass the CAVP testing and be in compliance with the standards. Both certificate types (CAVP algo certs and CMVP FIPS certs) are hosted on the NIST website. The certificates are public domain and can be searched by anyone.
Once established, the CMVP and CAVP needed to establish a way to “test” the modules. To that end they called upon the NVLAP (National Voluntary Laboratory Accreditation Program)5 to accredit “third-party” testing laboratories that would serve as an intermediary between the vendors seeking FIPS certification and the CAVP/CMVP bodies.
A last step in the history of FIPS was adoption of software modules. Originally when the standards were written, only dedicated hardware could perform the heavy lifting necessary for cryptographic mathematical operations so the standards were designed with ONLY hardware modules in mind. Doing cryptography in software at the time was impractical and therefore not considered in the original standards. As general purpose CPUs advanced, eventually it became feasible to implement algorithms in software and have those expensive math operations executed by a general purpose CPU in a reasonable amount of time. Once this reality arrived the standards were “adapted” to allow for both hardware and software modules. To this day there are “some scenarios” in the standards that only seem to make sense for hardware (See our blog post on vendor affirmation and how some software vendors are exploiting a loophole in the standards that was intended for hardware). NIST, the CMVP and CAVP have done a lot of work in the past few years bringing about the latest 140-3 standards. wolfSSL Inc. is thrilled to be the world’s first SP800-140Br1 FIPS 140-3 Validated, Certificate #4718, and one of the first software modules with a commercial FIPS 140-3 offering!
The Process (validating a module):
Today a hardware or software vendor will work in coordination with an NVLAP accredited lab to complete algorithm testing and receive algorithms certificates.
(Milestone 1 of a FIPS certification effort)
Once the vendor receives the prerequisite CAVP certificates they will perform operational testing with the same NVLAP accredited lab. Once all testing evidence has been captured and everything reviewed and approved by the NVLAP quality assurance department, the lab is ready to submit everything to the CMVP.
(Milestone 2 of a FIPS certification effort)
The CMVP will coordinate with the vendor via the NVLAP accredited lab and once all requirements have been satisfied the CMVP will either issue a new FIPS certificate or update an existing certificate if the vendor is adding an operating environment to an existing certificate.
(Milestone 3 of a FIPS certification effort)
Submission Scenario(s) supported by wolfSSL Inc:
- New cert (draw a new module boundary around specific algorithms and certify from scratch resulting in a new certificate)
- OE addition (Add an OE to an existing certificate)
- Revalidation (redraw the module boundary of an existing validated module to include new or remove existing algorithms from the boundary description)
- Vendor Affirmation – wolfSSL is a software module vendor. As a responsible FIPS vendor wolfSSL feels that software vendors are generally incapable of determining how a change to the CPU or OS will affect the cryptography (especially if the CPU or OS changes completely). As such wolfSSL Inc does not currently offer Vendor Affirmation as a path to FIPS. Special circumstances MAY exist but would need to be evaluated on a case-by-case basis.
Timeline estimates for the various scenarios change over time. If you would like an up-to-date estimate for a given submission scenario please contact support@wolfssl.com for the latest.
Summary:
- wolfSSL Inc can make the process of certifying your product painless and hands-free once we have the product and basic instructions for getting a hello-world app up and running on the target!
- FIPS is a set of standards, detailed in Special Publications, that need to be met in order to be awarded a FIPS validation/certification published on the NIST website. A FIPS certificate, with the product listed in the certificate, is required to sell product(s) to medical, federal or military agencies and often required by some private sector entities as well.
- The process can take time so please plan accordingly!
If you have any other questions about FIPS or the process or wolfSSL Inc please contact either fips@wolfSSL.com or support@wolfSSL.com anytime. We offer free pre-sales customer support, we have FIPS evaluation options and our staff are knowledgeable and eager to help!
¹ The National Institute of Standards and Technology (NIST) was founded in 1901 and is now part of the U.S. Department of Commerce. NIST is one of the nation’s oldest physical science laboratories. To promote U.S. innovation and industrial competitiveness by advancing measurement science, standards, and technology in ways that enhance economic security and improve our quality of life. – https://www.nist.gov/about-nist
² The Cyber Centre is the single unified source of expert advice, guidance, services and support on cyber security for government, critical infrastructure owners and operations, the private sector and the Canadian public. – https://www.cyber.gc.ca/en/about-cyber-centre
³ The Cryptographic Module Validation Program (CMVP) is a joint effort between the National Institute of Standards and Technology under the Department of Commerce and the Canadian Centre for Cyber Security, a branch of the Communications Security Establishment. The goal of the CMVP is to promote the use of validated cryptographic modules and provide Federal agencies with a security metric to use in procuring equipment containing validated cryptographic modules. – https://csrc.nist.gov/Projects/Cryptographic-Module-Validation-Program
4 The CAVP was established in July 1995 by NIST and the Government of Canada’s CCCS. CSD’s Security Testing, Validation, and Measurement Group (STVMG) manages the validation testing of cryptographic modules and their underlying cryptographic algorithms through the CAVP and CMVP. – https://csrc.nist.gov/Projects/Cryptographic-Algorithm-Validation-Program
5 The National Voluntary Laboratory Accreditation Program (NVLAP) provides third-party accreditation to testing and calibration laboratories in response to legislative actions or requests from government agencies or private-sector organizations. NVLAP-accredited laboratories are assessed against the management and technical requirements published in the International Standard, ISO/IEC 17025:2017. – https://www.nist.gov/nvlap
If you have questions about any of the above, please contact us at facts@wolfSSL.com or +1 425 245 8247.
Download wolfSSL Now
wolfSSL Invited to the White House Post-Quantum Standards Announcement
Our very own Tim Pickering was in attendance today when White House officials announced that the standards for post-quantum algorithms were no longer in draft mode. They are now fully empowered as standard algorithms and endorsed by the US Federal Government.
What was standardized today?
Here at wolfSSL we’ve been anticipating this moment for a very long time. We already have our own implementations of ML-KEM and ML-DSA and have them integrated with several protocols such as TLS 1.3, DTLS 1.3, SSH and MQTT. We have demoed these new algorithms with many open source projects such as cURL, Apache-httpd, nginx, lighttpd, and stunnel.
Read the newly minted standards documents that are linked above for more details. Reach out to us if you’d like more information about our implementations of these new standards!
If you have questions about any of the above, please contact us at facts@wolfSSL.com or +1 424 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/HACM
- AES
- Sealing/Unsealing
- Attestation
- PCR Extend/Quote
- Secure Root of Trust
In wolfTPM we already added support for the following platforms:
- Raspberry Pi (Linux)
- MMIO (Memory mapped IO)
- STM32 with CubeMX
- Atmel ASF
- Xilinx (Ultrascale+ / Microblaze)
- QNX
- Infineon TriCore (TC2xx/TC3xx)
- Barebox
These TPM (Trusted Platform Module) 2.0 modules are tested and running in the field:
- STM ST33TP* SPI/I2C
- Infineon OPTIGA SLB9670/SLB9672
- Microchip ATTPM20
- Nations Tech Z32H330TC
- Nuvoton NPCT650/NPCT750
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
For direct Secure Element access, we have ports in wolfSSL for:
Wolfcrypt has support for the following:
- NXP CAAM (Cryptographic Acceleration and Assurance Module) on i.MX6 (QNX), i.MX8 (QNX/Linux), RT1170 FreeRTOS
- Intel SGX
- ARM TrustZone CryptoCell 310
- MAXQ1065/1080 RNG
- MAX32665 and MAX32666 TPU (Trust Protection Unit)
For more detailed information on our supported hardware take a look at our Hardware Support list.
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
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, please feel free to contact us at facts@wolfSSL.com or +1 425 245 8247, or view our FAQ page.
Download wolfSSL Now
wolfSSL Invited to the White House Post-Quantum Standards Announcement
Our very own Tim Pickering was in attendance today when White House officials announced that the standards for post-quantum algorithms were no longer in draft mode. They are now fully empowered as standard algorithms and endorsed by the US Federal Government.
What was standardized today?
Here at wolfSSL we’ve been anticipating this moment for a very long time. We already have our own implementations of ML-KEM and ML-DSA and have them integrated with several protocols such as TLS 1.3, DTLS 1.3, SSH and MQTT. We have demoed these new algorithms with many open source projects such as cURL, Apache-httpd, nginx, lighttpd, and stunnel.
Read the newly minted standards documents that are linked above for more details. Reach out to us if you’d like more information about our implementations of these new standards!
If you have questions about any of the above, please contact us at facts@wolfSSL.com or +1 424 245 8247.
Download wolfSSL Now
How do you benchmark cryptography?
There are many different metrics that can be used when benchmarking cryptography. The common metrics are; average time per operation, average amount of data processed per unit of time, and number of clock cycles taken per data processed.
The first metric of average time per operation, is used with asymmetric key algorithms. These are algorithms that have a public and a private key pair and are doing operations such as signing, verifying, or creating a shared secret key where the input and output data of the operation is a constant size. In wolfSSL, the signature creation and verification operations for RSA and ECC can be benchmarked with the bundled benchmark application using the following command:
`./wolfcrypt/benchmark/benchmark -rsa -ecc`
The last two metrics of average amount of data processed per unit of time (often MB/s, megabytes per second) and number of clock cycles per byte processed are used with symmetric key algorithms. These are algorithms such as AES or ChaCha20 where the key used for encryption should be the same as decryption and the input / output sizes are dependent on the amount of data passed in by the user. When using hardware acceleration created specifically for crypto operations the cycles per byte can even dip below 1. That is – more than one byte of input data processed (encrypted or decrypted) in the time it took for one clock cycle with the CPU! An example of benchmarking AES and ChaCha20 would be the following command:
`./wolfcrypt/benchmark/benchmark -aes-gcm -chacha20`
There are many options available with the wolfSSL benchmark application. All of the options can be seen by using the flag -h `./wolfcrypt/benchmark/benchmark -h`. A couple of the flags that are of note are -base10 and -csv. The flag -base10 uses 1000 bytes as a kilobyte (instead of 1024 which is the default with wolfSSL, aka KiB) and can be used when comparing performance with OpenSSL which defaults to treating 1000 bytes as a kilobyte. Benchmark performance also is very dependent on the hardware that it is run on. The wolfSSL benchmarks page has performance of wolfSSL crypto operations on various hardware platforms.
For questions about setting up wolfSSL to be as fast as possible on your platform, or for inquiries about any of the above, please contact us at facts@wolfssl.com or +1 425 245 8247.
Download wolfSSL Now
Live Webinar: Getting Started with libcurl
Join us for an insightful live webinar with Daniel Stenberg, the founder and lead developer of curl and libcurl, on August 15th at 10 am PT. Daniel will present “Getting Started with libcurl” for all skill levels.
In this session, Daniel will delve into the core concepts and best practices of libcurl, the widely known client-side URL transfer library. libcurl is recognized for its user-friendliness and support for numerous protocols, including HTTP/3, cookies, DICT, FILE, FTP, and FTPS, ensuring compatibility across almost all platforms.
Register today: Getting Started with libcurl
Here’s a sneak peek of what the webinar will cover:
- Basic knowledge of libcurl
- Best practices for Synchronous Transfer
- Extracting information from transfers, properly receiving and uploading data
- Concurrent transfer methods
- URL parser
Don’t miss this chance to refresh your knowledge or learn new skills directly from the creator of libcurl. Enhance your expertise and strengthen your toolkit with libcurl training! Embark on a rewarding journey with libcurl. Register now!
Duration: 60minutes
As always, our webinars include Q&A sessions. If you have questions about any of the above, please contact us at facts@wolfSSL.com or +1 425 245 8247.
Download wolfSSL Now
CNSA 2.0 Update Part 5: PSK
On April 18th, 2024, the NSA released updates and clarifications to their CNSA 2.0 (Commercial National Security Algorithm Suite 2.0) advisory in the form of an FAQ. This is the fifth and final in a series of postings about the questions and answers that we feel are most interesting and our reactions to them.
Q: Can I mitigate the quantum threat by using a pre-shared key?
A: Many commercial protocols allow a pre-shared key option that may mitigate the quantum threat, and some allow the combination of pre-shared and asymmetric keys in the same negotiation. However, this issue can be complex. Customers who wish to explore this option should contact NSA or follow guidance the CSfC program provides.
This is great news for our customers as this means they can enable our PSK (pre-shared key) support in wolfSSL and start their post-quantum journey today! If you’re using Sneakernet (avoiding network transmission) then you’re golden! The knowledge of the pre-shared key takes care of both authentication and key establishment so there is no need for public key cryptography and therefore thwarts Shor’s algorithm.
That said, the NSA is correct, this issue is complicated. Here are just a few points to think about:
- How is the key shared? If it was sent over a data connection that was negotiated with non-quantum-safe algorithms, then this is not considered mitigating the quantum threat.
- How is the key generated? If it was done using an entropy source and/or PRNG (Pseudo-Random Number Generator) that is not approved then you are going to run into problems.
- Do you require PFS (Perfect Forward Secrecy)? Then you might have to think about how you’re going to achieve that very carefully.
- How are you storing and protecting the pre-shared keys? If your efforts to protect it are insufficient then you leave yourself vulnerable to other attack vectors.
Most people are not aware that this can even apply to our wolfBoot product. The signing tool in wolfBoot has a –encrypt SHAREDKEY.BIN flag that allows you to use a pre-shared key to encrypt the firmware image. On the device at boot time, as long as the shared key is stored in a secure manner (ie TPM, secure element) then it can be used to decrypt the firmware image.
Let our experts help you sort out these details. Get started on your journey into a world with quantum computers by downloading wolfSSL now.
If you have questions about any of the above, please contact us at facts@wolfSSL.com or call us at +1 425 245 8247.
Check out our CNSA 2.0 Update Blog Series!
- CNSA 2.0 Update Part 1: Today!
- CNSA 2.0 Update Part 2: NIAP
- CNSA 2.0 Update Part 3: LMS and XMSS
- CNSA 2.0 Update Part 4: Deployment
Download wolfSSL Now
CNSA 2.0 Update Part 4: Deployment
On April 18th, 2024, the NSA released updates and clarifications to their CNSA 2.0 (Commercial National Security Algorithm Suite 2.0) advisory in the form of an FAQ. This is the fourth in a multipart series of postings about the questions and answers that we feel are most interesting and our reactions to them.
Q: When should deployment of CNSA 2.0 algorithms in mission systems begin?
A: When validated products become available they should be deployed in mission systems. Meanwhile, NSA encourages responsible testing in vendor and government research environments now to understand the effects of deployment of the new algorithms on particular systems given the increased sizes used in these algorithms.
Translation: time to “get cracking” and build post-quantum cryptographic implementations you plan to use. You need to understand that while performance for Kyber/ML-KEM won’t be an issue, (see our benchmarks) artifact sizes are increasing!
If you are used to the tiny artifacts in ECDHE then this should be a real eye opener. We’re talking kilobytes going over the wire and taking up memory.
How will this affect you? First of all, if your transmission medium is slow then more bytes going over the wire during the protocol handshake will naturally increase the time to your first application data being sent. Secondly, if your current application is already memory constrained, you might need to re-evaluate how you use your memory or even increase the amount of memory available to your application.
What about your boot loaders that do firmware verification? The best options for quantum-readiness are the stateful hash-based signature schemes LMS and XMSS. Due to the state management requirement, all signing must be done in an HSM to be compliant. Do you already have that infrastructure in place? If not, now is the time to get started thinking about how this requirement is going to affect your processes. For the verification side, have a look at our wolfBoot product!
Considering these things takes time and planning, now is the time to start! Download now.
If you have questions about any of the above, please contact us at facts@wolfSSL.com or call us at +1 425 245 8247.
Catch up on CNSA 2.0 Update Part 1, Part 2 and Part 3! Stay tuned for the final part of the series.
Download wolfSSL Now