RECENT BLOG NEWS

wolfSSL is at wolfSSL at NXP Tech Days Minneapolis this year! NXP Technology Days is a deep-dive, technical training program for engineers designing solutions with embedded technology. This one-day event offers hands-on workshops and technical lectures over multiple markets enabling attendees to customize a schedule that is most relevant to their training needs.

Where wolfSSL will be located for this Tech Days:
Venue: Doubletree by Hilton Minneapolis Park Place
When: April 16, 2019
Directions: https://doubletree3.hilton.com/en/hotels/minnesota/doubletree-by-hilton-hotel-minneapolis-park-place-MSPPHDT/maps-directions/index.html

Stop by to hear more about the wolfSSL embedded SSL/TLS library, the wolfCrypt encryption engine, to meet the wolfSSL team, or to get some free stickers and swag!

For more information about wolfSSL, its products, or future events, please contact facts@wolfssl.com.

More information about NXP Tech Days can be found here: https://www.nxp.com/support/training-events/nxp-technology-days:NXP-TECH-DAYS

People have been asking if wolfSSL is vulnerable to the ’Selfie’ attack (https://eprint.iacr.org/2019/347).  We are glad to say that we follow all the recommendations made by the authors.  First, though, an explanation of the attack.

Overview

The attack targets the use of Pre-Shared Keys (PSKs) with TLS 1.3 though TLS 1.2 is also vulnerable.  There are very specific use cases that are affected. When a group of computers want to connect to each other then sharing a PSK is a simple way to set things up. Membership of the group is based on the knowledge of the PSK.  This means that certificate authentication is not used.

Attack

The attack scenario is when a new computer comes into the network that can intercept or Man-in-the-Middle (MitM) the communications between computers.  When a computer, let’s call it Alice, acting as a client sends a TLS ClientHello, the MitM, which we’ll call Eve, reflects the message back in a new connection to Alice.  Alice acting as a server sees a new TLS ClientHello and in parallel responds with the first round of messages. These messages are sent back by Eve to the client on Alice. Alice as a client uses the messages to establish a connection and sends a response.  Eve uses the response to respond to Alice the server and so on and a secure connection is established.

Because everyone is using the same PSK for client and server connections, Alice does not notice anything wrong!  Now that a secure connection has been established, which Eve cannot decrypt, it can be hard to see what the issue would be.  The attack comes when a message like ‘Delete your copy of this file, I have a copy’ is sent. Eve reflects the message back and Alice decides that the she doesn’t have to keep a copy after all and deletes it.

The paper lists a number of scenarios that may be vulnerable:

• Content Delivery Networks (CDNs) - poisoning caches.
• P2P Networks.
• WiFi networks that rely on PSKs for the entire network.
• Leader-election and consensus protocols.

Mitigations and Recommendations

One way to prevent this attack is to use the Server Name indicator (SNI) extension. This way Alice recognises she didn’t connect to the computer she wanted to but to herself.

The recommendations of the paper are:

• Don’t share PSKs amongst a group of computers unless certificates are used initially to establish identity. This goes against the PSK use case!
• If you must use a shared PSK without certificates, then use the SNI extension.
• TLS toolkits should either not implement PSK or not have it configured by default.

By default in wolfSSL, PSKs are not enabled but are available for use when you need it.  wolfSSL also implements the SNI extension and we encourage you to use it.

For more information about the wolfSSL library, please contact facts@wolfssl.com.

With the recent release of wolfSSL 4.0.0, the wolfSSL team has also released a new product: the wolfSSL FIPS Ready library. This product features new, state of the art concepts and technology. In a single sentence, wolfSSL FIPS Ready is a testable and free to download open source embedded SSL/TLS library with support for FIPS validation, with FIPS enabled cryptography layer code included in the wolfSSL source tree. To further elaborate on what FIPS Ready really means, you do not get a FIPS certificate and you are not FIPS approved. FIPS Ready means that you have included the FIPS code into your build and that you are operating according to the FIPS enforced best practices of default entry point, and Power On Self Test (POST).

FIPS validation is a government certification for cryptographic modules that states that the module in question has undergone thorough and rigorous testing to be certified. FIPS validation specifies that a software/encryption module is able to be used within or alongside government systems. The most recent FIPS specification is 140-2, with various levels of security offered (1-5). Currently, wolfCrypt has FIPS 140-2 validation with certificates #2425 and #3389. When trying to get software modules FIPS validated, this is often a costly and time-consuming effort and as such causes the FIPS validated modules to have high price tags.

Since the majority of wolfSSL products use the wolfCrypt encryption engine, this also means that if wolfSSH, wolfMQTT (with TLS support), wolfBoot, and other wolfSSL products in place can be tested FIPS validated code with their software before committing.

wolfSSL FIPS Ready can be downloaded from the wolfSSL download page, here: https://www.wolfssl.com/download/

For more information about wolfSSL and its FIPS Ready initiative, please contact facts@wolfssl.com.

Recently, we announced that there was support for JSSE in the works at wolfSSL. That project is currently nearing completion, and wolfSSL will soon be happy to announce its support for providing JSSE included with the wolfSSL-JNI library!

Java Secure Sockets Extension (JSSE) is a way for Java applications to utilize the SSL and TLS protocols through a standardized Java API using pluggable “providers” underneath - which is where wolfSSL will come in to place. wolfSSL provides SSL and TLS support up to the most recent versions of these protocols, and also provides high speed and strength encryption as well. Other beneficial features include potential use of wolfCrypt FIPS, low footprint, high portability, and more!

Stay tuned for the release of wolfSSL's support for providing JSSE! For more information, please contact facts@wolfssl.com.

With the recent release of wolfSSL 4.0.0, the wolfSSL embedded SSL/TLS library comes with many new features and improved functionality. Among these features is the addition of a port to the Zephyr Project - a scalable real-time operating system (RTOS) supporting multiple hardware architectures, optimized for resource constrained devices, and built with safety and security in mind.

wolfSSL's Zephyr port comes with multiple test and example applications, such as the wolfCrypt unit tests, wolfSSL TLS with sockets, and wolfSSL TLS with threads example applications. This Zephyr port allows for its users to easily implement lightweight, high-speed and strong encryption for secure data transfer on their devices. As both Zephyr and wolfSSL are targeted for resource-constrained and embedded devices, this combination only makes sense.

More information about the 4.0.0 release of wolfSSL can be found in our blog post here: https://www.wolfssl.com/wolfssl-4-0-0-now-available/

For other information or queries, please contact facts@wolfssl.com.

Are you a user of the ESP-IDF(Espressif IoT Development Framework)? If so, you will be happy to know that wolfSSL recently added support and example projects to the wolfSSL embedded SSL/TLS library for ESP-IDF.

ESP-IDF is intended for rapidly developing Internet-of-Things (IoT) applications, with Wi-Fi, Bluetooth, power management and several other system features.

The ESP-IDF “Get Started” document can be found here:

https://docs.espressif.com/projects/esp-idf/en/latest/get-started/index.html

In order to use wolfSSL under ESP-IDF, you need to deploy wolfSSL source files into the IDE. Please see the README.md placed in the “IDE/Espressif/ESP-IDF/” directory of wolfSSL source tree. In addition to that, example projects including TLS server/client, wolfCrypt test and benchmark are also provided. For building these examples, please see each README.md in example projects directories. When working with ESP-IDF, wolfSSL worked with the ESP32-WROOM-32 device.

wolfSSL also has a page that elaborates upon the use of Espressif with wolfSSL and the Espressif hardware devices, located here: https://www.wolfssl.com/docs/espressif/

Our wolfSSL master branch can be cloned here:
https://github.com/wolfSSL/wolfssl

The README.md can be found here:
https://github.com/wolfSSL/wolfssl/blob/master/IDE/Espressif/ESP-IDF/README.md

Additional examples for wolfSSL TLS Client/Server and wolfCrypt test/benchmark applications can be found here:
https://github.com/wolfSSL/wolfssl/tree/master/IDE/Espressif/ESP-IDF/examples

This support is currently located in our GitHub master branch, and will roll into the next stable release of wolfSSL as well. For any questions or help getting wolfSSL up and running on your ESP-IDF environment, please contact us at support@wolfssl.com.

wolfSSL's embedded SSL/TLS library provides support for many different features, such as TLS 1.3, a FIPS 140-2 validation, and even support for SSL/TLS using less traditional I/O.  In this context, “less traditional I/O” means running SSL/TLS over something besides TCP/IP or UDP - for example Bluetooth, a serial connection, memory buffers, or a proprietary transfer protocol.  In embedded projects, we know it can be common.

The wolfSSL embedded SSL/TLS library provides a mechanism to plug in your own application-specific I/O routines. By default, the library calls a BSD socket API, with functions that call the system’s recv() and send() using a file descriptor that has been cached with wolfSSL_set_fd().

The prototypes for the I/O callback functions are:

    typedef int (*CallbackIORecv)(WOLFSSL *ssl, char *buf, int sz, void *ctx);
    typedef int (*CallbackIOSend)(WOLFSSL *ssl, char *buf, int sz, void *ctx);

In the default case, the network socket file descriptor is passed to the I/O callback through the “ctx” parameter. The “ssl” parameter is a pointer to the current wolfSSL session, giving callbacks access to session-level details if needed.

In the receive case, “buf” points to the buffer where incoming ciphertext should be copied for wolfSSL to decrypt and “sz” is the size of the buffer. Callbacks should copy “sz” bytes into “buf”, or the number of bytes available.  In the send case, “buf” points to the buffer where wolfSSL has written ciphertext to be sent and “sz” is the size of that buffer. Callbacks should send “sz” bytes from “buf” across their transport medium. In either case the number of bytes written or read should be returned, or alternatively an applicable error code.

To register your own I/O callbacks with the wolfSSL Context (WOLFSSL_CTX) for your application, use the functions wolfSSL_SetIORecv() and wolfSSL_SetIOSend().

    wolfSSL_SetIORecv(ctx, myCBIORecv);
    wolfSSL_SetIOSend(ctx, myCBIOSend);

An example use case for alternative I/O would be to have a server with a datagram socket which receives data from multiple clients or processes TLS through STDIN and STDOUT. In this case you would have four buffers:

    cipher-receive     encrypted data received from peer
    cipher-send        encrypted data to send to peer
    clear-receive      clear data received from wolfSSL
    clear-send         clear data passed to wolfSSL

Pointers to these buffers, values for their sizes, and read and write positions might be placed into a user-defined structure. A pointer to this structure could then be cached in the wolfSSL session with the functions wolfSSL_SetIOReadCtx() and wolfSSL_SetIOWriteCtx().

    wolfSSL_SetIOReadCtx(ssl, buffer_data);
    wolfSSL_SetIOWriteCtx(ssl, buffer_data);

The application would receive a block of ciphertext into the buffer “cipher-receive”. Next the application would call wolfSSL_read(ssl, buffer_data->clear_receive), causing wolfSSL to call the registered receive callback. That receive callback will be given a buffer, the size of the buffer, and the ctx, which has the “cipher-receive” buffer. The callback may be called many times internally for one call to wolfSSL_read(). If the “cipher-receive” buffer is empty, the callback should return WOLFSSL_CBIO_ERR_WANT_READ, otherwise it should return the number of bytes copied into “buf”.

When the library wants to send data, during handshaking or when wolfSSL_send() is called with plaintext, the library will call the registered send callback. The callback is given a buffer full of encrypted data, and the length of the encrypted data. In this example, the callback would copy this cipher text into “cipher-send” and return the number of bytes copied. If the “cipher-send” buffer isn’t big enough, the callback should return WOLFSSL_CBIO_ERR_WANT_WRITE.

If you are interested in looking over an example of using the wolfSSL I/O abstraction layer, we have an example client/server application at the following link that does TLS using files as the transport medium: https://github.com/wolfSSL/wolfssl-examples/tree/master/custom-io-callbacks

If you have questions about using wolfSSL’s custom I/O callback layer, please contact us at facts@wolfssl.com.

Are you looking for an SSL/TLS library which will seamlessly integrate into your bare metal or No-OS environment? If so, continue reading to learn why the wolfSSL lightweight SSL library is a perfect fit for such environments.

wolfSSL has been designed with portability and ease of use in mind, allowing developers to easily integrate it into a bare metal or operating systemless environment. As a large percentage of wolfSSL users are running the library on small, embedded devices, we have added several abstraction layers which make tying wolfSSL into these types of environments an easy task.

Available abstraction layers include:

• Custom Input/Output
• Standard C library / Memory
• File system (Able to use cert/key buffers instead)
• Threading
• Operating System

In addition to abstraction layers, we have tried to keep wolfSSL’s memory usage as low as possible. Build sizes for a complete SSL/TLS stack range from 20-100kB depending on build options, with RAM usage between 1-36kB per connection.

To learn more about how to integrate wolfSSL into your environment or get more information about reducing wolfSSL’s memory usage, please see the wolfSSL Manual or contact us directly.

wolfSSL recently released version 4.0.0 of the wolfSSL embedded SSL/TLS library with a litany of port additions. One of these new ports is added functionality for Cypress’s WICED Studio SDK! WICED Studio is an SDK targeting IoT devices, offering both Bluetooth and WI-Fi (IEEE 802.11) development platforms. WICED SDK offers code examples and tools for embedded development boards including Adafruit Feather boards which, is a great alternative to Arduino for student boards. The code examples demonstrate the use of wolfCrypt and integrate wolfSSL functionality into the WICED platform. A TLS client and server was added using the wolfSSL library, as well as, an HTTPS client example. wolfSSL supplies a client and server for testing purposes, the HTTPS client example also runs against the wolfSSL example server as well as www.example.com for demonstration purposes.

wolfSSL is a highly configurable option to accompany WICED software allowing manual configuration options affecting functionality and build size. The examples provided serve as a starting point for any embedded project and works with TLS versions 1.0, 1.1, 1.2, and 1.3; they are built on the ThreadX RTOS using NetX Duo for the TCP/IP stack.

wolfSSL v4.0.0.0 can be downloaded from the wolfSSL download page, or from the GitHub repository here: https://github.com/wolfssl/wolfssl.git.

Supported functionality and features:

• wolfCrypt test suite and benchmark test
• wolfSSL TLS client and server
• wolfSSL HTTPS client
• NetX Duo TCP/IP stack for embedded systems
• ThreadX RTOS for embedded platforms
• Server Name Indication (SNI) extension
• Maximum fragment length extension
• Truncated HMAC
• TLS versions 1.0, 1.1, 1.2, and 1.3
• Certificate verification
• Certificate chain loading
• RSA and ECC certificates
• Multithread capability
• Session resumption

Cipher suites supported out of the box:

ECDHE-ECDSA-AES128-GCM-SHA256
ECDHE-ECDSA-AES128-SHA
ECDHE-ECDSA-AES256-GCM-SHA384
ECDHE-ECDSA-AES256-SHA384
ECDHE-ECDSA-CHACHA20-POLY1305
ECDHE-RSA-AES128-GCM-SHA256
ECDHE-RSA-AES128-SHA
ECDHE-RSA-AES256-GCM-SHA384
ECDHE-RSA-AES256-SHA
ECDHE-RSA-CHACHA20-POLY1305
AES128-GCM-SHA256
AES256-SHA256
AES256-GCM-SHA384
AES128-SHA

Cipher suites supported for TLS 1.3 out of the box:

TLS13-AES128-GCM-SHA256
TLS13-AES256-GCM-SHA384
TLS13-CHACHA20-POLY1305-SHA256
TLS13-AES128-CCM-SHA256