Month: July 2022

The cURL Project and wolfSSL is happy to announce the annual cURL Developers Conference, cURL Up has been rescheduled for Thursday September 15, 2022! cURL Up will be held virtually this September giving allowing the world – wide cURL community to join.

cURL Up is the annual curl developers conference where we gather and talk Internet protocols, curl’s past, current situation and how to design its future.

This is an intimate and very friendly meetup where you will have the opportunity to talk to Daniel Stenberg, founder and maintainer of cURL, as well as other speakers and sponsors about cURL and related technologies.

The first 50 registrants get some awesome swag!

When: Sep 15, 2022 06:00 AM Pacific Time (US and Canada)

Register in advance for this webinar:
https://us02web.zoom.us/webinar/register/WN_YHLm4WXGSKC-D8O6sgIb6Q

After registering, you will receive a confirmation email containing information about joining the webinar.

If you have questions or comments contact us at facts@wolfssl.com

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, comments or suggestions, send us an email at facts@wolfssl.com.

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.

wolfEngine : wolfCrypt as an Engine for OpenSSL
Time: July 28, 2022 09:00 AM in Pacific Time
Register here: https://us02web.zoom.us/webinar/register/WN_tDVDRW3uSh-AVnkGdA6jLQ

If you have any other questions or concerns please reach out to facts@wolfssl.com or support@wolfssl.com anytime.

wolfSSL will be at Black Hat in Las Vegas this year! Catch our team August 6th through the 11th to dive into the latest in cybersecurity. 

BHUSA  8/6 – 8/11 2022 – Mandalay Bay Convention Center, Las Vegas, NV, USA

Register for virtual or in-person access:https://www.blackhat.com/us22/registration.html

We will have Todd Ouska, our CTO, Engineers and Business Directors hanging out at Booth 1084, ready to answer all your security questions, talk through getting started with wolfSSL, as well as:

• Our post quantum cryptographic implementations 
  • Post quantum curl 
  • Post quantum SSH
  • Post quantum engine X
• TLS 1.3 sniffer support in the latest wolfSSL version 4.7.0
• The advantages of TLS 1.3 
• Getting to FIPS 140-3 first
• wolfSentry embedded IDPS (intrusion detection and prevention system) 
• wolfBoot Secure Boot
• wolfEngine, otherwise known as the wolfCrypt FIPS engine for OpenSSL
• Commercial curl support for your use case 

Email facts@wolfSSL.com to set up a meeting at the show, or come find us at Booth 1084! We can’t wait to see you. It’s been too long.

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!

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!

wolfSSL will be at Black Hat in Las Vegas this year! Catch our team August 6th through the 11th to dive into the latest in cybersecurity. 

BHUSA  8/6 – 8/11 2022 – Mandalay Bay Convention Center, Las Vegas, NV, USA

Register for virtual or in-person access:https://www.blackhat.com/us22/registration.html

We’ll have Engineers and Business Directors hanging out at Booth 1084, ready to answer all your security questions, talk through getting started with wolfSSL, as well as:

• Our post quantum cryptographic implementations 
  • Post quantum curl 
  • Post quantum SSH
  • Post quantum engine X
• TLS 1.3 sniffer support in the latest wolfSSL version 4.7.0
• The advantages of TLS 1.3 
• Getting to FIPS 140-3 first
• wolfSentry embedded IDPS (intrusion detection and prevention system) 
• wolfBoot Secure Boot
• wolfEngine, otherwise known as the wolfCrypt FIPS engine for OpenSSL
• Commercial curl support for your use case 

Email facts@wolfSSL.com to set up a meeting at the show, or come find us at Booth 1084! We can’t wait to see you. It’s been too long.

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/).

For more details about the release of information in general contact facts@wolfssl.com or even visit us BlackHat 2022 conference. We’ll be at booth 1084. See you there!

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! You can get in touch with your regional business director, send us a message at facts@wolfssl.com or even visit us BlackHat 2022 conference. We’ll be at booth 1084. See you there!