RECENT BLOG NEWS

wolfSSL has updated support for the Apache HTTP Server. We have updated support for Apache httpd to version 2.4.51 in pull request #4658. wolfSSL is a SSL/TLS library that implements support for the latest TLS standards (TLS 1.3 and DTLS 1.2).

Apache is the most popular web server on the Internet since April 1996 that provides a secure, efficient and extensible web server. By building wolfSSL, you can leverage the full power of wolfCrypt. This includes hardware support for multiple platforms and architectures, FIPS 140-2 (soon 140-3) compliance for your FIPS needs, and the best tested cryptography on the market.

To build wolfSSL for Apache httpd, please configure wolfSSL with –enable-apachehttpd –enable-postauth. The patch and instructions for using Apache 2.4.51 with wolfSSL 5.1.0 can be found at https://github.com/wolfSSL/osp/tree/master/apache-httpd.

Vulnerabilities Fixed

• [High] A TLS v1.3 server who requires mutual authentication can be bypassed. If a malicious client does not send the certificate_verify message a client can connect without presenting a certificate even if the server requires one. Thank you to Aina Toky Rasoamanana and Olivier Levillain of Télécom SudParis. CVE-2022-25640
•  [High] A TLS v1.3 client attempting to authenticate a TLS v1.3 server can have its certificate check bypassed. If the sig_algo in the certificate_verify message is different than the certificate message checking may be bypassed. Thank you to Aina Toky Rasoamanana and Olivier Levillain of Télécom SudParis. CVE-2022-25638

New Feature Additions

• Example applications for Renesas RX72N with FreeRTOS+IoT
• Renesas FSP 3.5.0 support for RA6M3
• For TLS 1.3, improved checks on order of received messages.
• Support for use of SHA-3 cryptography instructions available in ARMv8.2-A architecture extensions. (For Apple M1)
• Support for use of SHA-512 cryptography instructions available in ARMv8.2-A architecture extensions.  (For Apple M1)
• Fixes for clang -Os on clang >= 12.0.0
• Expose Sequence Numbers so that Linux TLS (kTLS) can be configured
• Fix bug in TLSX_ALPN_ParseAndSet when using ALPN select callback.
• Allow DES3 with FIPS v5-dev.
• Include HMAC for deterministic ECC sign build
• Add –enable-chrony configure option. This sets build options needed to build the Chrony NTP (Network Time Protocol) service.
• Add support for STM32U575xx boards.
• Fixes for NXP’s SE050 Ed25519/Curve25519.
• TLS: Secure renegotiation info on by default for compatibility.
• Inline C code version of ARM32 assembly for cryptographic algorithms available and compiling for improved performance on ARM platforms
• Configure HMAC: define NO_HMAC to disable HMAC (default: enabled)
• ISO-TP transport layer support added to wolfio for TLS over CAN Bus
• Fix initialization bug in SiLabs AES support
• Domain and IP check is only performed on leaf certificates

ARM PSA Support (Platform Security Architecture) API

• Initial support added for ARM’s Platform Security Architecture (PSA) API in wolfCrypt which allows support of ARM PSA enabled devices by wolfSSL, wolfSSH, and wolfBoot and wolfCrypt FIPS.
• Included algorithms: ECDSA, ECDH, HKDF, AES, SHA1, SHA256, SHA224, RNG

ECICE Updates

• Support for more encryption algorithms: AES-256-CBC, AES-128-CTR, AES-256-CTR
• Support for compressed public keys in messages.

Math Improvements

• Improved performance of X448 and Ed448 through inlining Karatsuba in square and multiplication operations for 128-bit implementation (64-bit platforms with 128-bit type support).
• SP Math C implementation: fix for corner case in curve specific implementations of Montgomery Reduction (P-256, P-384).
• SP math all: assembly snippets added for ARM Thumb. Performance improvement on platform.
• SP math all: ARM64/32 sp_div_word assembly snippets added to remove dependency on __udiv3.
• SP C implementation: multiplication of two signed types with overflow is undefined in C. Now cast to unsigned type before multiplication is performed.
• SP C implementation correctly builds when using CFLAG: -m32

OpenSSL Compatibility Layer

• Added DH_get_2048_256 to compatibility layer.
• wolfSSLeay_version now returns the version of wolfSSL
• Added C++ exports for API’s in wolfssl/openssl/crypto.h. This allows better compatibility when building with a C++ compiler.
• Fix for OpenSSL x509_NAME_hash mismatch
• Implement FIPS_mode and FIPS_mode_set in the compat layer.
• Fix for certreq and certgen options with openssl compatibility
• wolfSSL_BIO_dump() and wolfSSL_OBJ_obj2txt() rework
• Fix IV length bug in EVP AES-GCM code.
• Add new ASN1_INTEGER compatibility functions.
• Fix wolfSSL_PEM_X509_INFO_read with NO_FILESYSTEM

