RECENT BLOG NEWS

Happy Holidays!

The wolfSSL holiday release is available for download!

This release includes more compatibility layer expansions, updates to the version of open source projects supported, post quantum additions, and new hardware port additions to name some of what was included. As well as 2 vulnerabilities fixed in the release bundle. 

A major performance upgrade was added to wolfSSL SP C implementation for ECC. In some cases increasing the performance with the C implementation by over 20%. SP (single precision) performance is turned on by using the enable option –enable-sp.

New Feature Additions

Ports

• Curve25519 support with NXP SE050 added
• Renesas RA6M4 support with SCE Protected Mode and FSP 3.5.0
• Renesas TSIP 1.14 support for RX65N/RX72N

Post Quantum

• Post quantum resistant algorithms used with Apache port
• NIST round 3 FALCON Signature Scheme support added to TLS 1.3 connections
• FALCON added to the benchmarking application
• Testing of cURL with wolfSSL post quantum resistant build

Compatibility Layer Additions

• Updated NGINX port to NGINX version 1.21.4
• Updated Apache port to Apache version 2.4.51
• Add support for SSL_OP_NO_TLSv1_2 flag with wolfSSL_CTX_set_options function
• Support added for the functions
  • SSL_CTX_get_max_early_data
  • SSL_CTX_set_max_early_data
  • SSL_set_max_early_data
  • SSL_get_max_early_data
  • SSL_CTX_clear_mode
  • SSL_CONF_cmd_value_type
  • SSL_read_early_data
  • SSL_write_early_data

Fixes

PORT Fixes

• Building with Android wpa_supplicant and KeyStore
• Setting initial value of CA certificate with TSIP enabled
• Cryptocell ECC build fix and fix with RSA disabled 
• IoT-SAFE improvement for Key/File slot ID size, fix for C++ compile, and fixes for retrieving the public key after key generation

Math Library Fixes

• Check return values on TFM library montgomery function in case the system runs out of memory. This resolves an edge case of invalid ECC signatures being created.
• SP math library sanity check on size of values passed to sp_gcd.
• SP math library sanity check on exponentiation by 0 with mod_exp
• Update base ECC mp_sqrtmod_prime function to handle an edge case of zero
• TFM math library with Intel MULX multiply fix for carry in assembly code

Improvements/Optimizations

Build Options and Warnings

• Bugfix: could not build with liboqs and without DH enabled
• Build with macro NO_ECC_KEY_EXPORT fixed
• Fix for building with the macro HAVE_ENCRYPT_THEN_MAC when session export is enabled
• Building with wolfSentry and HAVE_EX_DATA macro set

Math Libraries

• Improvement for performance with SP C implementation of montgomery reduction for ECC (P256 and P384) and SP ARM64 implementation for ECC (P384)
• With SP math handle case of dividing by length of dividend
• SP math improvement for lo/hi register names to be used with older GCC compilers

Vulnerabilities

