Month: April 2021

wolfSSL is adding support for complete RTCA DO-178C level A certification! wolfSSL will offer DO-178 wolfCrypt as a commercial off -the-shelf (COTS) solution for connected avionics applications. Adherence to DO-178C level A will be supported through the first wolfCrypt COTS DO-178C certification kit release that includes traceable artifacts for the following encryption algorithms:

• SHA-256 for message digest.
• AES for encryption and decryption.
• RSA to sign and verify a message.
• chacha20_poly1305 for authenticated encryption and decryption.
• ECC to sign, verify and share secrets.
• HMAC  for keyed-hashing for message authentication.

The primary goal of this initial release is to provide the proper cryptographic underpinnings for secure boot and secure firmware update in commercial and military avionics. wolfSSL brings trusted, military-grade security to connected commercial and military aircraft. Avionics developers now have a flexible, compact, economical, high-performance COTS solution for quickly delivering enhanced, secure communications that can be readily certified to DO-178. In addition, any of the FIPS 140-2 validated crypto algorithms can be used in DO-178 mode for combined FIPS 140-2/DO-178 consumption. The wolfCrypt cryptography library has been FIPS 140-2 validated (Certificate’s #2425 and #3389).

If you have questions on any of the above, please contact us at facts@wolfssl.com, or call us at +1 425 245 8247.

Optimization Support

We understand that securely rebooting avionic systems has rigorous performance requirements. As such, we’re here to help with cryptographic performance optimizations through our services organization. 

Release Plan

• Basic crypto for secure boot and secure firmware updates – Available Now!
• wolfBoot Secure Boot – Q1, 2022
• wolfSSL – Q2, 2022
• wolfDTLS – Q2, 2022

To download and view the most recent version of wolfSSL, the wolfSSL GitHub repository can be cloned from here: https://github.com/wolfssl/wolfssl.git, and the most recent stable release can be downloaded from the wolfSSL download page here: https://www.wolfssl.com/download/.

For more information, please visit the wolfSSL DO-178 product page: https://www.wolfssl.com/wolfssl-support-178-dal/.

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 many in the FIPS world are aware NIST retired CAVP (Cryptographic Algorithm Validation Protocol) testing on June 30th of 2020, permanently replacing CAVP with ACVP (Automated Cryptographic Validation Protocol), also referred to as ACVTS (Automated Cryptographic Validation Test System).

In order to prepare for this transition NIST offered a “demo server” that Vendors like wolfSSL and FIPS Labs could utilize in standup of the new protocol. Once the transition was completed NIST also setup “production servers” which only FIPS Labs with a trusted certificate issued by NIST can connect to; Production Vectors passing are now the gateway to Algorithm Certification (IE certs like the ones wolfSSL just received!).

Algorithm Certification is a prerequisite to CMVP FIPS 140-2 (and 140-3) validations. This design keeps in place the need for a FIPS lab to achieve algorithm certification but it now allows for Vendors such as wolfSSL to pre-test in advance of requesting production vectors for certification! wolfCrypt has been listed on the CMVP IUT List for FIPS 140-3! We are currently working with our testing lab to get validated as quickly as possible with the new FIPS standard from the NIST. wolfSSL is the first software library on the FIPS 140-3 IUT list for embedded development.

Concurrently wolfSSL is also in the process of developing our own ACVP client based off of the current draft (draft-fussell-acvp-spec-01). Having many algorithms already completing the validation process through the NIST operated ACVP Demo server. Where our test vendor information can be seen publicly listed on the demo site here (https://demo.acvts.nist.gov/home).

More on ACVP’s

ACVP stands for (Automated Cryptographic Validation Protocol) and it is the upcoming protocol that will be used for FIPS validation. This is going to be a prerequisite certificate for the CMVP(Cryptographic Module Validation Program) and CAVP(Cryptographic Algorithm Validation Program) certificates.

ACVP makes testing cryptographic algorithms and modules more efficient than the current method and more automated. There are three main parts to ACVP – a server, a proxy, and a client.

• The server side handles requests for test vectors and requests for validation among other requests. This side is operated by a FIPS lab or by NIST themselves.
• A proxy with ACVP can be used to communicate to offline systems and handle transferring information from the system being tested to the server. Often an ACVP client is used instead.
• The last part being a client, which is most relevant to users who are wanting to get their cryptography FIPS validated. An ACVP client is directly hooked up to the module to be tested and then communicates with the ACVP server to send requests for test vectors, responses of the results from running those tests, and requests for algorithm validation. There are multiple pieces required to build a ACVP client in order to complete a validation process, some of the large portions of the effort go into
  • JSON parsing / creation for communication with a ACVP server
  • HTTPS GET / POST / PUT / DELETE messages used for securely transporting information
  • 2 factor authentication with TOTP (Time-Based One-Time Password Algorithm)
  • Plugging in the test harness that runs crypto operations

Ultimately an ACVP client communicates with the server to validate cryptographic operations. This includes creating, or referencing meta data such as; vendor, OE, and module information. A simplified message flow for getting an algorithm validated is as follows:

We can assist with your FIPS needs.

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

More information from NIST’s website about the ACVP project can be found here:
https://csrc.nist.gov/Projects/Automated-Cryptographic-Validation-Testing.

From the early days of the wolfSSL library, we have provided example clients and servers with wolfSSL. These examples have shown how easy it is to use wolfSSL in various configurations. We also use them to help test the library. Over the years we’ve added new features available with TLS to our examples, and our examples have grown a little complicated.

Enter the wolfSSL Examples GitHub repository. We tasked some of our interns, with little to no experience with the wolfSSL library, to write some example clients and servers that set up and test various types of connections. They give you a bare-bones simple demonstration on how to set up a client or server using wolfSSL. We also have examples showing off how to use some features of the library like the certificate manager. 

The repository contains example applications, written in C, which demonstrate how to use the wolfSSL lightweight SSL/TLS library for secure communication. Each directory represents a unique topic (SSL/TLS, DTLS, PSK, etc.) and contains a Makefile as well as a simple tutorial on the given topic.

Current Examples:

• utasker (uTasker wolfSSL Example Tasks)

This directory contains example uTasker client and server tasks that demonstrate using wolfSSL with the uTasker stack. These have been tested on the uTasker Simulator.

Please see the utasker/README.md for further usage and details.

• android (Android NDK Examples)

This directory contains examples that demonstrate using wolfSSL and wolfSSLJNI on the Android platform, using the Android NDK toolchain.

Please see the android/README.md for further usage and details.

• certfields (X509 field extraction)

This directory contains an example that demonstrates using the wolfSSL to read a DER encoded certificate and extract the public key and subject name information.

Please see the certfields/README.md for further usage and details.

• certmanager (wolfSSL CertManager)

This directory contains examples that demonstrate using the wolfSSL CertManager (Certificate Manager) functionality.

Please see the certmanager/README.md for further usage and details.

• wolfCLU (wolfSSL Command Line Utility)

This is a tool to provide command line access to wolfcrypt cryptographic libraries. wolfSSL command line utility will allow users to encrypt or decrypt a user specified file to any file name and extension.

Please see the clu/README.md for further usage and details.

Unique feature to wolfSSL CLU

The decision to allow for unique file extensions was prompted by automated tools available for brute forcing files. It will not provide extra security cryptographically however it will force attackers to check the header information on every single brute force attempt. This will provide further frustration and an extra step in any attempt to brute force a file encrypted with our utility.

• DTLS (Datagram TLS)

This directory contains examples of using DTLS, with client and server examples demonstrating UDP, DTLS, non-blocking, session resumption, and multi-threading.

When compiling wolfSSL for use with these examples, wolfSSL will need to be compiled with DTLS support:

cd wolfssl-[version]
./configure --enable-dtls

Examples in this directory may be compiled using:

cd ./dtls
make

• PSK (Pre-Shared Keys)

This directory contains examples of using PSK, with client and server examples demonstrating TCP/IP, PSK, non-blocking, session resumption, and multi-threading.

When compiling wolfSSL for use with these examples, wolfSSL will need to be compiled with PSK support:

cd wolfssl-[version]
./configure --enable-psk

Examples in this directory may be compiled using:

cd ./psk
make

• SSL/TLS

This directory contains examples of using SSL/TLS, with client and server examples demonstrating TCP/IP, SSL/TLS, non-blocking, session resumption, and multi-threading.

Examples in this directory may be compiled using:

cd ./tls
make

• BTLE

This directory contains examples for securing a Bluetooth Low Energy Link (BTLE). BTLE packets are small and throughput is low, so these examples demonstrate a way to exchange data securely without BTLE pairing.

Notes

When necessary, examples will use the example certificates and keys located in the ./certs directory. These certificates and keys have been pulled in from the main wolfSSL repository.

Support

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