RECENT BLOG NEWS

The sniffer support for processing multiple streams concurrently using our asynchronous version of the library. Support has been added for offloading to Intel QuickAssist or Cavium Nitrox V type hardware. Additionally we support offloading to worker threads. This allows a large increase in sniffer throughput for handling the asymmetric operations.

Our sniffer tool is built into wolfSSL and allows decryption of TLS traffic where the static RSA/ECC key is know or the ephemeral key used on one side is known. We support TLS v1.2 and TLS v1.3. The sniffer tool can process pcap files previously recorded or live.

We also support using a Key Manager for protected generation and storage of ephemeral keys with TLS v1.3. This is based on the ETSI TS 103 523-3 Middlebox Security Protocol; Part 3: Enterprise Transport Security. If interested see our full library and demo here: https://github.com/wolfSSL/wolfKeyMgr

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 offer two CMSIS packs for wolfSSL to assist with quick adoption of our library into your projects.

Our STM Cube Pack

For STM32 users we offer a CMSIS pack. This is available inside the STM32CubeIDE as we are a “MadeForSTM32” project. We work closely with STM to provide a seamless integration. The integration provides a simple GUI interface to configure the library for your hardware with out of the box support for most STM32 flavors.

The pack includes an example console application for running wolfCrypt test/benchmarks and a TLS client/server.

Official ST Page: https://www.st.com/en/partner-products-and-services/i-cube-wolfssl.html

Our documentation: https://github.com/wolfSSL/wolfssl/tree/master/IDE/STM32Cube

Our Keil CMSIS Pack

For Keil MDK and uVision users we provide a CMSIS pack for wolfSSL, which includes wolfCrypt and TLS examples. This allows for quick adoption of our library into your embedded target.

Guide: https://www.wolfssl.com/docs/keil-mdk-arm/

Pack Download: https://www2.keil.com/mdk5/partnerpacks/

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

CAAM support with wolfSSL on QNX was expanded. Previously the port included i.MX6 devices now it can run on i.MX8 devices and handle AES-CTR operations in addition to the previously supported ECC, CMAC, and BLOB operations.This enhancement included some additional refactoring and robustness of the QNX resource manager in wolfSSL.

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

wolfBoot v1.12 has been released. This version introduces the support for a new signature verification algorithm, RSA3072, new test cases, a new simulated architecture to speed up the validation, and some new features to support more use cases. Here is a brief description of some of the new features in this version.

Support for encrypted incremental updates

Our delta firmware update support is designed to reduce transfer times for firmware updates. By applying a binary patch on the existing version, wolfBoot is able to update the current firmware with a special update image, a “delta” update package, which maps the difference between the current and the new version. This feature can now be combined with our symmetric, pre-shared key encryption mechanism, allowing for encrypted delta updates.

Signed binaries and numeric identifiers

It is now possible to assign an identifier to each signed image. Our sign tool accepts a new command line argument (–id N) to set a custom id for a signed payload.

Id ‘1’ is the default, and is usually the image of the application, or the OS kernel, staged by wolfBoot after verification.

Id ‘0’ is reserved for wolfBoot self-updates.

Ids 2 to 15 can be used to design custom read-only partitions, extra images and binary extensions, each one living in a different flash memory partition, or mapped to a different zone in memory.

Support for multiple public keys

wolfBoot v1.12 now supports multiple public keys that can be stored together in the designed trust anchor, into a new data structure called `keystore`.

A keystore can contain keys that are either generated, using the keygen tool like in the previous versions, or imported from a third-party provisioning mechanism.

Each key can carry different permissions, i.e. can be allowed to authenticate binary images only associated with one or more specific identifiers.

wolfBoot is our secure bootloader that relies on wolfCrypt to provide secure boot and firmware updates. It can be used to secure the boot process on any embedded system, from very resource-restricted microcontrollers up to more powerful, microprocessor-based platforms, and even on x86_64 PC-based architectures. Safe-by-design, it’s the ideal choice in safety-critical systems that need to integrate a secure bootloader.

