RECENT BLOG NEWS

wolfSSL's embedded SSL/TLS library has included support for TLS 1.3 since early releases of the TLS 1.3 draft. Since then, wolfSSL has remained up-to-date with the TLS 1.3 specification. In this post, the major upgrades of TLS 1.3 from TLS 1.2 are outlined below:

TLS 1.3

This protocol is defined in RFC 8446. TLS 1.3 contains improved security and speed. The major differences include:

• The list of supported symmetric algorithms has been pruned of all legacy algorithms. The remaining algorithms all use Authenticated Encryption with Associated Data (AEAD) algorithms.
• A zero-RTT (0-RTT) mode was added, saving a round-trip at connection setup for some application data at the cost of certain security properties.
• Static RSA and Diffie-Hellman cipher suites have been removed; all public-key based key exchange mechanisms now provide forward secrecy.
• All handshake messages after the ServerHello are now encrypted.
• Key derivation functions have been re-designed, with the HMAC-based Extract-and-Expand Key Derivation Function (HKDF) being used as a primitive.
• The handshake state machine has been restructured to be more consistent and remove superfluous messages.
• ECC is now in the base spec  and includes new signature algorithms. Point format negotiation has been removed in favor of single point format for each curve.
• Compression, custom DHE groups, and DSA have been removed, RSA padding now uses PSS.
• TLS 1.2 version negotiation verification mechanism was deprecated in favor of a version list in an extension.
• Session resumption with and without server-side state and the PSK-based ciphersuites of earlier versions of TLS have been replaced by a single new PSK exchange.

More information about the TLS 1.3 protocol can be found here: https://www.wolfssl.com/docs/tls13/. Additionally, please contact facts@wolfssl.com for any questions.

The wolfSSL embedded SSL/TLS library has support for PCKS#11! The PKCS#11 standard defines an API for using cryptographic tokens. The API added to wolfSSL will work with the most commonly used cryptographic object types (RSA keys, X.509 Certificates, DES/Triple DES keys, etc.) and all the functions needed to use, create, modify and delete those objects.

Using wolfSSL on your application or your device will now allow you to utilize PKCS#11 for access to hardware security modules, smart cards, and other cryptographic tokens. Interoperability of wolfSSL's PKCS#11 implementation has been tested against both OpenCryptoki, and SoftHSM2.

To build wolfSSL with PKCS#11 support, the library needs to be downloaded and then built with a specific configure flag or macro define. The library can be downloaded from the wolfSSL website, located here: https://www.wolfssl.com/download/. The steps to build and install with PKCS#11 are detailed below:

# From within wolfSSL's root directory
./autogen.sh
./configure --enable-pkcs11
make
sudo make install

If the library is being built in a non-standard environment or autotools are not being used, then the macros HAVE_PKCS11 and HAVE_WOLF_BIGINT (used for some fastmath and ECC operations) need to be defined.

Documentation and more information about the PKCS#11 additions to wolfSSL  arelocated within on the doxygen pages, here: https://www.wolfssl.com/doxygen/group__PKCS11.html

More information about the new release of wolfSSL v3.15.7 can be found here: https://www.wolfssl.com/wolfssl-3-15-7-now-available/

Wikipedia article on PKCS#11: https://en.wikipedia.org/wiki/PKCS_11

For more information about wolfSSL and PKCS#11 use contact us at facts@wolfssl.com.

The wolfSSL embedded SSL/TLS library is highly portable, and easy to build on many different platforms. One of these platforms includes the Yocto Project, a project that assists developers with creating Linux-based systems on any architecture.

wolfSSL also includes many recipes and projects that make it easy to build on various platforms, and is maintained in the meta-wolfssl GitHub repository. This repository contains both Yocto and OpenEmbedded recipes for wolfSSL products (wolfSSL, wolfSSH, wolfMQTT, wolfTPM) and wolfSSL example applications. It also includes .bbappend files, which can be used to configure the cURL open-source project with support with the wolfSSL library.

More information about Yocto Linux and wolfSSL can be found in the meta-wolfssl readme, located in the GitHub repository here: https://github.com/wolfSSL/meta-wolfssl/blob/master/README.md

