RECENT BLOG NEWS
Or sign up to receive weekly email notifications containing the latest news from wolfSSL.
In addition, wolfSSL now has a support-specific blog page dedicated to answering some of the more commonly received support questions.
Version 4.7.0 of wolfSSL has general fixes and optimizations, a few excellent feature additions, and some vulnerability fixes. Some of the new features added are support for S/MIME bundles which are commonly used with email traffic, an
--enable-reproducable-build flag to help out with inspecting the wolfSSL library created, expansion to the OpenSSL compatibility layer, and additional session ticket API’s that help modularly control which TLS protocol version can use session tickets.
A few of the improvements and optimizations in the release are to linux kernel module support, DTLS resending of a flight after timeouts, the CMake build with a user settings file and out of directory builds of wolfSSL.
This release fixes 3 vulnerabilities, one of them being a TLS 1.3 client side issue that is rated as high. Thanks to Aina Toky Rasoamanana and Olivier Levillain from Télécom SudParis for the report on this TLS 1.3 issue.
A full list of items in the release can be seen in the ChangeLog.md bundled with wolfSSL or on our main webpage. For further reading about vulnerabilities see our webpage or contact us at email@example.com for general wolfSSL information.
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:
More information from NIST’s website about the ACVP project can be found here:
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.
- 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.
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
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
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
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.
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.
Please contact wolfSSL at firstname.lastname@example.org with any questions, bug fixes, or suggested feature additions.
wolfSSL personally invites you to our wolfSentry webinar, where we are introducing our newest product wolfSentry, a universal, dynamic, embeddable IDPS (intrusion detection and prevention system)! Join us to learn about about what an IDPS is, why you should care, and wolfSentry is the solution to all of your problems
About the webinar:
When: Mar 31, 2021 10:00 AM Pacific Time (US and Canada)
Topic: Introducing wolfSentry, an Embeddable IDPS
Register in advance for this webinar:
After registering, you will receive a confirmation email containing information about joining the webinar.
Please bring any questions you have, and we look forward to seeing you there!
We see a continuing adoption of wolfTPM and TPM 2.0 modules in IoT and Edge embedded systems. In addition, there is a new trend of adding wolfTPM to safety-critical systems, such as aerospace and medical products. For many years, there was no TPM 2.0 stack designed for baremetal and RTOS systems and wolfTPM changed this.
Today, we can announce that wolfTPM is also the first TPM 2.0 stack to support Physical Presence (PP). This feature allows the user to confirm TPM 2.0 operations by asserting physical input to the TPM chip and increase the level of security assurance for critical operations.
For example, TPM2_Clear is a command that returns the TPM to a factory state, destroying existing primary and storage keys, and can be safeguarded by a PP request. TPM2_Clear is typically used when onboarding a new owner of a system, e.g. second market or internal change of ownership equipment.
PP requests are satisfied by controlling a dedicated I/O pin on the TPM chip and now wolfTPM has the capability to extend the list of commands that require it. This could be used to restrict certain operations. It could also be used in existing designs to replace a mechanical switch previously used for Physical Presence.
Another new feature of wolfTPM is the ability to control extra I/O pins available on TPM modules, such as the STMicroelectronics ST33 TPM 2.0 module. The developer can use a single wolfTPM call to control additional I/O pins and pass physical signals, as sign of security or system events, to other subsystems.
For more information about TPM 2.0 Physical Presence and extra I/O support, please contact us at email@example.com
Some of our users have been wondering if we were doing benchmarks of our SSL/TLS and cryptography performance. Here are the results we have gathered so far: wolfSSL / wolfCrypt Benchmarking. This page includes several reference benchmarks as well as comparisons of software versus hardware cryptography.
Let us know if we should do a different kind of benchmark at firstname.lastname@example.org.
wolfSSL supports the Online Certificate Status Protocol (OCSP) [https://tools.ietf.org/html/rfc2560] as a client and OCSP stapling version 1 [https://tools.ietf.org/html/rfc6066#section-8] and 2 [https://tools.ietf.org/html/rfc6961]. OCSP is a substitute for Certificate Revocation Lists (CRL). CRLs are a list of certificates that shouldn’t be temporarily or permanently trusted. A major setback for CRLs is the time it takes for these lists to propagate. It may take up to a week [https://tools.ietf.org/html/rfc5280#section-3.3] due to CRLs being issued periodically by Certificate Authorities (CA). OCSP allows clients to verify the validity of server certificates with an OCSP responder and know in real time whether to trust a certificate or not.
OCSP stapling is a TLS extension sent by a client that instructs the server that it would like to receive certificate status information. Stapling significantly cuts down on bandwidth and on round trips needed to set up a connection. When a TLS server receives the Certificate Status Request extension from a client, it will transmit the OCSP responders complete, DER-encoded OCSP response. This relieves the client from having to ask an OCSP responder about the certificate validity and saves the OCSP responder bandwidth coming from clients of a frequently visited server.
OCSP stapling version 1 is severely limited by being able to only transmit the status information of only one certificate. Many TLS servers opt to send intermediate certificates along with its own certificate in case clients do not know the intermediate certificate chain. OCSP stapling version 1 will only save the client the trouble of confirming the status of the server’s certificate, but not of checking the intermediate certificates. OCSP stapling version 2 defines a new extension that allows “servers […] to provide status information about not only the server’s own certificate but also the status of intermediate certificates in the chain” [https://tools.ietf.org/html/rfc6961].
To compile wolfSSL with OCSP support, use the following configure options:
OCSP stapling v2:
The following API are available in wolfSSL to enable OCSP usage:
int wolfSSL_CTX_EnableOCSP(WOLFSSL_CTX*, int options); int wolfSSL_CTX_DisableOCSP(WOLFSSL_CTX*); int wolfSSL_CTX_SetOCSP_OverrideURL(WOLFSSL_CTX*, const char*); int wolfSSL_CTX_SetOCSP_Cb(WOLFSSL_CTX*, CbOCSPIO, CbOCSPRespFree, void*); int wolfSSL_CTX_EnableOCSPStapling(WOLFSSL_CTX*); int wolfSSL_CTX_DisableOCSPStapling(WOLFSSL_CTX*); int wolfSSL_CTX_EnableOCSPMustStaple(WOLFSSL_CTX*); int wolfSSL_CTX_DisableOCSPMustStaple(WOLFSSL_CTX*);
The following flow is enough to use OCSP in wolfSSL:
To use OCSP stapling:
wolfSSL_CTX_EnableOCSPStapling(ctx); wolfSSL_UseOCSPStapling(ssl, WOLFSSL_CSR_OCSP, 0); wolfSSL_CTX_EnableOCSP(ctx, 0);
To use OCSP stapling version 2:
wolfSSL_CTX_EnableOCSPStapling(ctx); wolfSSL_UseOCSPStaplingV2(ssl, WOLFSSL_CSR2_OCSP*, 0); wolfSSL_CTX_EnableOCSP(ctx, 0);
* To provide status request information for intermediate certificates use
To allow the server to provide OCSP stapling responses use:
To provide a custom OCSP responder URL use:
wolfSSL_CTX_SetOCSP_OverrideURL(ctx, ocspUrl); wolfSSL_CTX_EnableOCSP(ctx, WOLFSSL_OCSP_URL_OVERRIDE);
OCSP stapling version 2 can’t be used with TLS 1.3 as it has been deprecated [https://tools.ietf.org/html/rfc8446#section-18.104.22.168]. TLS 1.3 uses OCSP stapling version 1 but the certificate status is not a separate message. Instead it is included as an extension to the corresponding certificate.
To learn more about the many features of wolfSSL, email us at email@example.com.
Support for wolfSSL has been upstreamed to the master OpenVPN branch in f6dca235ae560597a0763f0c98fcc9130b80ccf4! This means that you will be able to use wolfSSL directly in OpenVPN. wolfSSL is a lightweight and embedded SSL/TLS library that is extensively tested to provide the best security available. Using OpenVPN with wolfSSL, you can take advantage of our hardware cryptography and acceleration on many platforms.
To use OpenVPN with wolfSSL:
Compile wolfSSL with:
./configure --enable-openvpn make make install
Compile OpenVPN with:
./configure --with-crypto-library=wolfssl make make check make install
Contact us at firstname.lastname@example.org with any questions or feedback.
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 email@example.com.
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/
To build wolfSSL for cjose:
./configure --enable-opensslall --enable-aeskeywrap CPPFLAGS='-DHAVE_EX_DATA -DWOLFSSL_KEY_GEN'
To build cjose for wolfSSL:
- Download the appropriate patch from https://github.com/wolfSSL/osp/tree/master/cjose. Choose a patch that corresponds or is closest to your version of cjose.
patch -p1 < <path/to/downloaded/patch>
To verify that this build passes the tests run:
wolfSSL currently supports cjose version 0.6.1,
Feel free to contact us at firstname.lastname@example.org for additional information and help with using the new features of wolfSSL.
This feature has been added in commit 0cfde0794b9c5ab1c01171745b800140ee4f8662.
S/MIME is short for Secure/Multipurpose Internet Mail Extensions, a standard for public key encryption and signing of MIME data. The S/MIME standard allows you to sign, authenticate and encrypt plaintext MIME messages. It is commonly used in email. wolfSSL now supports both “enveloped data” (application/pkcs7-mime) and “detached signature” (multipart/signed) messages.
To enable S/MIME support in wolfSSL, run
./configure with the
--enable-smime flag, or add
HAVE_SMIME to your
user_settings.h file. Then, call
wolfSSL_SMIME_read_PKCS7() with 2 parameters:
- A BIO object containing your S/MIME message.
- A NULL BIO pointer which will be set to the signed data in case of a multipart message.
- This function call will give you a PKCS7 pointer, or NULL in case of an error.
If you have any questions, don’t hesitate to contact us at email@example.com.
- April 2021 (2)
- March 2021 (27)
- February 2021 (29)
- January 2021 (22)
- December 2020 (21)
- November 2020 (14)
- October 2020 (7)
- September 2020 (22)
- August 2020 (11)
- July 2020 (8)
- June 2020 (14)
- May 2020 (15)
- April 2020 (14)
- March 2020 (4)
- February 2020 (24)
- January 2020 (18)
- December 2019 (7)
- November 2019 (16)
- October 2019 (14)
- September 2019 (24)
- August 2019 (21)
- July 2019 (8)
- June 2019 (13)
- May 2019 (35)
- April 2019 (31)
- March 2019 (20)
- February 2019 (10)
- January 2019 (16)
- December 2018 (24)
- November 2018 (10)
- October 2018 (18)
- September 2018 (18)
- August 2018 (8)
- July 2018 (15)
- June 2018 (29)
- May 2018 (15)
- April 2018 (11)
- March 2018 (19)
- February 2018 (6)
- January 2018 (11)
- December 2017 (5)
- November 2017 (12)
- October 2017 (7)
- September 2017 (8)
- August 2017 (6)
- July 2017 (11)
- June 2017 (8)
- May 2017 (10)
- April 2017 (5)
- March 2017 (7)
- February 2017 (1)
- January 2017 (8)
- December 2016 (3)
- November 2016 (2)
- October 2016 (18)
- September 2016 (8)
- August 2016 (5)
- July 2016 (4)
- June 2016 (10)
- May 2016 (4)
- April 2016 (5)
- March 2016 (4)
- February 2016 (12)
- January 2016 (6)
- December 2015 (4)
- November 2015 (6)
- October 2015 (6)
- September 2015 (5)
- August 2015 (8)
- July 2015 (7)
- June 2015 (9)
- May 2015 (1)
- April 2015 (4)
- March 2015 (13)
- January 2015 (6)
- December 2014 (7)
- November 2014 (3)
- October 2014 (2)
- September 2014 (11)
- August 2014 (6)
- July 2014 (9)
- June 2014 (11)
- May 2014 (11)
- April 2014 (9)
- March 2014 (3)
- February 2014 (3)
- January 2014 (5)
- December 2013 (9)
- November 2013 (4)
- October 2013 (7)
- September 2013 (3)
- August 2013 (9)
- July 2013 (7)
- June 2013 (4)
- May 2013 (8)
- April 2013 (4)
- March 2013 (2)
- February 2013 (3)
- January 2013 (9)
- December 2012 (13)
- November 2012 (5)
- October 2012 (7)
- September 2012 (4)
- August 2012 (6)
- July 2012 (4)
- June 2012 (3)
- May 2012 (5)
- April 2012 (7)
- March 2012 (2)
- February 2012 (5)
- January 2012 (7)
- December 2011 (5)
- November 2011 (7)
- October 2011 (6)
- September 2011 (6)
- August 2011 (5)
- July 2011 (2)
- June 2011 (8)
- May 2011 (12)
- April 2011 (4)
- March 2011 (12)
- February 2011 (8)
- January 2011 (13)
- December 2010 (17)
- November 2010 (12)
- October 2010 (14)
- September 2010 (11)
- August 2010 (20)
- July 2010 (14)
- June 2010 (7)
- May 2010 (1)
- January 2010 (2)
- November 2009 (2)
- October 2009 (1)
- September 2009 (1)
- May 2009 (1)
- February 2009 (1)
- January 2009 (1)
- December 2008 (1)