Category: Uncategorized

Version 1.8.0 of wolfSSL JSSE and JNI is now available for download! The wolfSSL JSSE provider and JNI wrapper provide Java applications with a convenient Java API to the widely-used wolfSSL embedded SSL/TLS library, including support for TLS 1.3 and FIPS 140-2/140-3!  This package provides both a Java JSSE Provider as well as a thin JNI wrapper around native wolfSSL.

Release 1.8.0 includes FIPS 140-3 compatibility, bug fixes and new features including:

• wolfCrypt FIPS 140-3 and FIPS Ready compatibility
• Add Socket method wrappers, fixes behavior when inner Socket used with JSSE
• Add wrappers to get FIPS verifyCore hash (FIPS error cb or directly)
• Fix potential NullPointerException with several clone() methods
• Refactor of SSLSessionContext implementation
• Fix behavior of WolfSSLSocket.getSoTimeout() when external Socket is wrapped
• Fix timeout used in socketSelect to correctly handle fractional sec timeouts
• Fix memory leak when custom X509TrustManager is used with wolfJSSE
• Add support for multiple X509TrustManager objects across multiple sessions
• Call WolfSSL.cleanup() in finalizer to release library resources earlier
• Release native WOLFSSL memory sooner, when WolfSSLSocket is closed
• Better management and freeing of native WolfSSLCertificate memory
• Release native logging callback when library is freed
• Release native wolfCrypt FIPS callback when library is freed
• Release CTX-level Java verify callback when CTX is freed
• Release CTX-level Java CRL callback when CTX is freed
• Better global reference cleanup in error conditions
• Fix unused variable warnings in non-FIPS builds
• Use one static WolfSSL object across all WolfSSLProvider objects
• Release local JNI array inside WolfSSLSession.read() on function exit
• Add multi-threaded JSSE provider client and server examples
• Update Android AOSP install script to create missing blank files if needed
• Update Android AOSP build fixes to define `SIZEOF_LONG` and `SIZEOF_LONG_LONG`
• Update IDE/Android example Android Studio project
• Fix default cipher suite list order used in JSSE WolfSSLContext objects
• Fix FIPS Ready compatibility with `WC_RNG_SEED_CB`
• Update Android AOSP Android.mk to compile wolfCrypt kdf.c

wolfSSL JSSE and JNI 1.8.0 can be downloaded from the wolfSSL download page and the wolfSSL JNI Manual can be found here.

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 have added wolfCrypt support to SQLCipher, which enables encryption of a SQLite database. The port also supports using our wolfCrypt FIPS module.

SQLCipher extends the SQLite database library to add security enhancements that make it more suitable for encrypted local data storage like [1]:

• on-the-fly encryption
• tamper detection
• memory sanitization
• strong key derivation

This feature is enabled with `./configure –with-crypto-lib=wolfssl`.

See pull request https://github.com/sqlcipher/sqlcipher/pull/411 for details.

[1] From the SQLCipher README.md. https://github.com/sqlcipher/sqlcipher#sqlcipher

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 are excited to announce our wolfTPM v2.3 release. This includes some minor fixes and features for PCR and GPIO.

If using a big endian platform consider updating to resolve a byte swapping issue with the TIS layer.

We have refactored the GPIO configuration example for use with either STM ST33 or Nuvoton NPCT750 TPM 2.0 modules.

The PCR example now includes a standalone read example.

Release Details:

• Refactor GPIO support (single gpio_config) (PR #194)
• Fix for Linux HAL IO try again timeout logic (PR #194)
• Fix for big endian in TIS layer (PR #191)
• Fix for RSAES padding (RSA_Encrypt) (PR #187)
• Fix in tests to allow command code error for CreateLoaded (not supported on hardware) (PR #184)
• Fix for compiler warning for file read in make_credential.c (PR #182)
• Fixes for Windows builds (PR #181)
• Fixes for RSA RNG in edge case builds (fixes wolfBoot build error) (PR #180)
• Added PCR Read example (PR #185)

For a full list of changes, check out the updated ChangeLog.md bundled with wolfSSL or view our page on GitHub here (https://github.com/wolfSSL/wolfTPM).

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

Happy Fall! wolfSSL has a great treat for all, we released version 5.0.0 and it is now ready for download! This includes a new major feature, having our FIPS 140-3 code added in. Stay tuned for more information in upcoming blog posts regarding the FIPS 140-3 code additions! It also includes notable feature additions such as the post quantum resistant code supporting use of liboqs, expansion to the compatibility layer for ease of replacing OpenSSL and many more features and fixes.

Key New Feature Additions

New Product

• FIPS 140-3 — currently undergoing laboratory testing, code review and ultimately CMVP validation. Targeting the latest FIPS standard.
  • Federal Information Processing Standards (FIPS) 140-3 is a mandatory standard for the protection of sensitive or valuable data within Federal systems. FIPS 140-3 is an incremental advancement of FIPS 140-2, which now standardizes on the ISO 19790:2012 and ISO 24759:2017 specifications.

Post Quantum

• Support for OQS‘s (liboqs version 0.7.0) implementation of NIST Round 3 KEMs as TLS 1.3 groups –with-liboqs
• Hybridizing NIST ECC groups with the OQS groups
• Remove legacy NTRU and QSH
• Make quantum-safe groups available to the compatibility layer

Linux Kernel Module

• Full support for FIPS 140-3, with in-kernel power on self test (POST) and conditional algorithm self test(s) (CAST)
• –enable-linuxkm-pie — position-independent in-kernel wolfCrypt container, for FIPS
• Vectorized x86 acceleration in PK algs (RSA, ECC, DH, DSA) and AES/AES-GCM
• Vectorized x86 acceleration in interrupt handlers
• Support for Linux-native module signatures
• Complete SSL/TLS and Crypto API callable from other kernel module(s)
• Support for LTS kernel lines: 3.16, 4.4, 4.9, 5.4, 5.10
• KCAPI: add support for using libkcapi for crypto

Compatibility Layer Expansion

• Ports
  • Add support for libssh2
  • Add support for pyOpenSSL
  • Add support for libimobiledevice
  • Add support for rsyslog
  • Add support for OpenSSH 8.5p1
  • Add support for Python 3.8.5  
• Numerous API/Structs Added

The release contained two vulnerabilities – one regarding a hang with DSA sign creation and the other regarding the handling of certificate name constraints. 
Vulnerabilities

• [Low] Hang with DSA signature creation when a specific q value is used in a maliciously crafted key. If a DSA key with an invalid q value of either 1 or 0 was decoded and used for creating a signature, it would result in a hang in wolfSSL. Users that are creating signatures with DSA and are using keys supplied from an outside source are affected.
• [Low] Issue with incorrectly validating a certificate that has multiple subject alternative names when given a name constraint. In the case where more than one subject alternative name is used in the certificate, previous versions of wolfSSL could incorrectly validate the certificate. Users verifying certificates with multiple alternative names and name constraints, are recommended to either use the certificate verify callback to check for this case or update the version of wolfSSL used. Thanks to Luiz Angelo Daros de Luca for the report.

For a full list of changes, check out the updated ChangeLog.md bundled with wolfSSL or view our page on GitHub here (https://github.com/wolfSSL/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.

wolfSSL was developed with security and open source development in mind. As such we have continued to make sure our products are open source, so that they are free to download and modify under a GPL licence. 

We are so happy to announce that our product wolfEngine and our OpenSSL Provider solution with FIPS are now public under a GPL v.3 license! wolfEngine is a FIPS-certified crypto module (wolfCrypt) with OpenSSL as an OpenSSL engine. You may also know that OpenSSL 3.0 has done away with the engines paradigm in favor of a new concept, called providers. wolfSSL has developed an OpenSSL 3.0 provider, allowing you to use the latest version of OpenSSL backed by our FIPS-certified wolfCrypt library. Like wolfEngine, the wolfSSL provider for OpenSSL is an excellent pathway for users looking to get FIPS compliance fast while still using OpenSSL.

Check them out in our GitHub Repository here!

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

In December 2020, wolfSSL 4.6.0 featured initial support for building as a Linux kernel module, supplying the entire native wolfCrypt and wolfSSL APIs directly to other kernel modules.

Now, with our just-released milestone 5.0.0 release, we have extended that support with in-kernel FIPS 140-3, additional accelerated cryptography options on x86, and substantial improvements in stack usage.

Porting a library as large and complex as wolfSSL to the Linux kernel has been a multi-phase undertaking, guided by three key objectives:

• A build process that is completely turnkey on supported kernel lines, via configure –enable-linuxkm and –with-linux-source=/source/tree/top.
• A source tree that remains unified: the library and the kernel module are built from the same codebase, and differ only in various settings, and in kernel-specific glue logic.
• Module builds that use the Linux in-tree Kbuild toolchain, rather than a bespoke out-of-tree build system, to facilitate simultaneous and continuing support for a wide variety of old and new kernel releases.

The Linux kernel is not a POSIX target, and many facilities commonly available to libraries and applications are unavailable (e.g. stack red zones, the C library, thread-local storage) or severely restricted (e.g. stack depth and vectorized instructions). Additionally, each minor kernel version and hardware target has peculiarities that cannot be ignored.

In this presentation, we will chronicle some of the challenges we encountered porting wolfSSL to this unusual target, and the solutions we developed.

We will discuss:

• Refactors spanning the entire wolfSSL library to strictly control peak stack usage;
• New development and QA tools developed for the kernel module project, such as fine-grained cumulative stack depth instrumentation and error-checking vector register save/restore and asserts;
• Porting wolfcrypt_test to the kernel, for comprehensive validation of all cryptographic implementations;
• Automated translation of symbol visibility to kernel namespace export directives, leveraging ELF visibility tags;
• Extending the wolfSSL autotools configuration to set up a Kbuild configuration and seamlessly hand off control to Kbuild;
• New automated testing: continually testing module builds on the latest release (currently 5.15) and a substantial cross-section of LTS kernels (currently 3.16, 4.4, 4.9, 5.4, and 5.10);
• The challenges of maintaining squeaky-clean builds on kernels as old as 3.16 (2014) and as new as 5.15 (this week) from a single unified codebase that is directly and continually impacted by the engineering decisions of the Linux kernel developers;
• The challenge of FIPS 140-3 compliance in the Linux kernel: containerizing the FIPS module, stabilizing its hash, and refactoring thread-local storage requirements;
• An example application: wireGuard kernel module crypto rip&replace, and matching rip&replace of wireGuard user space software;
• The future: example applications that exercise in-kernel TLS negotiation, more x86 accelerations, acceleration on other architectures, etc.

Watch the webinar here: Linux Kernel Mode

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

One of the greatest security issues facing the automotive and aviation worlds is securing connections over CAN bus and its derivative protocols.  The big issue with these protocols is that they do not have a method for authenticating who or what they are communicating with, and don’t encrypt the traffic.  This leaves them open to a variety of well known attacks, like MITM, replay, and of course eavesdropping.

As many of our users are aware, wolfSSL is transport agnostic.  As such, we do TLS 1.3 grade security, complete with authentication and encryption, over any number of transports, such as Bluetooth, BTLE, Zigbee, Zwave, serial, etc.  Our transport agnostic strategy brings great benefit to environments where the transport protocol does not include security, or has poor security, because of its design or history.

We are now embarking on the mission to secure CAN bus with TLS 1.3!  Are you curious or interested? If you have questions on any of the above, contact us at facts@wolfssl.com, or call us at +1 425 245 8247.

The wolfMQTT library is an implementation of the MQTT Client written in C for embedded use, which supports SSL/TLS via the wolfSSL library. This library was built from the ground up to be multi-platform, space conscious and extensible. And most importantly it integrates with wolfSSL to provide TLS support, for a secure solution out of the gate!

Specifications supported

• MQTT v3.1.1
• MQTT v5.0
• MQTT-SN (Sensor Network) v1.2

Application architecture

• Non-blocking support for baremetal apps
• Multithread for OS/RTOS supporting threads

Callbacks

• Publish messages that are received can trigger a registered function
• Broker disconnect for easily handling reconnects
• Networking for simple integration with any I/O
• MQTTv5 properties can be handled with a registered function

Supported build environments:

• Mac/Linux/Unix with make files
• Visual Studio solution
• Arduino
• MinGW
• Cross-compile for any target

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

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

The pq-wolfssl development team have done an excellent  experimental post-quantum integration.  We applaud their efforts and wanted to summarize and share some fascinating things that they published in their paper.  First we will discuss their scenario and then their conclusions.

The team’s objective was to study the possibility of a two-step migration strategy for post-quantum signature schemes.  In their scenario, initially, only long lived root certificates would use public keys associated with stateful hash-based signature algorithms while the intermediate and end entity certificates continue to have public keys associated with conventional algorithms such ECDSA. It is important to note here (as is done in the paper as well), that stateful hash-based signature algorithms are already specified as IETF RFCs and are generally accepted to be secure as their building blocks are well trusted hash algorithms and Merkle trees and do not depend on new or exotic mathematical constructs.

Eventually, as the other post-quantum algorithms are standardized and trust builds, intermediate certificates can be issued with public keys associated with them.  At this step end-entity certificates would then be issued with public keys associated with the new post-quantum algorithms as well. This finishes the migration process.

This begs the question, why not use stateful hash-based signature algorithms all throughout the chain from the beginning? The answer lies in the state.  End entity certificates hold public keys that are associated with private keys that will be used during the handshake phase of the TLS 1.3 connection.  The management of this state during on-line signing operations is ill advised for reasons that are not within the scope of this blog post. More detailed explanations can be found at NIST’s website.

They found that the first step of the migration could be done practically and with very little impact on connection establishment parameters. In their final migration step where the whole certificate chain and key establishment were all under post-quantum algorithms, they found that the best case scenario was feasable in all respects except RAM usage. They found that RAM usage was significantly higher.

In the paper, the team says “Therefore, we selected the open source TLS library wolfSSL (v4.7.0) for our integrations of PQC, because it is suitable for embedded systems and supports TLS 1.3.”

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

A little while ago we announced support for post-quantum KEM groups and then hybrid groups. We are now proud to announce support for the PQC NIST round 3 finalist signature scheme FALCON. With this announcement, customers can now experiment with fully quantum-safe TLS 1.3 handshakes.

From a high level perspective, for every TLS 1.3 connection, authentication and confidentiality are the two main goals that protect each connection. Authentication is maintained via signature schemes such as ECDSA. Confidentiality is maintained by key establishment algorithms such as ECDHE and then using the established key with symmetric encryption algorithms such AES to encrypt a communication stream. We can thus decompose the security of the TLS 1.3 protocol into 3 types of cryptographic algorithms:

– authentication algorithms
– key establishment algorithms
– symmetric cipher algorithms

When a cryptographically relevant quantum computer is finally developed, Shor’s algorithm completely breaks the security of modern authentication and key establishment algorithms while Grover’s algorithm reduces the security of modern symmetric cipher algorithms by half. So, we must replace our modern authentication and key establishment algorithms with quantum-safe ones and double the strength of our symmetric cipher algorithms to maintain the security of our communications.

Now that wolfSSL has integrated FALCON, we can use it for authentication. We can use any one of our new KEMs and just in case, we can hybridize it with NIST-approved ECDSA groups. And finally, since the strength of AES-128 is generally accepted to be sufficient, we can double our strength by using AES-256 by using the AES_256_GCM_SHA384 TLS 1.3 ciphersuite. To get a connection that has such a handshake, you would run the following commands:

$ examples/server/server -v 4 -l TLS_AES_256_GCM_SHA384 \ 
 -A certs/falcon_level5_root_cert.pem \ 
 -c certs/falcon_level5_server_cert.pem \ 
 -k certs/falcon_level5_server_key.pem \ 
 --oqs P521_KYBER_LEVEL5 
 
 $ examples/client/client -v 4 -l TLS_AES_256_GCM_SHA384 \ 
 -A certs/falcon_level5_root_cert.pem \ 
 -c certs/falcon_level5_cleint_cert.pem \ 
 -k certs/falcon_level5_client_key.pem \ 
 --oqs P521_KYBER_LEVEL5 

You can then use a modified wireshark that recognizes our algorithms to monitor the connection and see what is really going over the wire:

The merge request for the wireshark modifications can be found here:
https://gitlab.com/wireshark/wireshark/-/merge_requests/4924/

The pull request for instructions for making a docker image with the wireshark modifications can be found here:

https://github.com/open-quantum-safe/oqs-demos/pull/104

The integration of FALCON has made it onto our wolfSSL master branch, and will be part of the next release of wolfSSL.

One last word on the threat model and why it is important to consider post-quantum authentication sooner rather than later. Due to your application parameters or use case, it might not be cost effective or even possible to update software components. In these cases, you must carefully evaluate the lifetime of your product. If you project that we will see a cryptographically relevant quantum computer within the lifetime of your product, but it can’t be updated, then perhaps you need to start thinking about a strategy for moving to post-quantum algorithms today.

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