For more information on using wolfSSL, please contact facts@wolfssl.com.

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.

Because there is a FIPS 140-2 validated version of wolfCrypt, this means that wolfSSL not only has support for the most current version of TLS, but it also has the encryption backbone to support your FIPS 140-2 needs if required.

Some key benefits of combining TLS 1.3 with FIPS validated software include:

1. Software becomes marketable to federal agencies - without FIPS, a federal agency is not able to use cryptographic-based software
2. Single round trip
3. 0-RTT (a mode that enable zero round trip time)
4. After Server Hello, all handshake messages are encrypted.

And much more! For more information regarding the benefits of using TLS 1.3 or using the FIPS validated version of wolfCrypt, check out wolfSSL's TLS 1.3 Protocol Support and our wolfCrypt FIPS page.

FIPS 140-2 is a government validation that certifies that an encryption module has successfully passed rigorous testing and meets high encryption standards as specified by NIST. For more information or details on FIPS 140-2, it may be helpful to view this Wikipedia article: https://en.wikipedia.org/wiki/FIPS_140-2

For more details about wolfSSL, TLS 1.3, or if you have any other general inquiries please contact facts@wolfssl.com

To find out more about FIPS, check out the NIST FIPS publications or contact fips@wolfssl.com

Release 3.15.7 of wolfSSL Async has bug fixes and new features including:

Summary

