RECENT BLOG NEWS

What is CT (Certificate Transparency)? 

Certificate Transparency is from RFC 6962 and is an extension on certificates to create a Merkle Tree (hash tree like with blockchain). The purpose of the tree is to help spot misuses of certificates and to provide a public way to audit the log of certificates issued. It was first implemented by Google in 2013 and required by google in 2017 which was then pushed back to 2018. Google has now been requiring all new certificates that are issued to have CT. The SCT (signed certificate timestamp) for CT can be sent in a TLS extension too, or with OCSP.

This is something we are thinking of adding to our library just to make it easier for users to parse out the information and view it with wolfSSL. Currently, users can get the extension by getting the peer certificate after a connection is complete and using one of the available checkers (google/cloudflare have checkers). It obviously gets more involved if adding the TLS extension (signed_certificate_timestamp) or if implementing a Monitor (application that goes out and does the audit on the certificate).

What are we doing about it?

To make this process easier we are planning on leaving it up to the certificate to contain the SCT and parse it from there.

To get there we are planing on making sure it includes:

– API to get the certificate extension information (people using this will want the hash / signature / timestamp to perform an audit on certificates)

– Checks on the timestamp (must be rejected by client if it is in the future)

– Code in our certificate extension parsing to read the OIDs and store the hash / signature / timestamp

– Testing and documentation (more time on testing since affecting certificate parsing code)

Love it? Star wolfSSL on GitHub.

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

If you pop over to the OpenWrt project site, you’ll stumble upon some excellent news:

“TLS support is now provided by default in OpenWrt images including the trusted CA certificates from Mozilla. It means that wget and opkg now support fetching resources over HTTPS out-of-the-box. The opkg download server is accessed through HTTPS by default. OpenWrt switched from mbed TLS to wolfSSL as the default SSL library, mbed TLS and OpenSSL are still available and can be installed manually.”

This means OpenWrt users can easily benefit from everything keeping wolfSSL ahead of the pack, including our early adoption of TLS 1.3 for top-tier security, uncompromised performance benchmarks, and certifications such as FIPS 140-2 and 3. Learn more about wolfSSL’s advantages over OpenSSL and write to us (facts at wolfSSL.com) to tell us about your OpenWrt projects with wolfSSL!

Love it? Star wolfSSL on GitHub.

Find the OpenWrt announcement here.

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

The acronym CAAM stands for Cryptographic Accelerator and Assurance Module. It is hardware that can be found on many i.MX NXP devices. When used it speeds up the cryptographic algorithms such as ECC and AES. In addition to the performance gained with using the CAAM for cryptographic operations, the application can also increase security by using encrypted keys and secure memory partitions with the CAAM. When describing the keys and blobs used with the CAAM, the term black keys and blobs are used to describe when the key has been encrypted by the hardware. Red keys refer to when a key has not been encrypted and is still in plain text.

wolfSSL has support for the CAAM driver with many IoT OS’s and embedded i.MX devices. Support for additional algorithms, devices and OS’s is continuously being added. There is also support by request if a project calls for something not already implemented or in progress.

What is currently supported in wolfSSL:

OS: QNX (using wolfSSL QNX CAAM driver)
Operations Supported:
– ECC (sign/verify/ecdh), with and without encrypted black keys
– AES-CMAC
– BLOB (red and black)
– TRNG
Notes: Developed on i.MX6 UL

OS: GreenHills Integrity (using wolfSSL CAAM driver)
Operations Supported:
– AES (CCM, ECB, CBC, CTR)
– MD5
– SHA1, SHA224, SHA256
– TRNG
– BLOB (red)
Notes: Developed on i.MX6 Dual/Quad/Solo series

OS: Embedded Linux (using third party cryptodev-linux or af-alg)
Operations Supported:
– AES (ECB, CBC, GCM)
– SHA256

