RECENT BLOG NEWS

We are adding hardware security to wolfSSH to meet the rising security requirements for connected systems.

Thanks to the widely available Trusted Platform Module (TPM) and our portable wolfTPM library, wolfSSH can have the user’s private SSH key stored and used directly from a hardware security module. This way the private key material is never exposed in raw form and the system has physical tamper-proof protection of its important secrets.

wolfSSH is a portable SSH v2.0 client and server. It also supports the SCP and SFTP protocols. This makes wolfSSH a preferred choice for embedded systems and applications. 

wolfTPM is a portable TPM 2.0 library, designed for baremetal and embedded systems. wolfTPM has its own TPM Interface Layer (TIS) developed in accordance with the Trusted Computing Group Group (TCG). This allows wolfTPM to operate in every operating environment, because it does not require a TPM driver.

For information on our wolfSSH capabilities see https://www.wolfssl.com/products/wolfssh/.

Do you want to use SSH with hardware protected keys?

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 QSslSocket class in Qt makes it easy to add encryption to your application. wolfSSL makes it secure!

The wolfSSL embedded SSL/TLS library is a lightweight SSL/TLS library written in ANSI C and targeted for embedded, RTOS, and resource-constrained environments – primarily because of its small size, speed, and feature set.  It is commonly used in standard operating environments as well because of its royalty-free pricing and excellent cross-platform support. wolfSSL supports industry standards up to the current TLS 1.3 and DTLS 1.2 levels, is up to 20 times smaller than OpenSSL, supports FIPS, and has critical interfaces like TPM 2.0 and  PKCS#11.

Qt has traditionally used OpenSSL as the provider for SSL/TLS in Qt Network for secure network communications. wolfSSL 4.4.0 adds support for building Qt 5.12 and 5.13 against the wolfSSL embedded SSL/TLS library instead of the default OpenSSL backend! The wolfSSL integration with Qt provides a performance-minded alternative, ideal for Qt developers who are looking for a lightweight, progressive, and well-tested SSL/TLS implementation.  

Using wolfSSL as a TLS provider in Qt can have many advantages, depending on application and industry.  Some of these may include:

• Progressive SSL/TLS protocol support (up to TLS 1.3)
• Smaller footprint size (up to 20 times smaller than OpenSSL)
• Extensive testing to reduce bugs and vulnerabilities (currently the best-tested SSL/TLS implementation available)
• Certifications (FIPS 140-2, DO-178C)
• Portability (supports over 30 operating systems)
• Hardware cryptography support
• Commercial support
• Consulting services and training available

To learn more about the advantages of using wolfSSL, visit our page on “wolfSSL vs. OpenSSL”. For more insight into building Qt with wolfSSL, the advantages it brings to Qt developers when used in place of OpenSSL, and the current state of SSL/TLS and the cryptography algorithms used, watch this recorded talk by our Engineering Manager, Chris Conlon. 

For instructions on how to compile Qt with the wolfSSL patch, please visit Building Qt with 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.

The 200th curl release found 3 major security advisories from the curl bug-bounty program. These are the advisories:

• CVE-2021-22901: TLS session caching disaster

This is a Use-After-Free in the OpenSSL backend code that in the absolutely worst case can lead to an RCE, a Remote Code Execution. The flaw is reasonably recently added and it’s very hard to exploit but you should upgrade or patch immediately.

The issue occurs when TLS session related info is sent from the TLS server when the transfer that previously used it is already done and gone.

• CVE-2021-22898: TELNET stack contents disclosure

When libcurl accepts custom TELNET options to send to the server, it the input parser was flawed which could be exploited to have libcurl instead send contents from the stack.

• CVE-2021-22897: schannel cipher selection surprise

In the Schannel backend code, the selected cipher for a transfer done with was stored in a static variable. This caused one transfer’s choice to weaken the choice for a single set transfer could unknowingly affect other connections to a lower security grade than intended.

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 integrating wolfTPM into U-Boot. This will extend the TPM 2.0 capabilities in U-Boot to include signature verification and measured boot.

For many platforms we can replace U-Boot such as on the Xilinx UltraScale+ MPSoC.

Our wolfBoot allows many features including:
* Partition signature verification using ED25519, RSA and ECC
* Encryption of partitions
* Updating of partitions in the boot loader
* Measured boot with TPM 2.0 PCR registers
* Offloading to crypto coprocessors like the TPM 2.0 modules
* Version checking for updates
* Rollback on failed updates