• All wolfSSL v3.15.7 fixes and features.
• Fixes for additional static analysis warnings and async edge cases (https://github.com/wolfSSL/wolfssl/pull/2003).
• Added QAT v1.7 driver support including support for QAT 8970 hardware.
• Added QAT SHA-3 support.
• Added QAT RSA Key Generation support.
• Added support for new usdm memory driver.
• Added support for detecting QAT version and features.
• Added `QAT_ENABLE_RNG` option to disable QAT TRNG/DRBG.
• Added alternate hashing method to cache all updates (avoids using partial updates).

Here are the latest benchmarks with various build configurations:

CPU: ./configure --enable-keygen --enable-sha3
SP/AESNI: ./configure --enable-sp --enable-sp-asm --enable-aesni --enable-intelasm --enable-intelrand --enable-keygen --enable-sha3
QAT: ./configure --with-intelqa=../QAT1.7 --enable-asynccrypt --enable-keygen --enable-sha3
Nitrox V: ./configure --with-cavium-v=../CNN55XX-SDK --enable-asynccrypt

If you are interested in evaluating the wolfSSL Asynchronous support for Intel QuickAssist or Cavium Nitrox, please email us at facts@wolfssl.com.

Are you looking for an SSL/TLS library which will seamlessly integrate into your bare metal or No-OS environment? If so, continue reading to learn why the wolfSSL lightweight SSL library is a perfect fit for such environments.

wolfSSL has been designed with portability and ease of use in mind, allowing developers to easily integrate it into a bare metal or operating systemless environment. As a large percentage of wolfSSL users are running the library on small, embedded devices, we have added several abstraction layers which make tying wolfSSL into these types of environments an easy task.

Available abstraction layers include:

• Custom Input/Output
• Standard C library / Memory
• File system (Able to use cert/key buffers instead)
• Threading
• Operating System

In addition to abstraction layers, we have tried to keep wolfSSL’s memory usage as low as possible. Build sizes for a complete SSL/TLS stack range from 20-100kB depending on build options, with RAM usage between 1-36kB per connection.

To learn more about how to integrate wolfSSL into your environment or get more information about reducing wolfSSL’s memory usage, please see the wolfSSL Manual or contact us directly.

The wolfSSL FAQ page can be useful for information or general questions that need need answers immediately. It covers some of the most common questions that the support team receives, along with the support team's responses. It's a great resource for questions about wolfSSL, embedded TLS, and for solutions to problems getting started with wolfSSL.

To view this page for yourself, please follow this link here.

Here is a sample list of 5 questions that the FAQ page covers:

1. How do I build wolfSSL on ... (*NIX, Windows, Embedded device) ?
2. How do I manage the build configuration of wolfSSL?
3. How much Flash/RAM does wolfSSL use?
4. How do I extract a public key from a X.509 certificate?
5. Is it possible to use no dynamic memory with wolfSSL and/or wolfCrypt?

Have a  question that isn't on the FAQ? Feel free to email us at support@wolfssl.com.

Happy Holidays! wolfSSL release 3.15.7 is now available!

The holiday release of the wolfSSL embedded SSL/TLS library contains many feature additions, bug fixes, and improvements. Some of these changes include improved API documentation, RSA-verify-only and RSA-public-key-operations-only builds, and several new port additions. More details about what is included with the new version of wolfSSL are listed below.

• New Feature Additions And Ports:
• Support for Espressif ESP-IDF development framework
• PKCS#7 support for generating and verify bundles using a detached signature.
• Port update for Micrium uC/OS-III
• Feature to adjust max fragment size post handshake when compiled with the macro WOLFSSL_ALLOW_MAX_FRAGMENT_ADJUST
• The addition of multiple languages in wolfSSL’s bundled examples can cause problems for embedded devices that can not handle the special characters. Having NO_MULTIBYTE_PRINT defined compiles out code used for printing the special characters.
• RSA verify only (--enable-rsavfy) and RSA public only (--enable-rsapub) builds added. These are builds that can be used with --enable-cryptonly that compile out portions of RSA code. Giving the option for an even smaller build of wolfSSL in the case that only RSA public key operations or only RSA verify operations are needed.

One of the many new exciting updates to existing wolfSSL features was the support for the Intel QuickAssist v1.7 driver being added! This enables wolfSSL to be used in asynchronous mode with newer Intel hardware for a massive performance gain over the previous driver. In addition to the driver update, support for RSA key generation and SHA-3 support was added to the wolfSSL QuickAssist port. The following is a list of some of the other notable additional updates and fixes in the release:

• Fix for Xcode build with iPhone simulator on i386
• Fix for building the wolfSSL library with AES-CBC disabled and the opensslextra compatibility layer enabled
• Updates to sniffer for showing session information and handling split messages across records
• Updates for Doxygen documentation, including PKCS#11 API and more
• Enhancements to test cases for increased code coverage
• Updates to VxWorks port for use with Mongoose, including updates to the OpenSSL compatibility layer
• Updating --enable-armasm build for ease of use with autotools
• Lots of improvements were made for ease of use with Yocto. The INSTALL file bundled with wolfSSL has been updated as part of this to help guide users through a Yocto build of wolfSSL.
  

Some updates and minor fixes were made to the TLS 1.3 code in wolfSSL. Keeping our industry leading TLS 1.3 implementation robust and up to date. These fixes included:

• Updates to internal code checking TLS 1.3 version with a connection
• Removing unnecessary extended master secret from ServerHello if using TLS 1.3
• Fix for TLS v1.3 HelloRetryRequest to be sent immediately and not grouped

This release of wolfSSL also included a fix for 1 security vulnerability. It was a medium level fix for a potential cache attack with a variant of Bleichenbacher’s attack. Earlier versions of wolfSSL leaked PKCS #1 v1.5 padding information during private key decryption that could lead to a potential padding oracle attack. It is recommended that users update to the latest version of wolfSSL if they have RSA cipher suites enabled and have the potential for malicious software to be ran on the same system that is performing RSA operations. Users that have only ECC cipher suites enabled and are not performing RSA PKCS #1 v1.5 Decryption operations are not vulnerable. Users with TLS 1.3-only connections are not vulnerable to this attack. Thanks to Eyal Ronen (Weizmann Institute), Robert Gillham (University of Adelaide), Daniel Genkin (University of Michigan), Adi Shamir (Weizmann Institute), David Wong (NCC Group), and Yuval Yarom (University of Adelaide and Data61) for the report. The paper for further reading on the attack along with more details can be found at https://eprint.iacr.org/2018/1173.pdf. To view or apply a patch of the changes this is the exact PR on github with the fix: https://github.com/wolfSSL/wolfssl/pull/1950.