What is FIPS (long version)

Doing FIPS responsibly since 2014!

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 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!

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:

  1. Decide which algorithms were the best/strongest
  2. 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?
  3. Determine if there were other requirements aside from just having the algorithms implemented correctly
    1. Did the algorithms NEED to be re-tested periodically? (IE as the device was powering up)
    2. Did the module need to be checked periodically to see if it had been tampered with since the factory? (IE an integrity check, etc)
  4. 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)? 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)? 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 and wolfSSL Inc is very excited to be 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

? 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 

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 any questions or run into any issues, contact us at facts@wolfssl.com, or call us at +1 425 245 8247.

What is FIPS (short version)

Doing FIPS responsibly since 2014!

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:

  1. You send us your hardware and toolchain
  2. We run the initial tests which ensure the cryptography module behaves according to specification given your specific hardware and OS
  3. The CMVP certified lab runs and verifies the tests and their documentation
  4. The test results are submitted to NIST for review
  5. Your specific operating environment is added to our certificate
  6. You are FIPS 140 compliant in 60-90 days 

For more info please see the long version of this post here: <https://www.wolfssl.com/fips-long-version/>

If you have any questions or run into any issues, contact us at facts@wolfssl.com, or call us at +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!

The NSA Announces CNSA Suite 2.0

Recently, we have been hearing a lot about the (National Security Agency) NSA’s new (Commercial National Security Algorithm) CNSA Suite 2.0. The document was released in September of 2022 and can be found here. Likely, you have been hearing about it as well so we thought it might be a good idea to point out some interesting details.

The document focuses on notifying parties involved in National Security Systems (NSS) – such as vendors like you – that new requirements are coming. These requirements mandate a shift to quantum-resistant (also known as post-quantum) algorithms and the deprecation of legacy algorithms (ie RSA, DH, ECC). What does this mean for you?

It means that if you are making niche equipment for the NSS, you will need to switch to supporting post-quantum algorithms by 2030 and then only supporting them exclusively by 2033. The CNSA Suite 2.0 does allow for usage of legacy algorithms as a component of a hybrid solution, but their use alone will become unapproved. This is a very big change and wolfSSL is here to support you through this transition.

The document mentions the following algorithms; we have added our current support status for these algorithms beside each one:

  • AES-256 – (Supported. Have our own implementation.)
  • SHA-384 – (Supported. Have our own implementation.)
  • SHA-512 – (Supported. Have our own implementation.)
  • CRYSTALS-Kyber Level 5 – (Supported via integration with liboqs, PQM4 AND currently working on our own implementation.)
  • CRYSTALS-Dithium Level 5 – (Supported via integration with liboqs.)
  • LMS all variants – (Not supported yet.)
  • XMSS all variants – (Not supported yet.)

It is important to note that the transition dates mentioned above are for vendors that deal with the US government. Are you further down the supply chain? If so, then your customers need you to be ready even earlier as they will need time to develop their solutions. Don’t get caught unprepared!

Want to learn more about post-quantum cryptography? Want to try experimenting with these algorithms in TLS, SSH or MQTT? Looking to better understand our plans around LMS and XMSS? If you have any questions or run into any issues, contact us at facts@wolfssl.com, or call us at +1 425 245 8247.

wolfSSL 5.5.1 Release

wolfSSL 5.5.1 is released! wolfSSL 5.5.1 contains some fixes, feature additions, and one vulnerability fix. 

The vulnerability fix in this minor release was thanks to a report from Max at the trail of bits, and the team working on tlspuffin. It involved TLS 1.3 on the server side with –enable-session-tickets turned on. Our recommendation is that users always try to stay up to date with the latest releases, if using TLS 1.3 on the server side and having –enable-session-tickets enabled when building wolfSSL, users should update the version of wolfSSL.

This minor release also saw the addition of sphincs and kyber, two post quantum algorithms. Non blocking ECC in the TLS layer support was added, performance optimizations for use on ARMv7 among other architectures, along with porting work for use with the NXP RT685 board. 

A full list of changes can be found in the bundled ChangeLog.md or on our website here https://www.wolfssl.com/docs/wolfssl-changelog/.

If you have any questions or run into any issues, contact us at facts@wolfssl.com, or call us at +1 425 245 8247.

Next Level Interop Testing in QUIC

As TrueNuff.tv demonstrated in their “Does it blend?” series, by using a blender you will find out what things are really made of. Inspired by this, wolfSSL sponsored a new QUIC related test suite for the ngtcp2 project. What does it do and how does it help you in using wolfSSL?

Ngtcp2 is the leading open source QUIC implementation. We added wolfSSL support to it, as covered in our blog. Next to wolfSSL, most other TLS/SSL libraries are also supported: the quictls fork of OpenSSL, BoringSSL, GnuTLS, picotls. Libressl is expected to join soon. (OpenSSL itself is missing and is not expected to play a role in QUIC for the foreseeable future. We covered that in the mentioned blog post.)

What you as a user of wolfSSL are most interested in is not only that you get state-of-the-art TLS, but that it communicates correctly and efficiently with all the other TLS libraries out there. Now and for all future releases coming. 

QUIC’s use of TLS is very similar to TCP, but there are some differences. By testing TLS libraries against each other in the context of QUIC, we can verify not only interop for QUIC itself, but stress combinations of features and configurations that are used in “normal” TLS connections as well.

The Blender

The ngtcp2 test suite has become part of ngtcp2 itself. It is added to its CI on github, so all future development and new releases – of wolfSSL and all other TLS implementations – are always verified.

