RECENT BLOG NEWS

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

We’re happy to announce that wolfSSL is currently working on a Java Secure Socket Extensions (JSSE) provider for the native wolfSSL embedded SSL/TLS library!  JSSE is a way for Java applications to utilize the SSL and TLS protocols through a standardized Java API using pluggable “providers” underneath. It was integrated into Java versions following Java 1.4. With this upcoming provider, Java applications will have the ability to use the most recent and secure version of the TLS protocol, TLS 1.3!  And for FIPS 140-2 users, this will allow Java applications to use wolfCrypt FIPS underneath if needed.  Additionally, this will also allow users to take advantage of other features offered by the wolfSSL library such as high-speed and high-strength encryption, high portability, low footprint size, and more!

Are you interested in a JSSE provider for wolfSSL?  For more information about the wolfSSL library, its features, or if you would like to share your interest on this feature addition, please contact facts@wolfssl.com.

Reference
wolfSSL GitHub repository: https://github.com/wolfssl/wolfssl.git
Oracle JSSE reference guide: https://docs.oracle.com/javase/8/docs/technotes/guides/security/jsse/JSSERefGuide.html#Introduction

wolfSSL is at Japan IT Week - Spring this year! Japan IT Week Spring occurrs twice this year, once in April and once in May. wolfSSL will be attending the event in April, which will include two exhibitions: IoT/M2M Expo Spring and Embedded Systems Expo. For 2019, Japan IT Week Spring (part 1) will be held in Tokyo, Japan.

Where wolfSSL will be located for Japan IT Week:
Venue: Tokyo Big Sight
Booth #: 6-9, West Hall
When: April 10-12
Directions: https://www.japan-it-spring.jp/en-gb/visit/access.html

Stop by to hear more about the wolfSSL embedded SSL/TLS library, the wolfCrypt encryption engine, to meet the wolfSSL Japan 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 Japan IT Week Spring can be found here: https://www.japan-it-spring.jp/ja-jp.html

wolfSSL's wolfSSH library is a small footprint, fast, embedded SSH implementation. With recent additional support and adjustments, support for non-blocking connections has been added to the library! This allows for use of non-blocking connections with other features besides SSH, such as use with SFTP and SCP. This non-blocking support is supported by default and is easy to use. The default API can be called and the wolfSSH library internally handles all saving and restoring of states, returning WS_WANT_READ or WS_WANT_WRITE when calling wolfSSH_get_error() to signal if the API should be called again. The library is designed to be easy to use and quick to integrate into an application.

For more information about wolfSSH or using it in your project, please contact facts@wolfssl.com.

Spring is here, and along with it is the newest and shiniest release of the wolfSSL embedded SSL/TLS library!

As with every release, this release includes many feature additions, bug fixes, and improvements to the wolfSSL library. Additionally, this new version of the wolfSSL library includes support for the new FIPS 140-2 Certificate for wolfCrypt v4.0! More information on wolfSSL and FIPS can be found here: https://www.wolfssl.com/license/fips/.

The list below outlines the new feature additions that are included with the release of wolfSSL version 4.0.0:

• Support for wolfCrypt FIPS v4.0.0, certificate #3389
• FIPS Ready Initiative
• Added TLS server side secure renegotiation
• Added TLS Trusted CA extension
• Support for the Deos Safety Critical RTOS
• TLS handshake now supports using PKCS #11 for private keys
• PKCS #11 support of HMAC, AES-CBC and random seeding/generation
• Support for named FFDHE parameters in TLS 1.2 (RFC 7919)
• Added Espressif ESP32 WROOM support with hardware crypto acceleration. More data can be found here: https://www.wolfssl.com/docs/benchmarks/#espressif_esp32_wroom.
• Added Cypress WICED Studio support
• Added ARM CMSIS-RTOS v2 support
• Added port to the Zephyr Project
• Added Cortex-M support for Single Precision (SP) math
• Added wolfCrypt RSA non-blocking time support
• Added 16-bit compiler support using --enable-16bit option

Additionally, the wolfSSL blog will be posting more elaboration and details on the ports and support that have been added with this release in the furture. Stay tuned for more information!

The following list outlines the various fixes, updates, and general improvements that have been included with wolfSSL 4.0.0:

• Added new wrapper for snprintf for use with certain Visual Studio builds
• Added ECC_PUBLICKEY_TYPE to the supported PEM header types
• Added strict checking of the ECDSA signature DER encoding length
• Added ECDSA option to limit sig/algos in client_hello to key size with USE_ECDSA_KEYSZ_HASH_ALGO
• Compatibility fixes for secure renegotiation with Chrome
• Better size check for TLS record fragment reassembly
• Improvements to non-blocking and handshake message retry support for DTLS
• Improvements to OCSP with ECDSA signers
• OCSP fixes for memory management and initializations
• Fixes for EVP Cipher decryption padding checks
• Removal of null terminators on wolfSSL_X509_print substrings
• wolfSSL_sk_ASN1_OBJCET_pop function renamed to wolfSSL_sk_ASN1_OBJECT_pop
• Adjustment to include path in compatibility layer for evp.h and objects.h
• Fixes for decoding BER encoded PKCS7 contents
• Move the TLS PRF to wolfCrypt.
• Update to CMS KARI support
• Fixes and additions to the OpenSSL compatibility layer
• Xcode project file update
• Fixes for ATECC508A/ATECC608A
• Fixes issue with CA path length for self signed root CA's
• Fixes for Single Precision (SP) ASM when building sources directly
• Fixes for STM32 AES GCM
• Fixes for ECC sign with hardware to ensure the input is truncated
• Fixes for proper detection of PKCS7 buffer overflow case
• Fixes to handle degenerate PKCS 7 with BER encoding
• Fixes for TLS v1.3 handling of 6144 and 8192 bit keys
• Fixes for possible build issues with SafeRTOS
• Improved Arduino sketch example
• Improved crypto callback features
• Improved TLS benchmark tool

There was also a bug in the tls_bench.c example test application (unrelated to the crypto or TLS portions of the library) that was resolved in wolfSSL 4.0.0 - CVE-2019-6439.

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 contact facts@wolfssl.com.

Since earlier versions, wolfSSL's embedded SSL/TLS library has been included with MPLAB Harmony. MPLAB Harmony is a flexible, fully integrated embedded software development framework for 32-bit MCUs and MPUs. Recently, MPLAB Harmony version 3 was released, with wolfSSL packaged within! The new release of MPLAB Harmony features aspects from the latest version of wolfSSL, version 3.15.7. wolfSSL is included in such a way that the example applications, demos, and source code of the wolfSSL library can be easily integrated and executed with other MPLAB projects. Additionally, other software libraries and examples are also being included in this new release of MPLAB Harmony, such as CMSIS-FreeRTOS.

For more information on the new release of MPLAB Harmony v3, please visit Microchip's page here: https://www.microchip.com/mplab/mplab-harmony/mplab-harmony-v3.

For more information about wolfSSL, wolfSSL with MPLAB Harmony, or other general inquiries, please contact facts@wolfssl.com.