Find out more about wolfBoot! Download the source code and documentation from our download page, or clone the repository from 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.

Join our live wolfEngine  webinar, where we introduce one of our newest products wolfEngine, a separate standalone library which links against wolfSSL (libwolfssl) and OpenSSL. wolfEngine implements and exposes an OpenSSL engine implementation which wraps the wolfCrypt native API internally. Algorithm support matches that as listed on the wolfCrypt FIPS 140-2 certificate #3389.

Learn about about what wolfEngine is, why you should care, and why wolfEngine could be the solution to all of your problems. As always bring your questions for the Q&A following the presentation.

Watch the webinar here: wolfEngine : wolfCrypt as an Engine for OpenSSL

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

The summer release of wolfMQTT, v1.14.0, is now available! This release has several bug fixes and optimizations including:

• Support post-quantum KYBER_LEVEL1 and P256_KYBER_LEVEL1 with FALCON_LEVEL1 in wolfMQTT. by @anhu #300
• Add WOLFMQTT_USE_CB_ON_DISCONNECT for CB on client disconnect by @embhorn in #302
• Fix to release connect ack props by @embhorn in #301

Check out the changelog from the download for a full list of features and fixes, or contact us at facts@wolfssl.com with any questions:

https://github.com/wolfSSL/wolfMQTT/blob/master/ChangeLog.md

While you’re there, show us some love and give the wolfMQTT project a Star!

You can download the latest release here: https://www.wolfssl.com/download/

Or clone directly from our GitHub repository: https://github.com/wolfSSL/wolfMQTT

If you are working on MQTT, or if you just have questions, don’t hesitate to contact us at facts@wolfssl.com. We’re more than happy to hear from you!

Want to talk to us face to face about wolfMQTT at Black Hat?  Come by Booth 1084!

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

DTLS 1.3 is here! wolfSSL release 5.4.0 was recently sent out and one of the exciting new features in the release was initial support for DTLS 1.3. This new protocol implementation gives improvements over the previous 1.2/1.0 versions of DTLS and compliments the TLS 1.3 implementation in wolfSSL quite nicely.

wolfSSL prides itself on our many firsts. As a Cybersecurity company we have to make sure all of our products are state of the art. As such we make sure to be proactive, so that our products are always the best they can be. Being an open source company, we like to keep our users, customers, and followers up to date on our successes.  

wolfSSL Current Firsts:

• First Open Source Dual Licensed TLS (GPLv2/Commercial)
• First TLS to adopt fuzz testing; now sporting 7 internal nightly fuzz testers and 2 external fuzz testers
• First TLS 1.2 implementation
• First DTLS 1.2 implementation
• First TLS to support quantum resistant encryption (PQC) …in 2010!  We used NTRU.
• First TLS 1.3 implementation
• First MQTT SN implementation
• First MQTT 5.0 implementation
• First IETF SUIT Secure Boot implementation 
• First TLS 1.3 Sniffer
• First DO 178 DAL A certified crypto library
• First TPM 2.0 stack designed for baremetal and embedded systems – wolfTPM

Now wolfSSL is the first to have DTLS 1.3 implementation. wolfSSL’s DTLS 1.3 implementation is not ready for commercial use, but it’s fully functional and ready for being beta-tested! As usual, you can find the code at our GitHub repo or you can download the latest beta version here.

Since its first version, DTLS aims to bring the same security guarantees as TLS, but without requiring a reliable and order-preserving underlying protocol. This means that it’s much more suitable for latency-sensitive applications that can suffer from the overhead of TCP or similar protocols. The specifications of DTLSv1.3 were published just last April (RFC 9147) and DTLSv1.3 brings all the improvements of TLS v1.3 to DTLS: faster and more secure handshake, 0-RTT resumption, modern crypto algorithms, better downgrade protection and so on. We are the first to release a working implementation. 

