Month: July 2021

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!

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

For more information about wolfSSL and PKCS#7 contact us at facts@wolfssl.com.

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/

Please contact us at facts@wolfssl.com with any questions about the webinar.

For technical support, please contact support@wolfssl.com or view our FAQ page.

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 there are any specific questions about how wolfSSL tests, please contact our team at facts@wolfssl.com. 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

For questions email support@wolfssl.com

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.

Please contact wolfSSL at support@wolfssl.com with any questions, bug fixes, or suggested feature additions.

wolfSSL supports TLS 1.3 ! http://www.wolfssl.com/tls13

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

Clavister, one of Europe’s leading cybersecurity vendors, announced that their latest release of OneConnect for macOS, iOS and iPadOS utilizes acceleration from wolfSSL for better performance metrics. 

“We managed to leverage the acceleration in wolfSSL and could see a reduction of cpu usage (which should translate into better battery life),” says Clavister. If you’re not familiar with our performance benchmarks, visit our benchmarks page. 

wolfSSL is constantly expanding our hardware acceleration support portfolio. Check out our website for more information and send us a message to inquire about support for your target.

View Clavister’s announcement here. 

Follow wolfSSL on LinkedIn to stay tuned to more updates and use cases! Want to share how wolfSSL has helped your customers win? Write to us at facts@wolfSSL.com.

 

wolfSSL version 4.8.1 is available for download!!

This version of wolfSSL includes many new features, ports, and some great fixes. Some of the new features added includes:

• A tie in for use with wolfSentry. 
  • wolfSentry is a universal, dynamic, embedded IDPS (intrusion detection and prevention system)
  • The build option added to enable the code for use with wolfSentry can be compiled using the autotools flag –enable-wolfsentry. wolfSentry is our new product that can be used in a similar fashion as a firewall but unlike many firewall applications available today wolfSentry is designed for deeply embedded IoT devices with resource constraints.
  • Learn more from our webinar: Introducing wolfSentry, an Embeddable IDPS

• A number of API for the compatibility layer 
  • Helps support replacing OpenSSL using wolfSSL along with updating your crypto for FIPS requirements, 
• A QNX CAAM driver for use with NXP’  i.MX devices, 
  • CAAM stands for Cryptographic Accelerator and Assurance Module. When used, it speeds up the cryptographic algorithms such as ECC and AES, as well as increases security by using encrypted keys and secure memory partitions.
• Support for STM32G0, 
• Zephyr project example,
  • The Zephyr Project is a scalable real-time operating system (RTOS) supporting multiple hardware architectures, optimized for resource constrained devices, and built with safety and security in mind.
• An easy-to-use Dolphin emulator test for DEVKITPRO
  • devkitPro is a set of tool chains for compiling to gaming platforms.
• Fixes for PKCS#7 
  • PKCS#7 is used to sign, encrypt, or decrypt messages under Public Key Infrastructure (PKI). It is also used for certificate dissemination, but is most commonly used for single sign-on.
• Better parsing and handling of edge cases along with fixes for existing ports. 
• Fixes that came from testing with Coverity and fsanitizer tools. 
  • Coverity is very efficient in finding issues, and is often used as a metric for good code (based on how many issues are found and fixed)
  •  fsanitizer is a static analysis tool
• Two vulnerabilities announced, 
  • one dealing with OCSP 
    • OCSP or “Online Certificate Status Protocol” is an Internet protocol that is used to obtain the revocation status of an X.509 digital certificate.
  • the other with a previously fixed base64 PEM decoding side channel vulnerability.
    • PEM, or “Privacy Enhanced Mail” is the most common format that certificates are issued in by certificate authorities.

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). Any questions can be sent directly to facts@wolfssl.com.

The summer release of wolfMQTT v1.9.0 is now available! This release has several bug fixes and features including:

• Fixes for Sensor Network client (PR #204, 214, 219)
• Fixes for non-blocking (PR #205)
• Fixes for multithread (PR #207, 209, 211, 218)
• Fix for MQTTv5 publish response handling (PR #224, 220)
• Fix subscribe return code list (PR #210)
• Fix switch statement fallthrough on other toolchains (PR #225)
• Add HiveMQ Cloud capability with SNI feature (PR #222)
• Add ability to publish files from example client, fix chunked publish (PR# 223)

Check out the changelog from the download for a full list of features and fixes, or contact us at facts@wolfssl.com with any questions:
https://github.com/wolfSSL/wolfMQTT/blob/master/ChangeLog.md

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