Category: wolfSSL/ wolfCrypt

Version 5.7.0 of wolfSSL is now available! Many new and exciting features were added in this release. Near the top of that list is the addition of our Kyber implementation along with other post quantum algorithm support. This empowers you to future-proof your security measures, ensuring robust protection against evolving threats. In addition to introducing new features, we’ve addressed three vulnerabilities in this release. Two of these fixes target vulnerabilities related to row hammer attacks, while the other addresses a TLS 1.3 server-side issue. We take security seriously, and you can find more information about these fixes on our vulnerability page (https://www.wolfssl.com/docs/security-vulnerabilities/).

A full list of fixes, additions, and optimizations can be found in the ChangeLog, here are some of the highlights!

• Experimental framework for using wolfSSL’s XMSS and LMS implementation. Explore and test advanced cryptographic techniques within the wolfSSL ecosystem. (PR 7161 & PR 7283)
• Experimental wolfSSL Kyber implementation and assembly optimizations, enabled with –enable-experimental –enable-kyber. Proactively prepare for quantum computing threats with Kyber integration and assembly optimizations. (PR 7318)
• The Linux kernel module now supports registration of AES-GCM, AES-XTS, AES-CBC, and AES-CFB with the kernel cryptosystem through the new –enable-linuxkm-lkcapi-register option, enabling automatic use of wolfCrypt implementations by the dm-crypt/luks and ESP subsystems. In particular, wolfCrypt AES-XTS with –enable-aesni is faster than the native kernel implementation.
• BER content streaming support for PKCS7_VerifySignedData and sign/encrypt operations. Handles large data streams more effectively during PKCS7 operations. (PR 6961 & 7184)
• Microchip PIC24 support and example project expands compatibility, facilitating integration with Microchip’s PIC24 microcontrollers. (PR 7151)
• AutoSAR shim layer provides a standardized interface for RNG, SHA256, and AES (PR 7296)
• wolfSSL_CertManagerUnloadIntermediateCerts API to clear intermediate certs added to certificate store (PR 7245)

This is a small subset of the optimizations and enhancements made in the last release are as follows:

• Remove obsolete user-crypto functionality and Intel IPP support (PR 7097)
• Support for RSA-PSS signatures with CRL use (PR 7119)
• Enhancement for AES-GCM use with Xilsecure on Microblaze (PR 7051)
• Improve liboqs integration adding locking and init/cleanup functions (PR 7026)
• Update Arduino example TLS Client/Server and improve support for ESP32 (PR 7304 & 7177)
• Improvements for Espressif use; SHA HW/SW selection and use on ESP32-C2/ESP8684, wolfSSL_NewThread() type, component cmake fix, and update TLS client example for ESP8266 (PR 7081, 7173, 7077, 7148, 7240)

Visit our download page or wolfSSL GitHub repository to download the latest release. If you have questions about any of the above, feel free to email us at facts@wolfSSL.com or call us at +1 425 245 8247.

Download wolfSSL Now

Getting started with wolfSSL has never been easier. We’ve recently updated our library as published on the Arduino libraries site, listed in the “Communications” section:

https://www.arduino.cc/reference/en/libraries/wolfssl/

To use wolfSSL in the Arduino IDE, download the latest IDE version from arduino.cc and follow the installation instructions.

Note that if you used any version of wolfSSL prior to v5.6.6.Arduino.1, those versions have been removed from the Arduino registry as they were not Official wolfSSL Arduino releases.

To install wolfSSL, click on Tools… Manage Libraries:

Type wolfssl in the search box, then press the Install button.

Additional details can be found in the Arduino documentation for installing libraries for V1 or using the Arduino IDE V2 installation method.

When the sketch is opened, click on the “Select Board” dropdown:

In the case of Windows, click on the COM port that has your device, here for COM36:

Enter part of name to more quickly find the desired board selection:

Click on the desired board and click the OK button.

For Arduino brand and compatible boards, the Arduino IDE will prompt if libraries are needed to be installed:

There are two main examples for wolfSSL: a TLS client and a TLS server. The most recent code can be found in the IDE/Arduino directory on GitHub.

To use the examples from the Arduino IDE Library, click on File… Examples. See the wolfSSL sample sketches in the “Examples from Custom Libraries” at the bottom of the list:

Note that both the Client and Server examples need a network connection. Most boards will need to have WiFi parameters set for this. See the beginning of the sketch for setting a file (typically outside the scope of any GitHub repository, to be kept private):

Otherwise if you are not using a private file, the values can be entered directly into the source code, shown here for your_SSID and your_PASSWORD:

Once the sketch is loaded and a board (and serial port) are selected, simply press the upload button as with any other Arduino sketch.

If using the Server example, make note of the IP address assigned. By default a DHCP address is requested, so the value will be specific to the SSID / Access Point.

If using the Arduino Client, not only do the WiFi settings need to be assigned, but also the Server address WOLFSSL_TLS_SERVER_HOST value to connect to, shown here for an example address of 192.168.1.39

Both the Arduino Client and Server sketches can of course be used to communicate with the wolfSSL executables, found in the examples/client and examples/server directories. These are built automatically when running make from the root of the wolfSSL clone:

./configure --enable-all
make clean
make && make test
./examples/client/client -h 192.168.1.39 -p 11111

Keep in mind that workstation examples may need firewall rules and/or anti-virus adjusted when communicating with external embedded devices such as the Arduino boards. The wolfSSL TLS examples typically use port 11111.

Want to customize the wolfSSL settings? See the user_settings.h file in

C:\Users\%USERNAME%\Documents\Arduino\libraries\wolfssl\src

It’s best to not directly include the wolfSSL user_settings.h file in your code. When including the library, there’s a settings.h file that will automatically include the user_settings.h file as appropriate, along with making some default environment settings.

See the documentation for more details on settings. For embedded targets such as Arduino, all of the settings are the #define values in the user_settings.h file.

Details on how we publish wolfSSL to Arduino can be found in our wolfSSL/IDE/ARDUINO GitHub directory. If you have a local clone of wolfSSL, you can use the wolfssl-arduino.sh script to install your own latest version of wolfSSL directly to your Arduino libraries directory like this:

./wolfssl-arduino.sh INSTALL

Note that there’s only a Linux bash command. Windows users are encouraged to use WSL. See the README file for more information.

If any problems are encountered with the sketch, sometimes it can be helpful to delete the build cache directories. For Windows users, this is in the AppData directory:

C:\Users\%USERNAME%\AppData\Local\Temp\arduino\sketches

Find out more

If you have any feedback, questions, or require support, please don’t hesitate to reach out to us via facts@wolfSSL.com, call us at +1 425 245 8247, or open an issue on GitHub.

Download wolfSSL Now

The wolfSSL lightweight SSL/TLS library and underlying wolfCrypt cryptography library have included support for the NXP SE050 module since November 2021. Since that time we have been increasing compatibility with SE050 along with usage of SCP03 (Secure Channel Protocol 03) authentication. To help users get started with TLS usage, we also have two example client applications available for use and reference.

wolfSSL TLS users can use the wolfSSL_CTX_use_PrivateKey_Id() API to instruct wolfSSL to use a private key located in the SE050 at a specific key ID. This would replace calls to wolfSSL_CTX_use_PrivateKey_file() or wolfSSL_CTX_use_PrivateKey_buffer(), giving applications enhanced security by allowing the private key to be stored (and optionally generated) inside the SE050 module.

#include <wolfssl/ssl.h>
int wolfSSL_CTX_use_PrivateKey_Id(WOLFSSL_CTX* ctx, const unsigned char* id,
    long sz, int devId);

For access to wolfSSL_CTX_use_PrivateKey_Id(), wolfSSL needs to be compiled with WOLF_PRIVATE_KEY_ID defined. This can be passed through configure via CFLAGS, for example:

cd wolfssl-X.X.X
./configure <options> CFLAGS=”-DWOLF_PRIVATE_KEY_ID”
make
sudo make install

TLS Client Demos Using SE050

wolfSSL has two example SSL/TLS client applications that demonstrate how users can leverage SE050 underneath wolfSSL’s SSL/TLS implementation. These examples are set up to be easily run on a Raspberry Pi environment with attached NXP EdgeLock SE050 Development Kit.

Available examples are included in the “wolfssl-examples” GitHub repository under the SE050 subdirectory and include:

1. wolfSSL SSL/TLS Client Example

   This example demonstrates a simple SSL/TLS client, using hardware-based cryptography supported inside the SE050. It loads and uses a certificate and private key from C arrays/buffers. For a more advanced demo which uses the private key directly from the SE050, see the following example. For details, see the example README.md, or wolfssl_client.c file.

2. wolfSSL SSL/TLS Client Example with Cert and Private Key in SE050

   This example demonstrates a simple SSL/TLS client, using hardware-based cryptography supported inside the SE050. It loads and uses a certificate and private key from C arrays/buffers into the SE050, then does all private key operations inside the SE050 for the TLS private key, based on a key ID. For details, see the example README.md or wolfssl_client_cert_key.c.

Resources

For more details on using wolfSSL or wolfCrypt with the NXP SE050, see one of the following links or email us at facts@wolfSSL.com. The wolfSSL embedded SSL/TLS library supports up to the most current TLS 1.3 and DTLS 1.3 protocol standards, has been optimized for performance and footprint size, and also provides easy paths forward for validation and certification requirements (FIPS 140-3, FIPS 140-3 (in progress), CAVP, DO-178C).

Blog: wolfSSL NXP SE050 Support and Benchmarks
Blog: wolfSSL Support for NXP SE050 with SCP03
Documentation: wolfSSL NXP SE050 Support (README_SE050.md)
Examples: wolfSSL NXP SE050 Examples (README.md)
Dev Kits: NXP EdgeLock SE050 Development Kits
SE050 Product Page: EdgeLock SE050: Plug & Trust Secure Element Family

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

Download wolfSSL Now

wolfSSL 5.6.6 introduces the option for DTLS 1.3 servers to skip the cookie exchange on a session resumption. The cookie exchange is a security mechanism employed during the resumption of a DTLS 1.3 session. When a client wants to resume a previous DTLS 1.3 session, it sends a session ticket to the server, which may respond by issuing a “cookie” to the client. This cookie serves as a challenge-response mechanism, requiring the client to present it during the resumption attempt. The purpose of this exchange is for the client to demonstrate reachability at their apparent network address. In some cases, you may choose to skip the cookie exchange if the client presents a valid ticket or pre-shared key (PSK).

To resume a DTLS 1.3 session without the cookie exchange:

• Compile wolfSSL with WOLFSSL_DTLS13_NO_HRR_ON_RESUME defined. Either:
  • When compiling with configure add CPPFLAGS=-DWOLFSSL_DTLS13_NO_HRR_ON_RESUME
  • When compiling with user settings add #define WOLFSSL_DTLS13_NO_HRR_ON_RESUME
• Call wolfSSL_dtls13_no_hrr_on_resume(ssl, 1) on the WOLFSSL object to disable the cookie exchange on resumption
• Continue like with a normal connection

If you have any questions about using DTLS 1.3 in wolfSSL, please contact us at facts@wolfSSL.com or call us at +1 425 245 8247.

Download wolfSSL Now

(D)TLS 1.3 support for 0.5-RTT (round trip time) data has been introduced to wolfSSL in the latest release (5.6.6). 0.5-RTT data is an optimization in (D)TLS 1.3 that significantly reduces latency and improves overall performance of application data. The full handshake requires two full round trips to start sending data while this functionality allows the server to send application data along with its final flight of handshake messages. This new addition works well with our support for early data (also known as 0-RTT data). An embedded device is able to resume a connection, send early data with its connection request, and receive a response immediately within one RTT.

    	Client                                           	Server

    	ClientHello         	-------->
                                                    	ServerHello
                                          	EncryptedExtensions
                                          	CertificateRequest
                                                 	Certificate
                                           	CertificateVerify
                                                     	Finished
                            	<--------   	0.5-RTT Application Data
    	Certificate
    	CertificateVerify
    	Finished           	-------->
    	Application Data  	<------->    	Application Data

Diagram showing 0.5-RTT data in a full TLS 1.3 handshake

If you would like to learn more about (D)TLS 1.3 in wolfSSL, please contact us at facts@wolfSSL.com or call us at +1 425 245 8247.

Download wolfSSL Now

wolfSSL prior to version 5.6.6 had a vulnerability where the (D)TLS key boundaries were not properly checked. As a result, it was possible to combine (D)TLS messages using different keys into one (D)TLS record. The most extreme edge case is that, in (D)TLS 1.3, it was possible that an unencrypted (D)TLS 1.3 record from the server containing first a ServerHello message and then the rest of the first server flight would be accepted by a wolfSSL client. In (D)TLS 1.3 the handshake is encrypted after the ServerHello but a wolfSSL client would accept an unencrypted flight from the server. This does not compromise key negotiation and authentication so it is assigned a low severity rating.

We would like to thank Johannes Wilson for the report (Sectra Communications and Linköping University). The fix for this issue is located in the following GitHub Pull Request: #7029.

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

Download wolfSSL Now

Do you have a need to capture and/or analyze TLS traffic? The wolfSSL library includes a useful tool that you can leverage. The wolfSSL sniffer can be used to capture TLS packets and even decrypt them when at least one of the keys is known. This can be done with both live and recorded PCAP traces.

This could be useful for several reasons, including:

• Analyzing Network Problems
• Detecting network misuse by internal and external users
• Monitoring network usage and data in motion
• Debugging client/server communications

The sniffer supports both TLS v1.2 and TLS v1.3. It can be integrated into any application using our sniffer API’s and it even comes with a complete working example!

See here for more detailed documentation.

Have any questions, comments, or suggestions? Contact us at facts@wolfSSL.com or call us at +1 425 245 8247.

Download wolfSSL Now

Rust support is coming to wolfSSL this year! The wolfSSL embedded TLS library is a lightweight, portable, C-language-based SSL/TLS library known for its low footprint, speed, and feature set. Users have been able to take advantage of our library not only in C but also in their Java, C#, Python, and JavaScript projects using the various wrappers we provide. This year, we’re planning to add Rust to that list.

Similar to C, Rust is a low-level programming language with direct access to hardware and memory, which will make our wolfSSL Rust Wrapper a great SSL/TLS solution for embedded and IoT development for Rust projects. The wrapper will also service Rust users with performance and/or FIPS requirements.

Are you interested in a Rust wrapper?

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

Download wolfSSL Now

Recently Espressif announced their ESP-IDF v5.2 Beta 1 on GitHub. The same day we found out about this exciting new version, we confirmed that all the wolfSSL Espressif ESP32 Examples are working in that environment. So far the “beta” looks to be well polished from our perspective. Last week, we learned about the ESP-IDF v5.2 Beta 2 on GitHub. The final release should be quite nice.

We have both core performance, benchmark, and client-server examples as well as additional examples for the ESP32.

Incorporating wolfSSL in your Espressif project has never been easier. As announced in the summer of 2023 – wolfSSL is now available in the Espressif ESP Registry of managed components: this one line adds wolfSSL to your project:

# Add wolfSSL component to existing ESP-IDF project
idf.py add-dependency "wolfssl/wolfssl"

Get Started with wolfSSL

Additional information on getting Started with wolfSSL on the Espressif environment is available on the wolfSSL GitHub repository as well as this YouTube recording:

Find out more

If you have any feedback, questions, or require support, please don’t hesitate to reach out to us via facts@wolfSSL.com or call us at +1 425 245 8247, or open an issue on GitHub.

Download wolfSSL Now