RECENT BLOG NEWS

Here at wolfSSL we recently added fuzz testing to our testing processes. Security of CyaSSL software is always on our mind. As the software is used to secure connections and provide software security, the testing of how robust and secure CyaSSL is holds high importance.

As with the halting problem we know it is impossible to test every single possible path through the software but we practice an approach that is focused on lowering risk of failure. In addition to extensive automated tests we also make sure that we specifically test well known use cases. This post outlines some of our testing processes.

1.  Build options:  The first approach we use is by testing combinations of build options. Although there are too many potential combinations to test them all, this approach tests for potential issues with build option compatibility and also allows us to place a confidence value on build option combinations not yet used. We commonly use valgrind and scan-build when testing individual build options.

2.  API testing: In each particular build, we test every available call to cover API uses.

3.  Connection testing and data passing variables: To test this we start with simple connections and data, then as the test progresses we gradually increase the complexity of connection details.

4.  Interop: We test for interoperability with the other open source TLS implementations, including OpenSSL and GnuTLS.

5.  We then test interoperability outside of a closed environment and connect to unknown servers in the real world.

6.  We build with a series of `real` applications, like cURL, wget, pppd, etc.  For some of our customers with top level support, we build the new release with their application.

7. We test using a fuzzing software technique. This bombards the program with invalid, unexpected, and random data that then allows for observing if there is potential memory leaks or logic errors.

8. We engage in another ever expanding universe of benchmark testing, where we look at sizing, transmission rates, connection speeds, etc.

Much of our effort is automated by Jenkins (hat tip to that project!).  Thanks for listening.  If you have specific questions about how we test, please contact us at facts@wolfssl.com.

wolfSSL is in the process of adding curve25519 to the CyaSSL lightweight SSL/TLS library. You may ask, why add another ECC curve when CyaSSL already has quite a few ECC options? Curve25519 was chosen because of its record-setting speed while maintaining reliable security. In fact compared with some of the previous ECC curves, Curve25519 actually cuts the time taken to perform in half.

A paper by Daniel Bernstein for farther reading can be found at http://cr.yp.to/ecdh/curve25519-20060209.pdf.  If you want more details on our roadmap for Curve25519, contact us at facts@wolfssl.com.

The wolfSSL Tuning Guide is a reference that allows developers to optimize the performance and memory of the wolfSSL embedded SSL library within their products. The tuning guide includes three recipes for adjusting your wolfSSL implementation to build with minimum footprint, maximum speed, or maximum security. Choosing the correct recipe for building wolfSSL depends on a number of design goals such as the desired security level or memory footprint. These design goals are covered more thoroughly in the tuning guide.

To view these recipes and optimization options for wolfSSL, please view the wolfSSL Tuning Guide on our website. For questions or comments, please email us at facts@wolfssl.com.

We are excited to share our latest enhancement to wolfSSL, which is the addition of ChaCha20 and Poly1305 AEAD cipher suites. Currently they are compatible with the Google server and have the added bonus of also being able to use the more recent ChaCha20 – Poly1305 AEAD constructions.

All that we have left to do with the suites is to be put them through our extensive genetic testing system If you are interested in getting a copy early and beta testing the cipher suites please let us know at facts@wolfssl.com, or call us at +1 425 245 8247.

You may be familiar in general with the role of Web APIs in IoT scenarios. This demo shows how CyaSSL can easily secure the communications between IoT devices and cloud services.

Twilio is a cloud-based Voice and SMS service that allows a client PC or smart phone to be used in building intelligent communications. With the compact security protocol for embedded systems like CyaSSL, the service can immediately be extended to smart “things” in the network.

This simple demo program runs on any network-connected mbed with a CyaSSL+HTTPS based web API. It triggers Twilio phone call and text speech through the web API.

To take a look at the project, please visit our mbed site and import the demo.

http://mbed.org/users/wolfSSL/
http://mbed.org/users/wolfSSL/code/CyaSSL-Twilio/
http://mbed.org/users/wolfSSL/code/CyaSSL-Twilio-Dropbox/