CMake Updates

• Check for valid override values.
• Add `KEYGEN` option.
• Cleanup help messages.
• Add options to support wolfTPM.

VisualStudio Updates

• Remove deprecated VS solution
• Fix VS unreachable code warning

New Algorithms and Protocols

• AES-SIV (RFC 5297)
• DTLS SRTP (RFC 5764), used with WebRTC to agree on profile for new real-time session keys
• SipHash MAC/PRF for hash tables. Includes inline assembly for x86_64 and Aarch64.

Remove Obsolete Algorithms

• IDEA
• Rabbit
• HC-128

Here at wolfSSL, we love doing integrations. 

What you might not know about Mozilla’s Firefox and NSS is that all of the cryptography happens underneath their PKCS#11 layer which is a software component called the “NSS Internal PKCS #11 Module”. It has a “Software Security Device.” As you can see in the user interface screenshot above, “wolfPKCS11” has “wolfSSL HSM slot ID 01” and has been loaded in Mozilla Firefox’s Security Device Manager. You can find wolfPKCS11 at https://github.com/wolfSSL/wolfPKCS11/ . It primarily replaces the underlying authentication implementations with those found in wolfCrypt.

What does this mean in terms of FIPS 140-2/3? It means that if you are running Firefox in an environment that requires FIPS assurances, you can swap in wolfSSL and meet the requirement!

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 us to hear from cURL founder and lead developer Daniel Stenberg,  and learn about the cURL roadmap for 2022. Tune in to learn about the topics that he and wolfSSL plan to work on over the year and potential ideas that they are considering. As always, bring your questions for the Q&A session at the end!

Topic: cURL 2022 Roadmap

Watch the webinar here: cURL 2022 Roadmap

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 us to learn more about the current state of Bluetooth Low Energy (BTLE) security as well as an explanation of its limitations and issues. We will demonstrate using TLS v1.3 for BTLE secret and explain the benefits. Bring your questions for the Q&A session to follow!

Watch the webinar here: Securing BTLE with wolfSSL and TLS v1.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.

wolfSSL is a growing company looking to add a top notch embedded systems software engineer to our organization. wolfSSL develops, markets and sells the leading Open Source embedded SSL/TLS protocol implementation, wolfSSL. Our users are primarily building devices or applications that need security. Other products include wolfCrypt embedded cryptography engine, wolfMQTT client library, and wolfSSH.

Job Description:

Currently, we are seeking to add a senior level C software engineer with 5-10 years experience interested in a fun company with tremendous upside. Backgrounds that are useful to our team include networking, security, and hardware optimizations. Assembly experience is a plus. Experience with encryption software is a plus. RTOS experience is a plus.  Experience with hardware-based cryptography is a plus.

Operating environments of particular interest to us include Linux, Windows, Embedded Linux and RTOS varieties (VxWorks, QNX, ThreadX, uC/OS, MQX, FreeRTOS, etc). Experience with mobile environments such as Android and iOS is also a plus, but not required.

Location is flexible. For the right candidate, we’re open to this individual working from virtually any location.

How To Apply

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 is happy to announce that we’ve recently added support for AES-SIV (synthetic initialization vector). Our implementation is based on the specification in RFC 5297. SIV mode is designed to be resistant to security degradation from accidental nonce reuse. Notably, AES-SIV is a mandatory AEAD algorithm for network time protocol (NTP) servers supporting network time security (NTS), per RFC 8915. We added AES-SIV to support our chrony 4.1 port, which is one of the only major NTP implementations that currently supports NTS.

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

Significant improvements to the C-only implementation of Single Precision math for P-256 and P-384 have been made in wolfSSL 5.1.1. Previously the Montgomery reduction implementation was performed generically. This function makes up a significant proportion of the time to perform ECC operations. By adding an optimised implementation the performance of the 32-bit C code improved by up to 80%! The 64-bit C code saw similar improvements.

Also the Aarch64 implementation of P-384 got an optimised version of the Montgomery reduction operation too. This improved its performance by up to 150%!

From fuzz testing, it was found that the implementation finding the square root modulo a prime (used in uncompressing a point) was not handling a value of zero correctly and resulted in the function not returning. This corner case will not occur with valid points. Compressed points are not recommended and disabled by default, but the fix was required to protect against potential attacks.

Bug fixes for the SP general math library were made for 5.1.1. These included fixes to sanity check values passed to sp_gcd (used in but not affecting RSA key generation) and better checking of maximum size of numbers when dividing. Also, when compiling for MIPS 32-bit, some compilers didn’t like the register names ‘$lo’ and ‘$hi’. These have been changed to ‘%lo’ and ‘%hi’ respectively.

