RECENT BLOG NEWS

ExpressVPN’s Lightway protocol is out of beta and leverages wolfSSL for secure crypto. As such, the “modern VPN” inherits speed, performance, best-tested security and is able to maintain it’s lightweight mobility.

“In terms of the encryption, [ExpressVPN’s Chief Architect, Pete] Membrey explained that Lightway uses wolfSSL. ‘To be clear, we didn’t roll any of our own crypto. It’s something we – as a principle – keep well away from. It’s extremely easy to get that wrong so we outsourced it, effectively, to a library that’s open source and has been audited.’

wolfSSL is used on millions of devices already and is the library that powers Pokémon GO. It’s designed for embedded devices, so it’s fast on Apple M1 chip, on routers, iPhones and more.”

Learn more about ExpressVPN’s announcement on their blog and TechAdvisor.

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

Need more? Subscribe to our YouTube page for access to webinars.
Love it? Star us on GitHub!

A block cipher is an encryption method that applies a deterministic algorithm along with a symmetric key to encrypt a block of text, rather than encrypting one bit at a time as in stream ciphers. For example, a common block cipher, AES (Advanced Encryption Standard), encrypts 128 bit blocks with a key of predetermined length: 128, 192, or 256 bits. Block ciphers are pseudorandom permutation (PRP) families that operate on the fixed size block of bits. PRPs are functions that cannot be differentiated from completely random permutations and thus, are considered reliable, until proven unreliable.

Block cipher modes of operation have been developed to eliminate the chance of encrypting identical blocks of text the same way, the ciphertext formed from the previous encrypted block is applied to the next block. A block of bits called an initialization vector (IV) is also used by modes of operation to ensure ciphertexts remain distinct even when the same plaintext message is encrypted a number of times.

Some of the various modes of operation for block ciphers include CBC (cipher block chaining), CFB (cipher feedback), CTR (counter), and GCM (Galois/Counter Mode), among others. AES, described above, is an example of a CBC mode where an IV is crossed with the initial plaintext block and the encryption algorithm is completed with a given key, and the ciphertext is then outputted. This resultant cipher text is then used in place of the IV in subsequent plaintext blocks.

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

References

[1] Pseudorandom permutation. (2014, November 23). In Wikipedia, The Free Encyclopedia.Retrieved 22:06, December 18, 2014, from http://en.wikipedia.org/w/index.php?title=Pseudorandom_permutation&oldid=635108728.

[2] Margaret Rouse. (2014). Block Cipher [Online]. Available URL: http://searchsecurity.techtarget.com/definition/block-cipher.

[3] Block cipher mode of operation. (2014, December 12). In Wikipedia, The Free Encyclopedia. Retrieved 22:17, December 18, 2014, from http://en.wikipedia.org/w/index.php?title=Block_cipher_mode_of_operation&oldid=637837298

[4] Wikimedia. (2014). Available URL: http://upload.wikimedia.org/wikipedia/commons/d/d3/Cbc_encryption.png.

A stream cipher encrypts plaintext messages by applying an encryption algorithm with a pseudorandom cipher digit stream (keystream). Each bit of the message is encrypted one by one with the corresponding keystream digit. Stream ciphers are typically used in cases where speed and simplicity are both requirements. If a 128 bit block cipher (such as AES [Advanced Encryption Standard]) were to be used in place of a stream cipher where it was encrypting messages of 32 bit blocks, 96 bits of padding would remain. This is an inefficient approach and is one reason why a stream cipher would be preferred over a block cipher, since stream ciphers operate on the smallest possible unit.

Some common stream ciphers include Salsa20, ChaCha (a seemingly better variant of Salsa20), Rabbit, and HC-256, among others. Block ciphers can be used in stream mode to act as a stream cipher. If a block cipher is run in CFB (cipher feedback), OFB (output feedback), or CTR (counter) mode, it does not require additional measures to handle messages that aren’t equivalent to the length of multiples of the block size, and eliminates the padding effect.

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

References

[1] Stream cipher. (2014, November 19). In Wikipedia, The Free Encyclopedia. Retrieved 16:19, December 19, 2014, from http://en.wikipedia.org/w/index.php?title=Stream_cipher&oldid=634494612.

[2] Margaret Rouse. Stream Cipher. (2005). Available URL: http://searchsecurity.techtarget.com/definition/stream-cipher.

[3] Block cipher mode of operation. (2014, December 12). In Wikipedia, The Free Encyclopedia. Retrieved 17:13, December 19, 2014, from http://en.wikipedia.org/w/index.php?title=Block_cipher_mode_of_operation&oldid=637837298.

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.