You can run this yourself. On ngtcp2’s github are the instructions to checkout and build it yourself. The new test suite has its own README, explaining how to use it. The test suite is based on Python’s pytest and should run on all platforms that support it.

There are “examples” server and client executables in ngtcp2, one for each TLS library that you configured. Should you only configure `–with-wolfssl`, only the wolfSSL server and client are built. The test suite then verifies in various scenarios that they interoperate.

If you configure more TLS libraries in ngtcp2, say `–with-wolfssl –with-openssl`, then you get two servers and two clients. The tests then try all possible combinations: wolfssl-wolfssl, openssl-openssl, openssl-wolfssl and wolfssl-openssl. Meaning, you do not need all the TLS libraries to run the blender on your machine.

Should you develop your own QUIC application, the test suite is an excellent place to verify it. It runs executables against each other. It is fairly straightforward to modify it for your own purposes.

We are, for example, currently considering how to use it for testing curl, the swiss army knife for internet transfers, sponsored by wolfSSL. We added wolfSSL QUIC support in curl, using ngtcp2, and the test coverage there needs to be extended as well.

For All

We think by donating this test suite to the ngtcp2 project, it’ll serve everyone best. We could have made it part of wolfSSL’s CI suites, but that would be a barrier for other TLS projects to pick it up. Also, should interop problems arise, let’s say between GnuTLS and BoringSSL, we do not really want to be involved in resolving it.

This aspect of OSS where things can be added and stay accessible where they make most sense is a real strength. We are happy to contribute.

If you have any questions or run into any issues, contact us at facts@wolfssl.com, or call us at +1 425 245 8247.

wolfCLU 0.1.0 Release

wolfCLU 0.1.0 is available! wolfCLU is the wolfSSL’s Command Line Utility and is meant to be used for simple key generation, certificate operations, encryption, and more. It is also being developed to be an alternative for the commonly used OpenSSL command line utility. In addition to supporting platforms like Windows and FreeRTOS, there were vast feature enhancements over the last release. Support for several new flags were added in.

  • s_client : -CAfile and -verify_return_error
  • verify : -partial_chain
  • enc : -pass
  • crl : -text
  • req : -passout
  • x509 : -modulus

This release also included several fixes. A running list of changes can be found in the bundled ChangeLog.md. Visit our download page or https://github.com/wolfssl/wolfclu for downloading the bundle. If you have any questions or run into any issues, contact us at facts@wolfssl.com, or call us at +1 425 245 8247.

wolfMQTT Release v1.14.1

The fall release of wolfMQTT, v1.14.1, is now available! This is a point release that updates support for the vcpkg integration:

  • Fix cmake builds #307
  • Fix for Vcpkg on Windows not getting wolfssl/options.h included #305

The Microsoft vcpkg project allows applications to easily build, use, and update C libraries. 

You can download and install wolfMQTT using vcpkg:

git clone https://github.com/Microsoft/vcpkg.git
cd vcpkg
./bootstrap-vcpkg.sh

OR for Windows

bootstrap-vcpkg.bat

./vcpkg integrate install
./vcpkg install wolfmqtt

The wolfMQTT port in vcpkg is kept up to date by wolfSSL.

We also have vcpkg ports for wolftpm, wolfssl and curl.

Check out the changelog from the download for a full list of features and fixes, or if you have any questions or run into any issues, contact us at facts@wolfssl.com, or call us at +1 425 245 8247.:

https://github.com/wolfSSL/wolfMQTT/blob/master/ChangeLog.md

While you’re there, show us some love and give the wolfMQTT project a Star!

You can download the latest release here: https://www.wolfssl.com/download/

Or clone directly from our GitHub repository: https://github.com/wolfSSL/wolfMQTT

cURL Up 2022

The cURL Project and wolfSSL is happy to announce the annual cURL Developers Conference, cURL Up has been rescheduled for Thursday September 15, 2022! cURL Up will be held virtually this September giving allowing the world – wide cURL community to join.

cURL Up is the annual curl developers conference where we gather and talk Internet protocols, curl’s past, current situation and how to design its future.

This is an intimate and very friendly meetup where you will have the opportunity to talk to Daniel Stenberg, founder and maintainer of cURL, as well as other speakers and sponsors about cURL and related technologies.

The first 50 registrants get some awesome swag!

When: Sep 15, 2022 06:00 AM Pacific Time (US and Canada)

Watch the curl up 2022 comprehensive videos.

If you have any questions or run into any issues, contact us at facts@wolfssl.com, or call us at +1 425 245 8247.

Improved Coverage of Maintained (ABI) Application Binary Interfaces

wolfSSL’s controlled and maintained Application Binary Interface (ABI) coverage has been extended by 50 APIs to now have a total of 113. This includes parts of wolfCrypt including the Certificate APIs. This ensures that these APIs do not change over time so that any application using them will not be negatively impacted by upgrading to future releases of wolfSSL.

One of our goals at wolfSSL is to make sure that adopting our leading edge security solutions is as easy as possible. This includes helping our customers transition from an older version of wolfSSL to the latest version, with enhanced security, as easy as possible. The ABI coverage is one part in helping our customers with a smooth and easy transition.

Do you have questions about our ABI coverage?

Would you like to request enhancements or additional coverage?

If you have any questions or run into any issues, contact us at facts@wolfssl.com, or call us at +1 425 245 8247.

Posts navigation

1 2 3 52 53 54 55 56 57 58 192 193 194