The Single Precision code was also fixed around modular exponentiation. When the modulus is even or the exponent is 0 then we now error out. These are not use cases that are hit in normal operation.

A couple of bug fixes were made in the TFM implementation of our math library as well. An improved Montgomery reduction for Intel x86_64 was added in 5.0.0 and fixed to work reliably in this release. Also some out of memory error handling was improved around this same function.

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.

wolfSSL is adding support for complete RTCA DO-178C level A certification! wolfSSL will offer DO-178 wolfCrypt as a commercial off -the-shelf (COTS) solution for connected avionics applications. Adherence to DO-178C level A will be supported through the first wolfCrypt COTS DO-178C certification kit release that includes traceable artifacts for the following encryption algorithms:

• SHA-256 for message digest.
• AES for encryption and decryption.
• RSA to sign and verify a message.
• chacha20_poly1305 for authenticated encryption and decryption.
• ECC to sign, verify and share secrets.
• HMAC  for keyed-hashing for message authentication.

The primary goal of this initial release is to provide the proper cryptographic underpinnings for secure boot and secure firmware update in commercial and military avionics. wolfSSL brings trusted, military-grade security to connected commercial and military aircraft. Avionics developers now have a flexible, compact, economical, high-performance COTS solution for quickly delivering enhanced, secure communications that can be readily certified to DO-178. In addition, any of the FIPS 140-2 validated crypto algorithms can be used in DO-178 mode for combined FIPS 140-2/DO-178 consumption. The wolfCrypt cryptography library has been FIPS 140-2 validated (Certificate’s #2425 and #3389). For additional information, contact us at fips@wolfssl.com! 

Optimization Support

We understand that securely rebooting avionic systems has rigorous performance requirements. As such, we’re here to help with cryptographic performance optimizations through our services organization. 

Release Plan

• Basic crypto for secure boot and secure firmware updates – Available Now!
• wolfBoot Secure Boot – Q1, 2022
• wolfSSL – Q2, 2022
• wolfDTLS – Q2, 2022

To download and view the most recent version of wolfSSL, the wolfSSL GitHub repository can be cloned from here: https://github.com/wolfssl/wolfssl.git, and the most recent stable release can be downloaded from the wolfSSL download page here: https://www.wolfssl.com/download/.

For more information, please visit the wolfSSL DO-178 product page: https://www.wolfssl.com/wolfssl-support-178-dal/.

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

This is a quote from a message posted by Dustin Moody of NIST on the NIST PQC Forum at https://groups.google.com/a/list.nist.gov/g/pqc-forum/c/fvnhyQ25jUg :

“Yes - the 3rd round will shortly be ending.  NIST is actively writing the 3rd Round report which will 
explain our rationale for which algorithms we will standardize.   We hope to be able to announce the 
results and report not later than the end of March.”

Dustin Moody, Feb. 9, 2022

So, we can expect some news from NIST in a month or so. With this in mind, we thought this might also be a good time to talk about the FALCON Signature Scheme integration in the wolfSSL v5.1.1 release and some of the other work we have done around post-quantum cryptography.

The FALCON Signature Scheme is a post-quantum algorithm that is a finalist of round 3 of the NIST PQC competition. It shows much promise in that while its artifacts are large and key generation and signing are a bit slower than currently standardized algorithms, signature verification times are much faster which bodes well for IoT and constrained devices.  You can compare the speed in our benchmarking data that can be found in Appendix G of our wolfSSL Manual: https://www.wolfssl.com/documentation/wolfSSL-Manual.pdf

The good news for our customers that want to experiment with FALCON is that it couldn’t be easier! All you need to do is build liboqs, rebuild wolfSSL and add the –with-liboqs flag.  If you built your application to statically link with wolfSSL, you will need to rebuild your application.  If you dynamically link, you do not need to rebuild.  All you have to do now is  swap out your certificates with FALCON certificates!  No code changes are required for your application. You can find instructions and a script for generating a  FALCON certificate chain here: https://github.com/wolfSSL/wolfssl-examples/tree/master/pq

For customers who want to see post-quantum algorithms working in a real world use-case, we have instructions for you to build a quantum-safe apache web server and curl web client. All you need to do is follow the instructions here: https://github.com/wolfSSL/osp/blob/master/apache-httpd/README_post_quantum.md

Finally, just a few words regarding motivation.  Most people understand the harvest and decrypt threat model and thus see the urgency for moving to post-quantum key establishment. However, seeing the motivation for signature schemes might be harder. Suppose you are deploying authentication algorithms on devices that have long lifetimes and are hard to update.  A good example of this might be firmware for industrial machinery or cars.  If the lifetime of your deployment exceeds the time to a cryptographically relevant quantum computer, then you should probably consider experimenting to understand the impact of post-quantum algorithms sooner rather than later.

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.