Microsoft’s IoT Developer Advocate, Dave Glover, has put together an Azure Sphere Cloud example that uses the wolfMQTT client library and wolfSSL’s Embedded TLS library to demonstrate a secure IoT device connection using the Altair 8800 emulation project.

Find the project here and read more about Dave’s effort to get the Altair emulation connected to the Internet of Things!

Everyone deserves to have their IoT data secure, and wolfSSL provides the best libraries to accomplish that. Secure-IoT-Love from the wolfSSL team!

You can download the latest release here: https://www.wolfssl.com/download/
Or clone directly from our GitHub repository: https://github.com/wolfSSL/wolfMQTT

Don’t forget to add a star while you’re there!

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 embedded SSL/TLS library has support for PKCS#7 and you can use the wolfSSL Examples GitHub repository to take that functionality for a quick spin. PKCS #7: Cryptographic Message Syntax (CMS) is used to sign, encrypt, or decrypt messages under Public Key Infrastructure (PKI). Using the wolfSSL API to do all of the above has been demonstrated right here with different implementations and content types. This blog will showcase how to compile/run these examples.

Build wolfSSL as shown below. Some of the examples which use the CompressedData content type require the zlib library to be installed.

$ ./configure --enable-pkcs7 --enable-pwdbased CFLAGS="-DWOLFSSL_DER_TO_PEM" --with-libz
$ make
$ sudo make install

Then compile the examples in the pkcs7 directory.

$ make

All executables are now built and can be run from the terminal, encoding then decoding their respective bundles and printing the status. For example:

$ ./encryptedData
Successfully encoded EncryptedData bundle (encryptedData.der)
Successfully decoded EncryptedData bundle (encryptedData.der)

Be sure to examine how wolfCrypt’s usage varies across different content and RecipientInfo types. And in no time, you’ll be putting wolfSSL’s PKCS#7 API to good use and further strengthening the security for your IoT devices requiring TLS functionality.

Documentation and more information on PKCS#7 are located within doxygen pages, here: Algorithms – PKCS7 (wolfssl.com).

Wikipedia article on PKCS#7: https://en.wikipedia.org/wiki/PKCS_7

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 supports TLS 1.3 ! http://www.wolfssl.com/tls13

Checkout out latest release: https://www.wolfssl.com/download

We are excited to tell you about our partner collaboration with STMicroelectronics! This collaboration is a video series about wolfBoot, a secure bootloader and the STM32, a family of 32-bit microcontrollers.

This will be at least a 4 part video series with the first two already up and ready and the next two videos already planned

Video 1: wolfBoot for STM32, Part 1: Overview https://www.youtube.com/watch?v=9R4Gl0qrzZ0

• “Overview of the wolfSSL products and the wolfBoot support for STM32 devices. The wolfBoot product features such as secure boot, measured boot, encrypted partitions and root of trust (in the bootloader, TPM or secure element). Comparison of the SBSFU, TFM and wolfBoot options for STM32 micro-controllers. Implementation details for design of wolfBoot and how the partitions are defined.”

Video 2: wolfBoot for STM32, Part 2: Getting Started https://www.youtube.com/watch?v=e5VwYA5kknA

• “How to download wolfBoot, where to find files and documentation. The wolfBoot product features such as secure boot, measured boot, encrypted partitions and root of trust (in the bootloader, TPM or secure element).”

Video 3: wolfBoot Out of the box with STM32G0.

Video 4: How to expand the wolfBoot HAL support for a new target.

Stay tuned for more information on when the next part of this video series goes live.

Additional Resources

• https://www.st.com/en/embedded-software/wolfboot.html
• 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.

In the meanwhile, check out the wolfSSL embedded SSL/TLS library, star us on Github, and learn more about the latest TLS 1.3 is available in wolfSSL.

At wolfSSL, we pride ourselves on offering the Best-Tested SSL/TLS library on the market. We’re able to do so by conducting regular, diligent, and well-planned testing to maintain a robust and secure library. wolfSSL knows that it is impossible to test every single possible path through the software, but opts to practice an approach that is focused on lowering risk of failure. wolfSSL implements an extensive internal testing plan that not only uses automated testing, but makes sure to test well-known use cases. A key process in wolfSSL’s internal testing plan is Fuzz Testing.

What is Fuzz Testing?