If you are working on DTLS, or if you just have questions, don’t hesitate to contact us at facts@wolfssl.com. We’re more than happy to hear from you!

Want to talk to us face to face about DTLS 1.3 at Black Hat?  Come by Booth 1084!

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

DTLS 1.3 is here! wolfSSL release 5.4.0 was recently sent out and one of the exciting new features in the release was initial support for DTLS 1.3. This new protocol implementation gives improvements over the previous 1.2/1.0 versions of DTLS and compliments the TLS 1.3 implementation in wolfSSL quite nicely.

Another big change to make note of in this release is that the SP math implementation was switched to be the default one. Now when running a basic configuration and not specifying a specific math implementation SP math is used. Many hardware ports and RTOS ports were also updated, one such case was that the support of NXP’s CAAM when using QNX was expanded on.

In release 5.4.0 there were 3 vulnerabilities listed as fixed in wolfSSL. Two relatively new reports, one dealing with a DTLS 1.0/1.2 denial of service attack and the other a ciphertext attack on ECC/DH operations. The last vulnerability listed was a public disclosure of a previous attack on AMD devices fixed since wolfSSL version 5.1.0. Coordination of the disclosure of the attack was done responsibly, in cooperation with the researchers, waiting for the public release of the attack details since it affects multiple security libraries.

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.

Well, the internet has been abuzz with the announcement of the four post-quantum algorithms that will move on from the NIST Post-Quantum Competition to standardization. They are:

• KYBER Key Encapsulation Mechanism
• DILITHIUM Signature Scheme
• FALCON Signature Scheme
• SPHINCS+ Signature Scheme

NIST has a very detailed report about the algorithms and some explanations which can be found here:https://nvlpubs.nist.gov/nistpubs/ir/2022/NIST.IR.8413.pdf

Its great to see that both KYBER and FALCON are among the algorithms moving on as wolfSSL has already built in support for both of them with our integration with liboqs. So what is next for wolfSSL?

Our plan is to take a 2 pronged approach.

In the near term, we will continue to leverage our integration with liboqs to quickly bring support for DILITHIUM and SPHINCS+ into wolfSSL.

While that is happening, we will also be writing our own implementations of the new algorithms that will be standardized. For our own implementations, the “harvest now, decrypt later” threat model is top of mind and so we will begin with KYBER. We will then move onto DILITHIUM, FALCON and then SPHINCS+.

Do you want to learn more about these algorithms? Do you think we should implement the algorithms in a different order? Let us know! If you have any questions or run into any issues, contact us at facts@wolfssl.com, or call us at +1 425 245 8247.

At wolfSSL we create solutions to provide secure access to a variety of systems and devices. Our latest example adds the ability to use the SSH protocol to securely connect plain text serial UART using an Espressif ESP32 or ESP8266 over wireless or wired ethernet.

In celebration of this new capability, we’re having a contest where you can win fame, glory, and cool wolfSSL swag! All you need to do is demonstrate on social media that you were able to get this working on your own hardware, either the ESP32 or ESP8266 platforms and successfully connect to your UART device!

The project is part of our ongoing initiative to ensure all Espressif device users have access to commercial-grade reliable encryption.

To participate in the contest:

• Please follow us on Twitter and retweet the contest tweet.
• Install the wolfSSH embedded server found in the wolfssh-examples.
• Connect your ESP32 or ESP8266 to any serial device (or a USB-TTY if needed)
• Login via SSH from command-line, putty, etc.
• Reply to the tweet with pictures or video showing your successful login.
• The first person to demonstrate success will win some great wolfSSL swag!
• We may choose other winners based on creativity or PR’s for feature additions.
• Thank you for participating!

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

For more information, see https://www.wolfssl.com/espressif/

This example code is found on our new wolfssh-examples repo at: https://github.com/wolfSSL/wolfssh-examples