• [Low]  Potential for DoS attack on a wolfSSL client due to processing hello packets of the incorrect side. This affects only connections using TLS v1.2 or less that have also been compromised by a man in the middle attack. Thanks to James Henderson, Mathy Vanhoef, Chris M. Stone, Sam L. Thomas, Nicolas Bailleut, and Tom Chothia (University of Birmingham, KU Leuven, ENS Rennes for the report.
• [Low] Client side session resumption issue once the session resumption cache has been filled up. The hijacking of a session resumption has been demonstrated so far with only non verified peer connections. That is where the client is not verifying the server’s CA that it is connecting to. There is the potential though for other cases involving proxies that are verifying the server to be at risk, if using wolfSSL in a case involving proxies use wolfSSL_get1_session and then wolfSSL_SESSION_free when done where possible. If not adding in the session get/free function calls we recommend that users of wolfSSL that are resuming sessions update to the latest version (wolfSSL version 5.1.0 or later). Thanks to the UK’s National Cyber Security Centre (NCSC) for the report.

A full list of what was changed can be found in the wolfSSL ChangeLog (https://www.wolfssl.com/docs/wolfssl-changelog/).

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

This webinar will provide attendees with the basics and best practices needed to get started using the wolfSSL TLS library in products and projects into 2022. Topics will include a brief overview of TLS 1.3, wolfSSL package structure, how to build wolfSSL, running the wolfCrypt cryptography test and benchmark applications, wolfSSL basic API usage, tips on debugging, and more. Bring your questions for the Q&A session to follow!

Watch the webinar here: How to Get Started with wolfSSL in 2022

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

We’re pleased to announce that we’ve added support for SNI and TLSx options for CMake builds in wolfSSL v5.0.0! Server Name Indication (SNI) is useful when a server hosts multiple “virtual” servers at a single underlying network address. It may be desirable for clients to provide the name of the server which it is contacting. 

For more details, visit our blog post on using SNI with TLS here: https://www.wolfssl.com/ssl-termination-and-ssl-inspection-with-wolfssl-sni/

More information on building wolfSSL and configuring options can be found in the wolfSSL manual.

Access the wolfSSL GitHub page here: https://github.com/wolfSSL/wolfssl
Need more? Subscribe to our YouTube channel for access to wolfSSL webinars!

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 v5.0.0 includes an added build option to configure wolfSSL with the alternate certificate chain feature enabled! Default wolfSSL behavior is to require validation of all presented peer certificates. This also allows loading intermediate Certificate Authorities (CA’s) as trusted and ignoring no signer failures for CA’s up the chain to root. Enabling alternate certificate chain mode only requires that the peer certificate validate to a trusted CA. 

The newly added build improvement allows the option --enable-altcertchains to be appended to the ./configure script to build the wolfSSL library with alternate certificate chain mode enabled.

More information on building wolfSSL can be found in the wolfSSL manual.

Access the wolfSSL GitHub page here: https://github.com/wolfSSL/wolfssl
Need more? Subscribe to our YouTube channel for access to wolfSSL webinars!

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 v5.0.0 includes an added build option for use with our portable command-line utility product, wolfCLU! wolfCLU (Command Line Utility) is backed by the best-tested crypto using wolfCrypt and it can make use of FIPS builds with wolfSSL. You can download wolfCLU on Github today for use with the wolfSSL embedded SSL/TLS library!

This added build option allows the option –enable-wolfclu to be appended to the ./configure script to customize how the wolfSSL library is built.

For more information, check out our blog on wolfCLU here: https://www.wolfssl.com/know-command-line-utility/

More information on building wolfSSL can be found in the wolfSSL manual.

Access the wolfSSL GitHub page here: https://github.com/wolfSSL/wolfssl
Need more? Subscribe to our YouTube channel for access to wolfSSL webinars!

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

We are excited to announce wolfSSL’s support for the NXP SE050. The wolfSSL SE050 port supports a variety of algorithms including: SHA, SHA2-224, SHA2-256, SHA2-384, SHA2-512, AES-CBC, AES-ECB, ECDSA, ECDHE and most notably ED25519 / CURVE25519.

In the tested configuration a Raspberry Pi 2b was connected to the SE050 dev kit through a header board. Please refer to this guide if interested in replicating hardware configuration (https://www.nxp.com/docs/en/application-note/AN12570.pdf).

Below are hardware accelerated benchmarks using the NXP SE050:

If you have an interest in using wolfSSL with this board, please see:
https://github.com/wolfSSL/wolfssl/tree/master/wolfcrypt/src/port/nxp

Additionally, wolfSSL also provides support for the latest version of the TLS protocol, TLS 1.3! Find more information about TLS 1.3 here: https://www.wolfssl.com/docs/tls13/

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

lwIP (lightweight IP) is as the name suggests, a lightweight Open Source networking stack that is used in a lot of embedded systems. wolfSentry is a relatively new product by wolfSSL that provides a lightweight IDPS (Intrusion Detection and Prevention System). Of course, together the two should pair quite nicely, so the team at wolfSSL have created an example of how to do this.

The example uses Docker to create four containers and a specific virtual network so that the example configuration works as expected. One of the containers is a simple echo server and the other three are clients that the rules are designed to allow or deny.

The callback hooks in lwIP allow for easy integration and the example shows how to integrate for TCP/IP filtering, MAC address filtering and ICMP ping filtering. It is of course possible to filter other protocols and if you need advice on how to do such integrations the team at wolfSSL are here to help.

This example is freely available in the “examples” directory of the wolfSentry source here: https://github.com/wolfSSL/wolfsentry/tree/master/examples/Linux-LWIP

Further examples including STM32 with FreeRTOS and lwIP are coming soon. So watch this space!

Need more? Subscribe to our YouTube channel for access to wolfSSL webinars!
Love it? Star us 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.

We have recently become aware of a team of researchers at R.C. ATHENA and Monash University that have completed yet another post-quantum integration of wolfSSL. Their implementations can be found at https://gitlab.com/g_tasop/ . There, you will find two projects, “PQ WolfSSL for PC” and “PQ WolfSSL for embedded”. The team discusses some of their findings regarding performance in their paper which can be found at https://eprint.iacr.org/2021/1553.pdf. They integrate the KYBER and SABER KEMs as well as Dilithium and FALCON authentication schemes.

We would like to thank the team for picking wolfSSL and highlight a particular passage from their paper:

“Regarding TLS open-source solutions for embedded systems, the most famous and widely used implementations are: Mbed TLS [3] and wolfSSL [8, 9]. With Mbed TLS lacking support for TLS 1.3, wolfSSL is the only option to be adopted in this paper’s research work.”

I would also like to highlight another wise passage in their paper:   

“…in most realistic embedded devices usage scenarios the embedded system acts as a client, connected to a powerful server…”

We at wolfSSL agree and this is why we chose to implement FALCON. It is an authentication scheme that does not perform as well for key generation and signing, but does extremely well for the verification operation; even faster than currently standardized algorithms. In IOT server-only (non-mutual) authentication is more typical. During practical experimentation, high performance hardware can offset signing operation speeds while during  verification on embedded systems, FALCON’s inherent speed can offset the performance of the hardware.

If you are interested, we encourage you to download and read the paper as it is quite unique. Here is a quick summary of some of their conclusions:

• The KEM algorithms provide similar performance to already standardized algorithms.
• The largest impact on performance is introduced by the authentication schemes.
• In terms of energy consumption, it is shown that the average current consumption is independent of PQ algorithms, since it is probably dominated by the communication transmission cost.
• If your signer is going to be resource constrained, use Dilithium, but in IOT use cases, it is more likely that your verifier is going to be resource constrained. In this case use FALCON.

Here at wolfSSL, we are here to support you and your IOT efforts; even in a post-quantum world!

Need more? Subscribe to our YouTube channel for access to wolfSSL webinars!
Love it? Star us 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.

TLDR:  wolfSSL can run over CAN Bus.  This means wolfSSL can secure CAN Bus, which is typically insecure.  As such, you can now authenticate over CAN Bus and encrypt over CAN Bus.

The CAN (Controller Area Network) bus is a common data bus used in vehicles for onboard microcontrollers to communicate to each other. Modern vehicles have dozens of microcontrollers inside them and the usage of this technology is only going to grow in road vehicles as newer safety standards come into effect. Vehicle computers are becoming rather powerful and there have already been instances in the media of these computers being remotely hacked. Security, therefore, will become an important part of CAN bus communication over the coming years.

Part of the downside of the CAN bus protocol is that it only supports a payload of up to 8 bytes per packet, so there are layers on top of this to add flow control and packet headers so that larger packets can be reliably sent. One of the most common of these is ISO-TP (ISO 15765-2), which is regularly used for things such as OBD-2 diagnostic messaging.

A great thing about ISO-TP is that it allows us to send packets of up to 4KB and a great thing about wolfSSL is that you can hook it into pretty much anything with a data send and receive function. We have therefore created an example of how to hook wolfSSL into ISO-TP and use this over a CAN bus. This example can be found at https://github.com/wolfSSL/wolfssl-examples/tree/master/can-bus. This is a simple echo client and server which will negotiate a TLS handshake and then send / receive encrypted messages. The Linux kernel has a built-in virtual CAN bus as documented in the README, but you can use a real CAN bus to try this on. For example, here is one I made earlier between my laptop and a Raspberry Pi 3A:

Using this setup the example works as below:

And that is it! The code is relatively simple to go through but feel free to contact us for more information. Look out for more CAN bus security tools from wolfSSL in the future.

Need more? Subscribe to our YouTube channel for access to wolfSSL webinars!
Love it? Star us 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.

We’re happy to announce that we’ve added support for Renesas TSIP v1.13 on RX72N in wolfSSL v5.0.0! The RX72N MCU is the flagship model of RX series, using a 32-bit RX72N 240 MHz microcontroller.Using the TSIP driver, wolfSSL can offload supported cryptographic and TLS operations to the underlying Renesas hardware for increased performance.

If you have an interest in using wolfSSL with this MCU, check out our benchmark page about RX72N here: https://www.wolfssl.com/docs/benchmarks/

Check out our blog on wolfSSL Renesas TSIP support here: https://www.wolfssl.com/renesas-tsip-support/

More information on using wolfSSL in combination with Renesas and wolfSSL’s support for Renesas can be found here: https://www.wolfssl.com/docs/renesas/

You can access the GitHub page to wolfSSL here: https://github.com/wolfSSL/wolfssl

Need more? Subscribe to our YouTube channel for access to wolfSSL webinars!
Love it? Star us 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.