For information on our wolfBoot TPM integration see https://www.wolfssl.com/products/wolfboot/.

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

Connect with wolfSSL:
Twitter
LinkedIn
Facebook

Our first preview release of wolfSentry, the IDPS (Intrusion Detection and Prevention System) for embedded and IoT systems, has platform support for Raspberry Pi, STM32 with CubeMX, Atmel ASF and Barebox. As well as native support for Microsoft Windows and Linux.

Here at wolfSSL we are always striving to be better so we would love to hear which operating environments and platforms you would like to see supported by wolfSentry.

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 fans! Do you like FIPS? Do you like virtual machines? Guess what. wolfSSL`s crypto library, wolfCrypt, is validated for FIPS 140-2 and in the process of being one of the first cryptography libraries to be validated for FIPS 140-3. 

As wolfCrypt is commonly used in standard operating environments because of its royalty-free pricing and excellent cross platform support, wolfCrypt FIPS has been validated on a number of Operating Environments (OEs). The current validated OE list for both wolfCrypt FIPS certificates (#2425 and #3389) are listed here for reference.  

Certificate #2425 Current OE List:

Certificate #3389 Current OE List:

wolfSSL can easily add additional OEs to existing wolfCrypt FIPS certificates.

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

As some may be aware, wolfSSL added support for strongSwan in April of 2019. The upstream commit can be reviewed here: https://github.com/strongswan/strongswan/pull/133

Users can test the latest development master of wolfSSL with the latest version of strongSwan using the following setup:

wolfSSL Build and Installation Steps

$ git clone https://github.com/wolfSSL/wolfssl.git

$ cd wolfssl
$ ./autogen.sh

$ ./configure --enable-opensslall --enable-keygen --enable-rsapss --enable-des3 --enable-dtls --enable-certgen --enable-certreq --enable-certext --enable-sessioncerts --enable-crl --enable-ocsp CFLAGS="-DWOLFSSL_DES_ECB -DWOLFSSL_LOG_PRINTF -DWOLFSSL_PUBLIC_MP -DHAVE_EX_DATA"

$ make
$ make check
$ sudo make install

strongSwan Build and Installation Steps

# if the following packages are not already installed:
$ sudo apt-get install flex bison byacc libsoup2.4-dev gperf

$ git clone https://github.com/strongswan/strongswan.git
$ cd strongswan
$ ./autogen.sh

# if packages are missing autogen.sh must be re-run

$ ./configure --disable-defaults --enable-pki --enable-wolfssl --enable-pem
$ make
$ make check
$ sudo make install

wolfSSL has had interest in enabling FIPS 140-2/140-3 support with strongSwan so our engineers verified everything is working with the wolfCrypt FIPS 140-2 validated Module!

The steps wolfSSL used for testing are as follows:

Testing was done using the wolfSSL commercial FIPS release v4.7.0 which internally uses the wolfCrypt v4.0.0 FIPS 140-2 validated Crypto Module. It was located in the /home/user-name/Downloads directory on the target test system, Linux 4.15 Ubuntu 18.04 LTS running on Intel(R) Xeon(R) CPU E3-1270 v6 @ 3.80GHz.

1. wolfSSL was configured and installed with these settings:

./configure --enable-opensslall --enable-keygen --enable-rsapss --enable-des3 --enable-dtls --enable-certgen --enable-certreq --enable-certext --enable-sessioncerts --enable-crl --enable-ocsp CFLAGS="-DWOLFSSL_DES_ECB -DWOLFSSL_LOG_PRINTF -DWOLFSSL_PUBLIC_MP -DHAVE_EX_DATA -DFP_MAX_BITS=8192" --enable-ed25519 --enable-curve25519 --enable-fips=v2 --enable-intelasm --prefix=$(pwd)/../fips-install-dir
 make
 make install

2. A custom install location was used which equated to /home/user-name/Downloads/fips-install-dir and the configuration for strongSwan accounted for this.
3. strongSwan was cloned to /home/user-name/Downloads with “git clone https://github.com/strongswan/strongswan.git”
4. StongSwan was configured and installed with these settings:

./configure --disable-defaults --enable-pki --enable-wolfssl --enable-pem --prefix=$(pwd)/../strongswan-install-dir wolfssl_CFLAGS="-I$(pwd)/../fips-install-dir/include" wolfssl_LIBS="-L$(pwd)/../fips-install-dir/lib -lwolfssl"
 make
 make install
 make check

5. In the make check stage of the test, it was observed that 1 test was failing.

 Passed 34 of 35 'libstrongswan' suites
 FAIL: libstrongswan_tests
 ==================
 1 of 1 test failed
 ==================

6. Reviewing the logs it was apparent one of the RSA tests was failing.
7. Upon further debugging it turned out the failure was a test in strongSwan that was attempting to create an RSA key size of 1536-bits.

Running case 'generate':
 DEBUG: key_sizes[_i] set to 1024
 + PASS
 DEBUG: key_sizes[_i] set to 1536
 - FAIL
 DEBUG: key_sizes[_i] set to 2048
 + PASS
 DEBUG: key_sizes[_i] set to 3072
 + PASS
 DEBUG: key_sizes[_i] set to 4096
 + PASS

wolfSSL has a function RsaSizeCheck() which in FIPS mode will specifically reject any non FIPS RSA key sizes so this failure was not only expected, but it is a good thing for those wanting to use strongSwan in FIPS mode and ensure only FIPS-validated RSA key sizes will be supported!

wolfSSL is pleased that with the latest release of wolfSSL v4.7.0 and the wolfCrypt FIPS 140-2 module validated on FIPS certificate 3389, strongSwan support is working splendidly and wolfSSL engineers will be making efforts to ensure continued support into the future!

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

devkitPro is a set of tool chains for compiling to gaming platforms. This includes the Nintendo Switch, 3DS, Wii, and Gamecube. If you need cryptographic or SSL/TLS capabilities in your games then wolfSSL has support for compiling with devkitPro. wolfSSL is a very lightweight and fast SSL/TLS library that will fit perfectly in a constrained game console environment.

This blog will showcase how to compile the wolfSSL testwolfcrypt program for Wii and run it in the Dolphin Emulator. It assumes that the devkitPro was installed in /opt/.

Compile wolfSSL using the devkitPPC tool chain:

./autogen.sh
./configure CFLAGS='-DDOLPHIN_EMULATOR -DDEVKITPRO -DGEKKO -DNO_WRITEV -I/opt/devkitpro/libogc/include -mrvl -mcpu=750 -mno-eabi -MMD -MP' LDFLAGS='-L/opt/devkitpro/libogc/lib/wii -lwiiuse -lbte -logc -lm' CC=/opt/devkitpro/devkitPPC/bin/powerpc-eabi-gcc RANLIB=/opt/devkitpro/devkitPPC/bin/powerpc-eabi-ranlib --host=ppc --enable-cryptonly --disable-shared --enable-static --disable-filesystem
make

Then convert the binary to a .dol file:

/opt/devkitpro/tools/bin/elf2dol wolfcrypt/test/testwolfcrypt ../testwolfcrypt.dol

The above command places the resulting binary in the directory that contains the wolfssl directory. Navigate to this directory in the Dolphin Emulator and run it:

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 wolfSSL / wolfCrypt libraries support asynchronous (non-blocking) crypto using hardware acceleration with the Intel QuickAssist and Cavium Nitrox III/V adapters. These are PCIe devices that accelerate crypto operations. For server platforms requiring high connection rates and throughput this allows greatly increased performance.

For some performance numbers see this page: https://www.wolfssl.com/docs/intel-quickassist/

Release v4.7.0 of wolfSSL Async has bug fixes and new features including:

• All wolfSSL v4.7.0 release fixes (https://github.com/wolfSSL/wolfssl/releases/tag/v4.7.0-stable)
• Fix for ARC4 macro typo.
• Fixes for Cavium Nitrox and Intel Quick Assist (https://github.com/wolfSSL/wolfssl/pull/3577) with TLS v1.3
• Documentation updates.
• Fixes for asynchronous memory leaks (https://github.com/wolfSSL/wolfssl/pull/3227)

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 in the process of adding BSD Kernel compatibility to wolfSSL. This means that our embedded SSL library would run in Kernel mode and use BSD based OE’s. The advantage of this project may include performance enhancement for device driver implementers that want SSL security. Stay tuned for more updates regarding this project. We would love to know do Kernel developers want an SSL library? Please comment!

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