For more information:
Twilio: http://twilio.com
mbed: http://mbed.org

mbed HTTPClient class:
http://mbed.org/users/donatien/code/HTTPClient/
http://mbed.org/handbook/TCP-IP-protocols-and-APIs

wolfSSL has been tested with and works on SmartOS! SmartOS is an operating system used specifically for databases and in conjuncture with cloud operations. It inherited features from the well known Solaris and has been extended by Joyent to make it great for cloud operators.

One of the big things added was disk I/O throttling – see the following YouTube link on why that is good to have. (http://www.youtube.com/watch?v=a6AJxAYmP-M) . The OS does provide some measure of security in their file operations but wolfSSL could be used alongside the operating system to allow more options for encrypting stagnant files that are being stored and passed between the OS and the cloud. Another feature that wolfSSL could provide for it, along with continuous updates that are focused on security, is that we would be able to provide support for upcoming suites such as recent ones using AEAD.

Contact us here at wolfSSL if this is something you would like to see happen with your cloud and database operations.

For some time now wolfSSL has been compatible with and will continue to support IPv6. While according to Google`s IPv6 adoption statistics only 4% of the Internet has adopted IPv6, that number is more than doubling every year. At the beginning of 2013 the percentage of IPv6 adoption was only 1.06%, and at the end of 2013 it was sitting at 2.84%. And now only halfway through 2014, it has risen to 4.06%.

With IPv6 on the rise, the need for an SSL library that supports it is also on the rise. By using the wolfSSL embedded library you are future proofing yourself against the rise of IPv6 with an embedded library built by individuals that have had years of experience securing both IPv4 and IPv6 connections. By design wolfSSL supports both IPv4 and IPv6 and is considered IP neutral, meaning it should work out of the box on either protocol without any additional configurations.

For more information on IPv6, you can refer to it’s wiki page: http://en.wikipedia.org/wiki/IPv6

Google`s IPv6 Statistics: https://www.google.com/intl/en/ipv6/statistics.html

openPicus provides hardware for use with IoT, M2M, and the cloud. These hardware modules connect using Wifi and Ethernet connections, and as such, these connections need to be secured when communicating. wolfSSL is curious about the current need of our customer and user base for having secure connections on this hardware.

Do you want to use CyaSSL with openPicus modules? Contact us if SSL/TLS or cryptography support for OpenPicus is something that you would like to see added to CyaSSL and/or wolfCrypt.

CyaSSL 3.1.0 has been released and is now available for download from the wolfSSL website. This release includes bug fixes and new features including:

– Fix for older versions of icc without 128-bit type
– Intel ASM syntax for AES-NI
– Updated NTRU support, keygen benchmark
– FIPS check for minimum required HMAC key length
– Small stack (–enable-smallstack) improvements for PKCS#7, ASN
– TLS extension support for DTLS
– Default I/O callbacks external to user
– Updated example client with bad clock test
– Ability to set optional ECC context info
– Ability to enable/disable DH separate from opensslextra using –enable-dh and –disable-dh
– Additional test key/cert buffers for CA and server, located in certs_test.h
– Updated example certificates

Please see the README and our on-line documentation for more information or feel free to contact us.

We have been working within OpenEmbedded and the Yocto Project to develop an Open Source SSL/TLS layer designed for incorporating CyaSSL into custom Linux builds for embedded systems. meta-wolfssl contains three completed recipes including the CyaSSL library as well as the CTaoCrypt (wolfCrypt) test and benchmark executables. You can now test and send information quickly and securely through your embedded device using our portable and lightweight SSL/TLS library.

These recipes can be easily incorporated into any bitbake build, specifically through the use of the OpenEmbedded and Yocto Project utilities. For our original construction, we ran a custom version of core-image-sato (a mobile image platform) on the Minnowboard.

The meta-wolfssl github page includes detailed instructions for installing any of these recipes in your build image. Check back for future updates regarding meta-wolfssl and OpenEmbedded/Yocto. If you have any questions regarding adding wolfSSL to your OpenEmbedded/Yocto projects, feel free to contact us at support@wolfssl.com.