Author: Kajal Sapkota

In a recent blog post we showed the details of a quantum-safe connection using wireshark. This post is to announce that now you can also do the exact same thing by following instructions provided by our friends at the Open Quantum Safe group. They have generously hosted a wireshark integration via docker that will display algorithm names using both their naming convention as well as wolfSSL’s.

The default naming convention is OQS’s but if you want to use wolfSSL’s naming convention, simply clone their repo at `git@github.com:open-quantum-safe/oqs-demos.git` and in the `wireshark/Dockerfile` change the following line:

ARG QSC_SSL_FLAVOR="oqs"

… to …

ARG QSC_SSL_FLAVOR="wolfssl"

… and then follow the rest of the instruction in `wireshark/README.md` and `wireshark/USAGE.md`. We at wolfSSL would like to thank our friends at the OpenQuantumSafe project for their hard work!

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 latest benchmarks of wolfSSL power consumption on an STM32L476G device are up (https://www.eembc.org/viewer/?benchmark_seq=13436). What we found is that using wolfSSL’s SP math (with assembly speed ups) is superior on the device. It has a positive impact on both the speed and power consumption.

With the measurements used with EEMBC (https://www.eembc.org/) higher final scores are better. Without using any optimizations in building wolfSSL the power usage collected was 2170 and performance was 502. Once turning on optimizations and SP assembly the power usage was 13200 and performance was 3050.

The energy score is derived from an inverted, weighted, micro Joules per iteration. Similarly the performance is an inverted, weighted, microseconds per iteration. ECDSA operations saw a significant performance and power usage improvement with SP math enabled and assembly optimizations compiled in. ECDSA operations are the biggest resource consumers with TLS handshakes and a good indication of how long and how much power a TLS connection will use.

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

Our wolfMQTT project includes an example for secure firmware update or Over the Air (OTA) update. This example uses the wolfSSL embedded SSL/TLS library to hash/sign the binary image and send it over MQTT. The example has two applications. One is called fwpush, which hashes, signs and publishes the firmware image over TLS to an MQTT broker. The second is called fwclient, which subscribes to the example firmware update topic, receives the firmware image and validates the signature of it. This example is located in examples/firmware.

The latest wolfMQTT releases can be downloaded at:
https://wolfssl.com/download

Documentation for wolfMQTT can be found here:
https://www.wolfssl.com/docs/wolfmqtt-manual/

The latest source code can be found on our GitHub repo at:
https://github.com/wolfSSL/wolfMQTT

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’re happy to announce that we’ve added wolfSSL support to OpenPegasus 2.14.1 using our OpenSSL compatibility layer! OpenPegasus is an open source CIM server. The wolfSSL port allows you to use OpenPegasus with our FIPS-certified wolfCrypt library. To build OpenPegasus with wolfSSL, follow the instructions in our open source projects repository.

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

Ever wonder exactly how much power your crypto is consuming? How long the battery of your device will last after adding in security? wolfSSL has worked with EEMBC to plug wolfSSL into SecureMark TLS for benchmarking a hardware’s performance and power consumption (https://github.com/eembc/securemark-tls). One of the algorithms benchmarked with SecureMark is ECDSA which makes up the bulk of the power and time taken for TLS 1.3 and TLS 1.2 handshakes using ECDSA cipher suites. 

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.