Fuzz testing, also known as fuzzing, is an automated software testing technique that is conducted to reveal coding errors and security loopholes in softwares, networks, or operating systems. A fuzz test is a technique that is widely used to discover defects which otherwise would not be identified by merely using traditional functional testing methods. Fuzzing is a black box testing technique that bombards a library with invalid, unexpected, or random data (known as fuzz to the system) in an attempt to expose inputs that cause the system to crash, fail in unexpected ways, or leak memory. This allows wolfSSL to catch bugs that could turn into potential vulnerabilities before they are able to make it into a release!

Fuzzing at wolfSSL

wolfSSL was the first TLS to adopt fuzz testing, and firmly believes that if a TLS and cryptography provider does not do fuzz testing, they are extremely exposed. wolfSSL runs 7 internal fuzz testers nightly to ensure the most secure library on the market. wolfSSL tests using several different software fuzzers, including: 

• an in-memory fuzzer (managed by wolfSSL)
• a network fuzzer (managed by wolfSSL)
• OSS-fuzz (service to run tests provided by Google, tests created by wolfSSL and Guido)
• libfuzzer (tests created and ran by wolfSSL)
• tlsfuzzer (project from https://github.com/tlsfuzzer/tlsfuzzer, test is ran by wolfSSL)
• AFL (tests created and ran by wolfSSL)
• Third-party fuzz testing from Robert Horr

As a testament to wolfSSL’s commitment to security, highly respected external testers are utilized when possible. Some of our partners include Guido Vranken in Holland and Robert Horr of T-Systems in Germany. (Check out their guest blog posts: Fuzzing for wolfSSL by Guido Vranken, and Modern testing of the wolfSSL TLS library by Robert Horr).

As stated in the wolfSSL 2019 Annual Report, wolfSSL is the best-tested cryptography on market, more so than OpenSSL, due to consistent implementation of additional fuzz testing resources from both internal and external sources.

For further details regarding the internal wolfSSL process of testing to ensure code quality and security, please reference this blog page.

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

If there is a desire to include other SSL/TLS or crypto implementations in wolfSSL interop testing, please let us know. Likewise, if users would like to include wolfSSL in their own test framework, we would be happy to discuss!

The ALPACA attack may affect TLS servers who share multiple services and protocols on the same TLS endpoint/instance. The attack is difficult to implement because it requires a Man-in-the-Middle (MitM) position that can intercept and divert the victim’s traffic at the TCP/IP layer. 

As the TLS protocol does not protect the integrity of the TCP connection itself this attack redirects traffic from the intended TLS service to another service on the same endpoint. If the client considers the certificate of the substitute server to be valid for the intended server the authentication of the connection is violated.

This can enable cross-protocol attacks at the application layer, where the client unknowingly sends the protocol data for the intended server to the substitute server that expects a different protocol, potentially compromising the security of either server at the application layer.

For server’s hosting multiple services / protocols on the same endpoint here are steps to help prevent this attack:

1) Enable ALPN: The client and server should enable ALPN by setting `–enable-alpn` or by defining `HAVE_ALPN` and initialize ALPN by calling `wolfSSL_UseALPN`. The server (and preferably the client, too) should use the `WOLFSSL_ALPN_FAILED_ON_MISMATCH` option to enforce strict ALPN verification.

2) Enable SNI: The client and server should enable SNI by setting `–enable-sni` or by defining `HAVE_SNI`. The client should initialize it by calling `wolfSSL_UseSNI`. The server should implement a custom verification for the SNI hostname using the `wolfSSL_CTX_set_servername_callback`.

Links

* ALPACA Attack Paper: https://alpaca-attack.com/index.html#paper

* Instructions for wolfSSL: https://alpaca-attack.com/libs.html#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 Blog Series

From the early days of the wolfSSL library, we have provided example clients and servers with wolfSSL. These examples have shown how easy it is to use wolfSSL in various configurations. We also use them to help test the library. Over the years we’ve added new features available with TLS to our examples, and our examples have grown a little complicated.

Enter the wolfSSL Examples GitHub repository. This repository contains example clients and servers that set up and test various types of connections. They give you a bare-bones simple demonstration on how to set up a client or server using wolfSSL. In addition to these client/servers, our developers have included examples that demonstrate how to build wolfSSL with specific real time operating systems and TCP/IP stacks for embedded systems and devices, how to link with the wolfSSL library with a simple Enclave, and even how to use some features of the library like the certificate manager or wolfCrypt’s public-key functionality.

The repository contains example applications written in C, each directory represents a unique topic (TLS, DTLS, PSK, etc.) and contains a Makefile as well as a simple tutorial on the given topic. The wolfSSL Examples GitHub repository is a great way to gain familiarity with the wolfSSL lightweight SSL/TLS library so this upcoming blog series will be showcasing it and each topic/directory it contains. Here’s a comprehensive list of the topics to be covered.

