RECENT BLOG NEWS

Many new additions and updates have been introduced in wolfSSL 3.9.6. For IoT and embedded SSL/TLS there was the addition of embOS and uTasker ports, each of these ports allowing for easily building wolfSSL on the respective environments. Updates were also done to STM32 crypto for using AES-GCM and AES-CCM, and updates were made to the MDK5 projects.

AES-NI saw an update for AES-CBC decrypt with wolfSSL version 3.9.6. This update decrypts 6 or 8 blocks at a time, greatly speeding up decryption times while using AES-NI. Additions that overlap both IoT and desktop platforms were also added like the addition of static memory. Compiling wolfSSL with –enable-staticmemory allows for using no dynamic memory while creating a SSL/TLS connection. This is useful for applications that wish to have a fixed amount of memory ahead of time and want more control over memory management. In addition to using static memory, compiling with –enable-sessionexport allows for serializing and exporting DTLS session information after the handshake is completed – giving the option of performing DTLS handshakes on one device and then sending that connection over to another device to handle throughput.

wolfSSL`s wrapper and OpenSSL compatibility layer were both expanded with the recent release. Version 3.9.6 introduced Python wrappers for crypto operations, allowing for integrating wolfSSL in Python projects. This easy to build wrapper is found in the directory “wolfssl-3.9.6/wrapper/python” along with a set of instructions for building it. Expansion to the OpenSSL compatibility layer was made with the introduction of dynamic session tickets. This makes it even easier for plug and replace when switching to use wolfSSL.

Furthering the progressiveness of wolfSSL, there was the addition of using the netRandom quantum random number generator from Whitewood. Now a quantum resistant cipher suite using NTRU can also be using a quantum random number generator. Making wolfSSL an excellent choice for quantum resistant security.

If looking to gain more speed with SSL/TLS connections operating in parallel to each other, check out the asynchronous operations addition to wolfSSL with this version. This keeps wolfSSL from blocking on SSL/TLS operations, such as RSA for example, in addition to non blocking on socket read/writes. If interested in using the new asynchronous features of wolfSSL please contact facts@wolfssl.com.

Along with all the additions and updates, some fixes were made to wolfSSL code with release 3.9.6. One fix was some edge case bugs with ECC when using ALT_ECC_SIZE and with key sizes over 256 bits. Additional code and comments on these ECC fixes can be found on our github page with pull requests #411, #416, and #428. The following list shows highlighted feature additions, updates and fixes.

Expanded list of release 3.9.6 for wolfSSL including new features and bug fixes:

– Add staticmemory feature, for using no dynamic memory allocation with wolfSSL
– Add public wc_GetTime API with base64encode feature
– Add AES CMAC algorithm, enabled using –enable-cmac
– Add DTLS sessionexport feature to serialize and send connection information. This allows for another system to take up the connection after the DTLS handshake has been performed
– Add python wolfCrypt wrapper. Located in directory wolfssl-3.9.6/wrapper/python.
– Add ECC encrypt/decrypt benchmarks. Can be ran with “./configure –enable-eccencrypt –enable-hkdf && make && ./wolfcrypt/benchmark/benchmark”
– Add dynamic session tickets to be used with openSSL compatibility
– Add eccshamir to configure.ac giving the option to compile without using ECC_SHAMIR. Can be used with ./configure –disable-eccshamir
– Add quantum RNG support with Whitewood netRandom, –with-wnr
– Add embOS port. Located in the directory wolfssl-3.9.6/IDE/IAR-EWARM/embOS
– Add minimum key size checks for RSA and ECC during TLS connection
– Add STARTTLS support to example client with ‘-M’ argument
– Add uTasker port. Macro define for uTasker can be found in wolfssl-3.9.6/wolfssl/wolfcrypt/settings.h
– Add asynchronous crypto and wolf event support
– Add compile check for misc.c with inline, this helps developers working in IDEs to not compile misc.c when not needed
– Add RNG benchmark to wolfcrypt/benchmark/benchmark.c
– Add reduction to stack usage with hash-based RNG
– Update STM32F2_CRYPTO port with additional algorithms supported, AES-GCM and AES-CCM
– Update MDK5 projects
– Update AES-NI to allow decrypting AES-CBC by 6 and 8 blocks at a time
– Fix for STM32 missing wc_ShaUdate return code with STM32F2_HASH defined
– Fix for function visibility warnings when building with MinGw
– Fix ECC math bugs with ALT_ECC_SIZE and key sizes over 256 bit. Code changes for ECC fix can be found at pull requests #411, #416, and #428
– Fix mismatch of certificate buffers to certificate files, github issue #422
– Fix decrypt max size with RSA OAEP. Previously in the case that the max message size allowed was being decrypted a bad padding error was returned
– Fix DTLS sanity check with DTLS timeout notification
– Fix free of WOLFSSL_METHOD on failure to create CTX
– Fix potential memory leak in failure case with wc_RsaFunction. Builds using RSA with using normal math and not RSA_LOW_MEM should update

Note: the tag v3.9.6w is for a simple port value fix with the echo server on a windows OS. This is with using Visual Studio as a development and testing environment.

For more information about any of the items on this list or information in general about wolfSSL contact us at facts@wolfssl.com

In the interest of supporting the lightweight cipher suites used in the IoT, wolfSSL has added ECDHE-ECDSA-AES128-CCM. This is an AEAD cipher suite with the perfect forward secrecy that ECDHE provides, using AES128 counter mode to encrypt the data and provide the 16-byte MAC. If there are any new ciphers or cipher suites you would be interested in having support for in the wolfSSL embedded SSL/TLS library, let wolfSSL know at facts@wolfssl.com.

We’ve added an Azure IoT Hub example to wolfMQTT in the v0.8 release. For this example we setup an Azure cloud server to demonstrate the IoT Hub. This example demonstrates how to connect/authenticate (creation of a SasToken), how to publish events and how to listening for device bound messages.

Release Notes:
* Fixed stdin capture bug and improved signal (ctrl+c) handling.
* Added Azure IoT hub MQTT client example.
* Added support for MQX / RTCS.
* Added “–disable-tls” and “–disable-examples” configure options.
* Added comment about max packet size.
* Added example for how to load a client certificate to mqttclient example.
* Added return code for firmware and azure examples that are not compiled in due to older / incompatible version of wolfSSL.
* Moved the support for custom printf/line endings into the mqtt_types.h for use throughout the project.
* Updated README.md with information about the examples.

If you have any questions about wolfMQTT or the wolfSSL embedded SSL/TLS library, contact us at facts@wolfssl.com

The Apple Worldwide Developers Conference (WWDC) is currently underway in San Francisco, CA this week. One of the conference topics, also mentioned in the Keynote, is the Swift programming language.

Swift, introduced roughly two years ago, is a programming language for macOS, iOS, watchOS, and tvOS that is gaining popularity with developers. This year at WWDC, several announcements were made including the introduction of the Swift Playgrounds app for iPad.

We would like to ask our user base if there is any interest in a Swift wrapper for the wolfSSL embedded SSL/TLS library. wolfSSL currently has language wrappers for Java, C#, and Python, and is generally portable across devices and operating systems. Are you interested in using wolfSSL from Swift? If so, let us know at facts@wolfssl.com!

WWDC16
Swift Programming Language (Apple)

We were recently reading about PikeOS and ElinOS, embedded operating systems from SYSGO AG and were curious if any wolfSSL users are interested in the wolfSSL embedded SSL/TLS library and wolfCrypt cryptography libraries running on these operating systems.  If you aren’t familiar with these operating systems, here’s a quick summary via Wikipedia:

PikeOS:

“PikeOS is a microkernel-based real-time operating system made by SYSGO AG. It is targeted at safety and security critical embedded systems. It provides a partitioned environment for multiple operating systems with different design goals, safety requirements, or security requirements to coexist in a single machine.”

ElinOS:

“ELinOS is a commercial development environment for embedded Linux. It consists of a Linux distribution for the target embedded system and development tools for a development host computer. ELinOS provides embedded Linux as a standalone operating system or it can be integrated into the PikeOS virtualization platform if safety and security demands cannot be met by Linux alone.”

If you are interested in seeing support in wolfSSL for these OS’s, let us know at facts@wolfssl.com!

We are pleased to inform that wolfCrypt has a new wrapper!

The wolfCrypt Python Wrapper allows use of the wolfCrypt embedded crypto library in a Python project. This will let users take advantage of the low footprint size of wolfCrypt in IoT projects that use the Python language.

Check out the wolfCrypt Documentation (https://wolfssl.github.io/wolfcrypt-py) and try it out.

For more info about using wolfCrypt with Python, or the wolfSSL embedded SSL/TLS library, contact us at facts@wolfssl.com.

wolfSSL has added support for embOS in the wolfCrypt embedded cryptography library. We have example projects in the “/IDE/IAR-EWARM/embOS/” directory which include a library to link against, a benchmark, and wolfcrypt_test that are preconfigured for Atmel’s SAMV71 Xplained Ultra when using IAR Embedded Workbench for ARM (EWARM). These examples are set up to build and run with no user modifications by default (After you download the documented software and have on hand the necessary hardware).

The examples will be available in the next stable release of the wolfSSL embedded SSL/TLS library and are currently available in the wolfSSL development branch at: https://github.com/wolfssl/wolfssl

There is a README_custom_port that will assist in creating a project that targets a different MPU as well. As always we are more than willing to help anyone get setup and going so please feel free to contact us support@wolfssl.com if you ever have any questions!

When using wolfSSL with MYSQL the portability and robustness refined in the IoT realm meets databases. The patch has been updated to MYSQL version 5.6.30 and allows for easy replacement of the bundled TLS/SSL library to a recent version of wolfSSL. Using the patch leverages the progressive, lightweight wolfSSL embedded SSL/TLS library when securing database connections. The patch, along with instructions on how to apply it, can be found on github at this repository https://github.com/wolfSSL/mysql-patch.

For more information contact wolfSSL at facts@wolfssl.com

Are you interested in seeding wolfSSL with quantum entropy?  wolfSSL has recently partnered with Whitewood Encryption Systems to bring support for the Whitewood netRandom client library to wolfSSL.

Whitewood netRandom is a client/server solution for delivery true random numbers.  The netRandom server includes the Whitewood Entropy Engine – a hardware-based high-performance, quantum random number generator.  A netRandom client securely connects to this server to retrieve quantum entropy.  This is beneficial in environments where it is tough or impossible to locally generate good random numbers.  Since the security of a cryptosystem is dependent on true random numbers, this is very important for users of wolfSSL and wolfCrypt.

When wolfSSL is compiled with support for the netRandom client library API, wolfSSL’s PRNG will be seeded with quantum random numbers from the netRandom server.  Users can compile wolfSSL with netRandom support by using the following ./configure option or by defining HAVE_WNR when compiling wolfSSL:

–with-wnr=PATH      Path to Whitewood netRandom install (default /usr/local)

netRandom support adds the following two functions to the wolfSSL API, through the header:

int wc_InitNetRandom(const char* configFile, wnr_hmac_key hmac_cb, int timeout);
int wc_FreeNetRandom(void);

An application should call wc_InitNetRandom() once during startup, passing it the netRandom configuration file, optional HMAC callback, and entropy timeout.  wc_FreeNetRandom() should be called upon application shutdown to free the netRandom context.

Usage examples can be found in the wolfSSL example applications, located in under the “./examples” directory of the wolfSSL download.  netRandom support is currently available in the development branch of wolfSSL and will be incorporated into the next stable release as well.

For more information about using the wolfSSL embedded SSL/TLS library with the Whitewood netRandom client library, contact us at facts@wolfssl.com.

References:
Whitewood Encryption Systems
Whitewood netRandom

OpenSSL released a security advisory on May 3rd 2016: https://www.openssl.org/news/secadv/20160503.txt. Some wolfSSL embedded TLS users are probably wondering if similar security fixes are needed in wolfSSL.  The answer to that is no.  Specifically, CVE-2016-2107 and CVE-2016-2108 are OpenSSL implementation bugs.  Since wolfSSL and CyaSSL embedded SSL libraries have a completely different code base from OpenSSL we do not share these defects.

Please contact wolfSSL by email at facts@wolfssl.com, or call us at 425 245 8247 if you have any security related questions.