Benchmarks using the CAAM with wolfSSL can be found on the benchmark page located here (https://www.wolfssl.com/docs/benchmarks/).

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

The embedded systems community has long sought a top quality, super flexible, made-with-love IDPS. Today, wolfSSL answers the call, with our first preview release of wolfSentry, the IDPS (Intrusion Detection and Prevention System) for embedded and IoT systems.

Included in this preview are

• Support for Linux, BSD, MacOS X, and Deos, on 32 and 64 bit x86 and PPC targets.
• Programmatic insertion, deletion, and enumeration of static firewall rules.
• Evaluation of static firewall rules, with prefix and wildcard matching, enabling basic application call-ins.
• Integration into wolfSSL, using a new --enable-wolfsentry option, demonstrating simple pre-negotiation filtering of new connections.

Because this is a preview release, many capabilities are only partially implemented. Configuration and querying by textual blobs, dynamic defenses, plugin actions, and thread safety, are coming soon.

Follow this blog and our GitHub for the latest, as we will make quick work of these features!

Also coming soon is support for more target ecosystems, including AUTOSAR, FreeRTOS, VxWorks, QNX and other key embedded environments.

We particularly seek to enable researchers with this release. Let us know what you think, or ask us about our plans, and we’ll respond. We want wolfSentry to be fully vetted by the best in the OSS community.

Download wolfSentry now from https://github.com/wolfSSL/wolfsentry, and tell us what your IDPS priorities are!

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

Author: Daniel Stenberg (cross posted from daniel.haxx.se)

Friends of mine know that I’ve tried for a long time to get confirmation that curl is used in space. We’ve believed it to be likely but I’ve wanted to get a clear confirmation that this is indeed the fact.

Today GitHub posted their article about open source in the Mars mission, and they now provide a badge on their site for contributors of projects that are used in that mission.

I have one of those badges now. Only a few other of the current 879 recorded curl authors got it. Which seems to be due to them using a very old curl release (curl 7.19, released in September 2008) and they couldn’t match all contributors with emails or the authors didn’t have their emails verified on GitHub etc.

According to that GitHub blog post, we are “almost 12,000” developers who got it.

While this strictly speaking doesn’t say that curl is actually used in space, I think it can probably be assumed to be.

Here’s the interplanetary curl development displayed in a single graph:

See also: screenshotted curl credits and curl supports NASA.

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

With our new release of wolfSentry people might wonder how it compares to Suricata. Suricata is an open source IDS / IPS / NSM engine. While it seems that Suricata is in rivalry with wolfSentry, our embedded IDPS; they actually have a synergy, it would make sense for sophisticated users to deploy both of them.

Suricata:

• The distribution tarball is 29 MB
• The build tree with minimal featureset is 536 MB
• The binary installation image is 35 MB, of which 34.5 MB is the Suricata binary executable (dynamically linked)
• The main executable depends on 18 special purpose libraries not included in the distribution.
• Suricata depends on Python
• It only runs on Unix-like and Windows OSs, and its firewalling (host protection) depends on host OS facilities.

Suricata is a heavyweight, infrastructural IDS platform.  It has to duplicate the logic, and a lot of the processing, of the protocols/libraries/applications that it is monitoring and protecting.

Suricata can do a lot of powerful things, including protecting endpoints that can’t protect themselves, and protecting endpoints before they’re attacked, by blocking bad actors at the first opportunity, when they’ve only had time to attack a first protected endpoint.

wolfSentry

By comparison, wolfSentry has a much smaller footprint. 

• The distribution tarball is 36 K.
• The build tree is 2.5 MB, with all features and debugging symbols enabled.
• libwolfsentry.a is 339 K, and the biggest example executable is 443 K, or 84 K stripped, and uses no libraries beyond libc (which it barely uses).
• It is designed to integrate directly with network-facing applications/libraries to block bad traffic, and it can optionally integrate with host firewall facilities, via plugins.
• It can run on bare metal, in which case the firewall functions can be directly integrated into the network stack of the application.

wolfSentry isn’t infrastructural, it’s on the endpoints, and it’s intended to be integrated with the endpoint applications/libraries to leverage them to the fullest.

Comparison and Synergy

The synergy between wolfSentry and Suricata infrastructural IDPSs is to have wolfSentry (via a plugin) notify the external IDPS when it detects bad traffic that the external IDPS might not be able to detect.  This can enable clever stuff like blocking the bad traffic inside the network, before it even reaches the endpoint, and of course blocking the bad traffic for all the protected endpoints at once.

This raises an obvious worry about Suricata being compromised, because by nature it is directly exposed to the network, and is highly privileged.  Suricata addresses this by doing lots of fuzz testing etc. to build confidence.  However, because they have a 29 MB distribution tarball, there is a higher likelihood for things to fall through the cracks.

An advantage of wolfSentry is wolfSentry doesn’t require the endpoint to trust anyone else, nor anyone else to trust the endpoint.  It’s a freestanding, high-efficiency self-defense system.

Ultimately, while there are some comparisons and different uses between the two, the best course of action would be to use wolfSentry and Suricata together for the best secure IDPS.

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

Secure boot and remote updates are becoming a mandatory requirement in the market of IoT connected and secured embedded systems.

wolfSSL offers multiple solutions to update your remote embedded systems connected to the Internet. The core component that authenticates the firmware and regulates the installation of a new version is wolfBoot, the secure bootloader for all 32-bit microcontrollers.

wolfBoot follows the IETF SUIT group recommendations to validate the authenticity and the integrity of any firmware, before allowing it to run on the target. To do so, wolfBoot uses public key based authentication mechanisms provided by wolfCrypt.

In this short tutorial, we have developed a TLS 1.3 web server that can receive authenticated updates and interact with the bootloader to begin the installation once the received firmware is successfully verified and authenticated. wolfBoot will only allow genuine firmware images, generated by the device’s owner, to be installed and run on the target. The updates are signed with the owner’s private key, and can be deployed on the target from a web interface (or using a curl one-liner!).

What are the Key Differences Between wolfBoot and the Others?

wolfBoot is independent of any silicon vendor, IP designer or system vendor’s approach to the problem of secure boot and secure firmware updates. As such we support heterogeneity in keystores, like TPM 2.0, PKCS#11, STSafe, CAAM, ATECC608A, ST33, etc. In terms of hardware encryption, we support a wide variety of hardware encryption drivers such that your firmware update and re-boot will be performant. Unlike our gaggle of competitors, we also support multiple traditional, RTOS, and bare metal environments. Our heterogeneity also extends to a variety of transport mechanisms, including, SSH, cURL, TLS 1.3, HTTPS, all with a variety of TCP/IP options. Need certifications like FIPS 140-2, DO-178, MISRA or ASPICE? No problem, we do that too!

In short, we can support you in your real world application! If you have questions, then please contact us at facts@wolfssl.com.

The Base System

Our system of choice for this example is the NXP Kinetis K64 freedom board. The hardware manufacturer provides drivers and board support software, which is compiled within the running application or OS. The simplest application does not contain any operating system, and executes all the tasks in a single-threaded main loop. This approach is often referred to as ‘bare metal’, and is simple enough to implement for most embedded systems that are dedicated to a single specific task, or where the entire functionality of the device can be easily developed within a single, global state machine.

A different approach consists in integrating a real-time operating system (RTOS). FreeRTOS is one of the most popular choices for multitasking embedded systems. Our base system in this scenario runs FreeRTOS, and uses a TCP/IP stack to provide network access to its threads. FreeRTOS supports several TCP/IP stacks. We decided to use picoTCP in this case, but any embedded TCP/IP implementation would work as well.

Securing the Connections

By default, all the socket connectivity in our system will not be encrypted or secured in any way. Luckily, wolfSSL is a SSL/TLS implementation that is capable of running in small, microcontroller based systems and providing the latest and greatest security mechanisms that are recommended by international standards. wolfSSL is designed to easily be integrated with any combination of RTOS and TCP/IP stacks out there, and it provides secure socket communication using the same level of security as the rest of the IT infrastructure while being generally smaller in size and faster than all its competitors. All threads in the system are able to create secure sockets to communicate with the remote endpoint. In this case we create a simple embedded HTTPS server, only allowing TLS 1.3 connections, which is running in a thread on the target. The only purpose of our demo server is to accept a transfer request, via a HTTP POST, to upload a new version of the running firmware.

The picture below shows the architectural components of the running application.

Figure 1: Architecture of secure IoT multithreading system

Secure Bootloader

Integrating wolfBoot into an existing system is easy. First of all, we create a configuration for the target device. The configuration can be generated step-by-step by running

make config

from the wolfBoot directory. The configuration also contains the information needed by the bootloader to partition the internal flash in order to accommodate two firmware images at the same time in the FLASH memory. In our scenario, we opt for the following geometry:

• A 40KB partition for wolfBoot. wolfBoot itself will be about 26KB in size, but we allow some extra space in case we want to change the public key algorithm, or if we decide to enable debugging symbols in wolfBoot to check what it is doing at boot. Adding debugging symbols will result in a larger wolfBoot image.
• Two partitions of the same size (499712 bytes). These are the partitions used to store the current firmware and the update image received through a secure connection later, which is the candidate for a new installation if the bootloader allows that.
• One single-sector (4KB) swap partition, used by wolfBoot when replacing the current firmware with an updated version, to make all the swapping operations fail-safe, and to guarantee that a copy of the old firmware is kept in the second partition after an update. This mechanism provides a reliable way to step back after a failed boot into a buggy firmware (although verified and genuine).

The setup above corresponds to the following values in wolfBoot configuration:

WOLFBOOT_PARTITION_SIZE?=0x7A000
WOLFBOOT_SECTOR_SIZE?=0x1000
WOLFBOOT_PARTITION_BOOT_ADDRESS?=0xA000
WOLFBOOT_PARTITION_UPDATE_ADDRESS?=0x84000
WOLFBOOT_PARTITION_SWAP_ADDRESS?=0xff000

Which in turn reflects the flash geometry in the figure below:

Figure 2: FLASH memory geometry chosen for this example

To sign the partition, we could use DSA or ECDSA algorithms provided by wolfCrypt. In this case, we opt for ECDSA with ECC256. A manifest header is attached at the beginning of each image: it contains the signature, the version number and other important information about the original firmware. Because of the manifest header, the actual entry point of the application has a fixed offset from the start of the BOOT partition. When using ECC256, this offset is 256 Bytes, so the actual starting point for the application code will be at address 0x0A100.

Because the code of the application is not position-independent, the linker script (.ld) must be adjusted so all the symbols addresses are relative to its new entry point. The MEMORY section in our original linker script contained the following line:

FLASH (rx) : ORIGIN = 0x00000000, LENGTH = 1M

Which we replace with:

FLASH (rx) : ORIGIN = 0x0000A100, LENGTH = 0x7A000

In order to accommodate the bootloader at the beginning of the FLASH.

Sign and Install the Initial Firmware

In the example code provided, all the operations to create the initial image are automated, and executed by simply running make. However, all the steps are explained here to understand what is going on under the hood.

When the bootloader is compiled for the first time, the key pair is generated. The public key can be safely included in the wolfboot image (wolfboot.bin), while the corresponding private key (ecc256.der in our case) must be safely stored and never distributed. The private key is very important, as it is used to sign the firmware image that we are about to upload to the target, and all the future updates that we shall want to upload in the future via the device HTTPS interface, simply using our web browser. When the application is compiled and linked via our modified linker script, we sign it and assign a version number. This is accomplished using the python script sign.py, included in wolfBoot:

sign.py --ecc256 image.bin ../wolfBoot/ecc256.der 1

which will create a new image image_v1_signed.bin containing the manifest header for the verification required to run on the target.

The two images wolfboot.bin and image_v1_signed.bin are then combined into the final image factory.bin, taking into account the partitions offset. If the image has been created correctly and uploaded to the device, the system will boot into wolfboot, which takes a few milliseconds to validate the image.

HTTPS-based Firmware Updates

One FreeRTOS thread is responsible for responding to HTTPS requests. In the example code, the system responds on the Ethernet interface to IP address 192.168.178.211 on port 443. A web browser that supports TLS 1.3 can access the web interface at that address. The example code that manages the HTTPS requests from the client is very simple: it responds to GET requests with a form page, where a new signed firmware update can be uploaded, and to POST request by storing the firmware in the UPDATE partition and initiate the shutdown.

When we create a new version of the software, we can simply sign the new image using the sign.py script, and increase the version number in the command invocation:

sign.py --ecc256 image.bin ../wolfBoot/ecc256.der 2

The new application image can be simply uploaded from a web browser the embedded HTTPS on the board.

When the transfer is complete, the device informs the bootloader that an update is available, and reboots to complete the installation of the new version. The page should reload automatically after about 30 seconds, to show that the updated firmware has been authenticated and it is now running.

Source Code

The source code for this demo is available at:

https://github.com/wolfSSL/wolfBoot-examples/tree/master/freeRTOS-Freescale-K64F-https-TLS1.3

The system analyzed in this tutorial represents an example of just one of the many possibilities of integration of wolfSSL solutions for securing the boot process of embedded micro controllers. Different products (wolfMQTT, wolfSSH) may be combined with the secure boot mechanism provided with wolfBoot to secure the entire firmware update process.

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

As some may be aware, wolfSSL added support for strongSwan in April of 2019. The upstream commit can be reviewed here: https://github.com/strongswan/strongswan/pull/133

Users can test the latest development master of wolfSSL with the latest version of strongSwan using the following setup:

wolfSSL Build and Installation Steps

$ git clone https://github.com/wolfSSL/wolfssl.git

$ cd wolfssl
$ ./autogen.sh

$ ./configure --enable-opensslall --enable-keygen --enable-rsapss --enable-des3 --enable-dtls --enable-certgen --enable-certreq --enable-certext --enable-sessioncerts --enable-crl --enable-ocsp CFLAGS="-DWOLFSSL_DES_ECB -DWOLFSSL_LOG_PRINTF -DWOLFSSL_PUBLIC_MP -DHAVE_EX_DATA"

$ make
$ make check
$ sudo make install

strongSwan Build and Installation Steps

# if the following packages are not already installed:
$ sudo apt-get install flex bison byacc libsoup2.4-dev gperf

$ git clone https://github.com/strongswan/strongswan.git
$ cd strongswan
$ ./autogen.sh

# if packages are missing autogen.sh must be re-run

$ ./configure --disable-defaults --enable-pki --enable-wolfssl --enable-pem
$ make
$ make check
$ sudo make install

wolfSSL has had interest in enabling FIPS 140-2/140-3 support with strongSwan so our engineers verified everything is working with the wolfCrypt FIPS 140-2 validated Module!

The steps wolfSSL used for testing are as follows:

Testing was done using the wolfSSL commercial FIPS release v4.7.0 which internally uses the wolfCrypt v4.0.0 FIPS 140-2 validated Crypto Module. It was located in the /home/user-name/Downloads directory on the target test system, Linux 4.15 Ubuntu 18.04 LTS running on Intel(R) Xeon(R) CPU E3-1270 v6 @ 3.80GHz.

1. wolfSSL was configured and installed with these settings:

./configure --enable-opensslall --enable-keygen --enable-rsapss --enable-des3 --enable-dtls --enable-certgen --enable-certreq --enable-certext --enable-sessioncerts --enable-crl --enable-ocsp CFLAGS="-DWOLFSSL_DES_ECB -DWOLFSSL_LOG_PRINTF -DWOLFSSL_PUBLIC_MP -DHAVE_EX_DATA -DFP_MAX_BITS=8192" --enable-ed25519 --enable-curve25519 --enable-fips=v2 --enable-intelasm --prefix=$(pwd)/../fips-install-dir
 make
 make install

2. A custom install location was used which equated to /home/user-name/Downloads/fips-install-dir and the configuration for strongSwan accounted for this.
3. strongSwan was cloned to /home/user-name/Downloads with “git clone https://github.com/strongswan/strongswan.git”
4. StongSwan was configured and installed with these settings:

./configure --disable-defaults --enable-pki --enable-wolfssl --enable-pem --prefix=$(pwd)/../strongswan-install-dir wolfssl_CFLAGS="-I$(pwd)/../fips-install-dir/include" wolfssl_LIBS="-L$(pwd)/../fips-install-dir/lib -lwolfssl"
 make
 make install
 make check

5. In the make check stage of the test, it was observed that 1 test was failing.

 Passed 34 of 35 'libstrongswan' suites
 FAIL: libstrongswan_tests
 ==================
 1 of 1 test failed
 ==================

6. Reviewing the logs it was apparent one of the RSA tests was failing.
7. Upon further debugging it turned out the failure was a test in strongSwan that was attempting to create an RSA key size of 1536-bits.

Running case 'generate':
 DEBUG: key_sizes[_i] set to 1024
 + PASS
 DEBUG: key_sizes[_i] set to 1536
 - FAIL
 DEBUG: key_sizes[_i] set to 2048
 + PASS
 DEBUG: key_sizes[_i] set to 3072
 + PASS
 DEBUG: key_sizes[_i] set to 4096
 + PASS

wolfSSL has a function RsaSizeCheck() which in FIPS mode will specifically reject any non FIPS RSA key sizes so this failure was not only expected, but it is a good thing for those wanting to use strongSwan in FIPS mode and ensure only FIPS-validated RSA key sizes will be supported!

wolfSSL is pleased that with the latest release of wolfSSL v4.7.0 and the wolfCrypt FIPS 140-2 module validated on FIPS certificate 3389, strongSwan support is working splendidly and wolfSSL engineers will be making efforts to ensure continued support into the future!

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 is implementing MIKEY-SAKKE!

MIKEY-SAKKE is a standard created by the UK government’s National Cyber Security Center (NCSC). MIKEY-SAKKE is a standard designed to enable secure, cross-platform multimedia communications. It is highly scalable, requiring no prior setup between users or distribution of user certificates. It is designed to be centrally-managed, giving a domain manager full control of the security of the system. But even so, it maintains high-availability, as calling does not require interaction with centralized architecture.

wolfSSL is a lightweight TLS/SSL library that is targeted for embedded devices and systems. It has support for the TLS 1.3 protocol, which is a secure protocol for transporting data between devices and across the Internet. In addition, wolfSSL uses the wolfCrypt encryption library to handle its data encryption.

Secure communications are needed across all governments. As a result governments create policies encouraging the development of security solutions. MIKEY-SAKKE is the answer to the security requirements from the UK government to specify secure, open and patent free cryptographic methods in order to empower private industry to provide UK government interoperable secure communication solutions. As a result many private and commercial organizations perceive a sizable advantage being MIKEY-SAKKE compliant.

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

FIPS 140-2 requires the use of validated cryptography in the security systems implemented by federal agencies to protect sensitive information. The wolfCrypt Module is a comprehensive suite of FIPS Approved algorithms. All key sizes and modes have been implemented to allow flexibility and efficiency.

The National Institute of Standards and Technology (NIST) is sending FIPS cert #2425 into sunset June 2021. For customers who will be impacted, the wolfCrypt Cryptographic Module maintains its #3389 certificate and can be used in conjunction with the wolfSSL embedded SSL/TLS library for full TLS 1.3 client and server support. Upgrade your FIPS cert with wolfSSL to stay afloat and benefit from: 

• Algorithm support for TLS 1.3!
• New algorithms such as AES (CBC, GCM, CTR, ECB), CVL, Hash DRBG, DSA, DHE, ECDSA (key generation, sign, verify), HMAC, RSA (key generation, sign, verify), SHA-3, SHA-2, SHA-1, and Triple-DES
• Hardware encryption support for NXP’s Cryptographic Assistance and Assurance Module (CAAM), NXP Memory-Mapped Cryptographic Acceleration Unit (mmCAU), Intel’s AES-NI, and more
• Support for secure elements and TPM’s
• Interoperability with wolfBoot, wolfSSH, and wolfTPM
• Integration support for third party libraries such as strongswan, nginx, python and more

Contact us to upgrade to FIPS cert #3389 at fips@wolfssl.com. 

Additional Resources 

Learn more about wolfSSL support for FIPS cert #3389: https://www.wolfssl.com/wolfcrypt-fips-certificate-3389-3/ 

For a list of supported Operating Environments for wolfCrypt FIPS, check our FIPS page: https://www.wolfssl.com/license/fips/ 

Our FIPS Story

wolfSSL is currently the leader in embedded FIPS certificates. We have a long history in FIPS starting with wolfCrypt FIPS 140-2 Level 1 Certificate #2425 as well as wolfCrypt v4 FIPS 140-2 Level 1 Certificate #3389. wolfSSL partners with FIPS experts KeyPair to bring you FIPS consulting services, and high assurance along each step of your FIPS certification process. Additionally, wolfSSL will be the first implementation of FIPS 140-3.

wolfSSL also provides support for a wolfCrypt FIPS Ready version of the library! wolfCrypt FIPS Ready is our FIPS enabled cryptography layer code included in the wolfSSL source tree that you can enable and build. You do not get a FIPS certificate, you are not FIPS approved, but you will be FIPS Ready. FIPS Ready means that you have included the FIPS code into your build and that you are operating according to the FIPS enforced best practices of default entry point, and power on self test.

wolfCrypt FIPS Ready can be downloaded from the wolfSSL download page located here: https://www.wolfssl.com/download/. More information on getting set up with wolfCrypt FIPS Ready can be found in our FIPS Ready User guide here: https://www.wolfssl.com/docs/fips-ready-user-guide/

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