CAAM+QNX+i.MX8

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.

Upcoming Live Webinar : wolfEngine – wolfCrypt as an Engine for OpenSSL

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.

wolfMQTT Releases v1.14.0

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 Beta Out!

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.

wolfSSL 5.4.0 Release!

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.

NIST Announces Post-Quantum Algorithm Standardization

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.

TLS Glitch Resistance on Encrypt

We’ve had some recent interest in adding resistance for detection of encrypt issues due to glitching. A recent report for ESP32 AES HW showed it was possible to skip the encrypt operation with some timed glitching. The attack requires physical access to the hardware. The attack results in the HW encrypt operation being skipped and the data being sent unencrypted over the TLS transport.

As a result we’ve added a new build option WOLFSSL_CIPHER_TEXT_CHECK to enable checking of the encrypt to ensure the data changed (i.e. is not the same). It defaults to checking 64-bits of the buffer, but this can be enlarged by overriding the WOLFSSL_CIPHER_CHECK_SZ macro.

We enable this feature by default with our “max strength” build option `–enable-maxstrength`.

For details see PR https://github.com/wolfSSL/wolfssl/pull/5231 “Added sanity check on TLS encrypt to trap against glitching”.

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 Xilinx FreeRTOS

wolfSSL has easy options for using FreeRTOS with LwIP on Xilinx boards! The Xilinx SDK has support for FreeRTOS and LwIP with embedded projects, which wolfSSL has been ported to use both for some time! The directory containing some Xilinx IDE projects and information for a quick start when working with the Xilinx SDK is located here (https://github.com/wolfSSL/wolfssl/tree/master/IDE/XilinxSDK).

With Xilinx FreeRTOS there are also calls to hardware acceleration using the Xilinx hardened crypto which greatly speeds up AES-GCM, SHA3, and RSA operations (https://docs.xilinx.com/v/u/en-US/wp512-accel-crypto). Stay tuned for updated benchmark numbers and status on the hardware acceleration with the new Versal board.

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

wolfSSH SSHD

We are in the process of developing an SSHD server with wolfSSH. This will be a fully featured application that can take in a typical OpenSSH style sshd_config file and handle incoming SSH connections. It’s backed by the progressive and well tested wolfCrypt library for all crypto operations. It is also developed with embedded devices in mind, having a reduced footprint size!

For early access to the SSHD server or questions contact us at facts@wolfssl.com.

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

wolfMQTT with Post-Quantum KYBER and FALCON

Here at wolfSSL, we pride ourselves on keeping up to date with the various post-quantum developments related to the protocols we support. wolfMQTT is a client side library that supports the MQTT publish and subscribe protocol that is a very good fit for IoT applications.

Recently, the OpenQuantumSafe project got a pull request for a new demo which featured the mosquito MQTT broker operating on top of TLS 1.3 with post-quantum cryptographic algorithms. Naturally, we were very excited to try and run some interoperability tests against it!

This blog post is to announce that wolfMQTT now supports KYBER_LEVEL1 KEM group and P256_KYBER_LEVEL1 hybrid group for key exchange along with FALCON_LEVEL1 for signature authentication over TLS 1.3. Our implementation has been successfully tested for inter-operability with the OpenQuantumSafe project’s mosquito MQTT broker demo. If you would like to try it out, please follow the instructions athttps://github.com/wolfSSL/wolfmqtt#post-quantum-mqtt-support

Want different post-quantum groups for KEM key exchange? Want other post-quantum signature schemes? Want to see the wolfSSL team make a post-quantum MQTT broker? Want to see this setup working on STM32 devices?

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

Posts navigation

1 2 3 9 10 11 12 13 14 15 22 23 24