Month: December 2021

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!

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!

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!

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:

Algorithm	Performance
TRNG	0.114 KB/s
ECDH - Shared Secret	Avg 169.276 ms
ECDSA - Sign	Avg 102.899 ms
ECDSA - Verify	Avg 102.920 ms
ED25519 - Sign	Avg 261.323 ms
ED25519 - Verify	Avg 143.541 ms
CURVE25519 agree	Avg 157.089 ms

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/
For more information, please contact facts@wolfssl.com.

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!

Contact us at facts@wolfssl.com for any questions or comments.

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!

Contact us at facts@wolfssl.com for any questions or comments.

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!

Contact us at facts@wolfssl.com for any questions or comments.

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!

One of the highlights of our wolfSSL library is its exceptional portability, which allows wolfSSL’s team of engineers to frequently add new ports!

We’re happy to announce that we’ve added support for pyOpenSSL in wolfSSL v5.0.0! We have integrated wolfSSL with the pyOpenSSL project, which allows for the use of pyOpenSSL with our SSL/TLS library, wolfSSL. pyOpenSSL is a thin OpenSSL wrapper for python.

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!

In a recent blog post we showed the details of a quantum-safe connection using wireshark. This post is to announce that now you can also do the exact same thing by following instructions provided by our friends at the Open Quantum Safe group. They have generously hosted a wireshark integration via docker that will display algorithm names using both their naming convention as well as wolfSSL’s.

The default naming convention is OQS’s but if you want to use wolfSSL’s naming convention, simply clone their repo at `git@github.com:open-quantum-safe/oqs-demos.git` and in the `wireshark/Dockerfile` change the following line:

ARG QSC_SSL_FLAVOR="oqs"

… to …

ARG QSC_SSL_FLAVOR="wolfssl"

… and then follow the rest of the instruction in `wireshark/README.md` and `wireshark/USAGE.md`. We at wolfSSL would like to thank our friends at the OpenQuantumSafe project for their hard work!

For information about wolfSSL and power usage contact facts@wolfssl.com.