android (Android NDK Examples)

This directory contains examples that demonstrate using wolfSSL and wolfSSLJNI on the Android platform, using the Android NDK toolchain.

BTLE

This directory contains examples for securing a Bluetooth Low Energy Link (BTLE). BTLE packets are small and throughput is low, so these examples demonstrate a way to exchange data securely without BTLE pairing.

certfields (X509 field extraction)

This directory contains an example that demonstrates using wolfSSL to read a DER encoded certificate and extract the public key and subject name information.

certgen (wolfSSL Certificate Generation)

This directory contains examples that demonstrate using wolfSSL to generate and sign certificates.

certmanager (wolfSSL CertManager)

This directory contains examples that demonstrate using CertManager (Certificate Manager) functionality.

crypto (wolfCrypt Examples)

This directory contains examples that demonstrate using the wolfCrypt functionality to encrypt files with different algorithms (AES, 3DES, etc.)

custom-io-callbacks (wolfSSL Custom IO Callbacks)

This directory contains examples that demonstrate how the custom IO callbacks can be used to facilitate a TLS connection using any medium.

DTLS (Datagram TLS)

This directory contains examples of using DTLS, with client and server examples demonstrating UDP, DTLS, non-blocking, session resumption, and multi-threading.

ecc (Elliptic Curve Cryptography)

This directory contains examples that demonstrate the various use-cases of wolfCrypt ECC.

embedded (Embedded Systems)

This directory contains examples that demonstrate TLS client/servers communicating through buffers and using sockets.

hash (wolfCrypt Hash Examples)

This directory contains examples that demonstrate how to hash an input file using wolfCrypt.

java (wolfJSSE Examples)

This directory contains examples that demonstrate HTTPS URL use with wolfJSSE and example keystores.

mynewt (Apache Mynewt Examples)

This directory contains examples that demonstrate using wolfSSL with Apache Mynewt OS.

picotcp (picoTCP Examples)

This directory contains a TLS server created by using picoTCP via wolfSSL custom callbacks.

pk (Public-Key)

This directory contains examples that demonstrate various wolfCrypt public-key functionality (storing and loading keys after generation, extracting public key from private key, etc.).

pkcs11 (PKCS #11)

This directory contains examples of using wolfSSL’s PKCS #11 feature and a TLS server example using a PKCS 11 based key.

pkcs7 (PKCS #7)

This directory contains example applications that demonstrate usage of the wolfCrypt PKCS#7/CMS API, included in the [wolfSSL embedded SSL/TLS library].

PSK (Pre-Shared Keys)

This directory contains examples of using PSK, with client and server examples demonstrating TCP/IP, PSK, non-blocking, session resumption, and multi-threading.

riot-os-posix-lwip (RIOT-OS)

This directory contains examples that demonstrate how to use wolfSSL TLS sockets over RIOT-OS POSIX sockets.

RT1060 (i.MX RT1060-EVK)

This directory contains a wolfCrypt benchmark test application for i.MX RT1060-EVK.

SGX_Linux (Linux Enclave)

This directory contains an example application, written in C, which demonstrates how to link the wolfSSL lightweight SSL/TLS library with a simple Enclave (SGX) using Linux .

SGX_Windows (Windows Enclave)

This directory contains an example application, written in C++, which demonstrates how to link the wolfSSL lightweight SSL/TLS library with a simple Enclave (SGX) using Windows.

signature (Sign and Verify Examples)

This directory contains examples that demonstrate using wolfSSL to sign and verify binary data (supports RSA and ECC for signing and MD2, MD4, MD5, SHA, SHA224, SHA256, SHA384 and SHA512).

tirtos_ccs_examples (TI-RTOS)

This directory contains a client/server example that demonstrates using wolfSSL in a TI-RTOS ecosystem.

TLS

This directory contains examples of using SSL/TLS, with client and server examples demonstrating TCP/IP, SSL/TLS, non-blocking, session resumption, and multi-threading.

utasker (uTasker wolfSSL Example Tasks)

This directory contains example uTasker client and server tasks that demonstrate using wolfSSL with the uTasker stack. These have been tested on the uTasker Simulator.

wolfCLU (wolfSSL Command Line Utility)

This is a tool to provide command line access to wolfCrypt cryptographic libraries. wolfSSL command line utility will allow users to encrypt or decrypt a user specified file to any file name and extension.

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 supports TLS 1.3 ! http://www.wolfssl.com/tls13

Checkout out latest release: https://www.wolfssl.com/download