RECENT BLOG NEWS

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

wolfSSL has supported FreeRTOS for over a decade but you can now run wolfSSL’s command-line tool, wolfCLU, on FreeRTOS as well! The wolfSSL embedded TLS library is a lightweight, portable, C-based SSL/TLS library known for its low footprint, speed, and feature set and wolfCLU makes use of this portable library to offer a portable, low overhead cert/crypto command-line tool alternative.

As of right now, all wolfCLU commands that do not require a filesystem can be run on FreeRTOS including commands for generating certificates, certificate requests, DSA/DH/ECC parameters, and random data.

Are you interested to have more wolfCLU functionality supported on FreeRTOS?

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

Story time with wolfSSL! Join us for a comprehensive presentation on how to leverage wolfSSL for all of your Automotive Security needs as we go through a variety of different use cases and example with the specific engineering details for each story.

As always bring your questions for the Q&A following the presentation.

Watch the webinar here: Everything about Automotive Security

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