Category: Uncategorized

Open Source plays an important role in securing the Internet of Things. As more embedded products become available and security updates are required, devices will reach end-of-life, no longer supported by their creators, but will still remain in use. In the case of an open source project, developers within the open source community can contribute to updating the device as it continues to be used. This open source community can become an insurance blanket over a product, allowing the public to continue using a product that may no longer be supported by its initial developers, but still has active contributors.

In Beth Flanagan’s recent keynote talk at OSCON 2014, she discusses the importance of security and Open Source within the Internet of Things. Her speech, “Yes, Your Refrigerator is Trying to Kill You,” covers the consequences of insufficient security in embedded devices. The title example is the idea of someone hacking into your refrigerator and turning it off every night and back on every morning, slowly spoiling your food and ultimately leading to your death. While this control over your refrigerator could very easily occur and devices belonging to the connected home should still be considered highly important on a security level, these types of devices are not her main concern, but rather implantable devices, such as pacemakers, that contribute to keeping a person alive. If a pacemaker or insulin pump has wireless capabilities, a user’s health could be dictated by someone hacking into the device, which demonstrates the immediate need for a secure system.

wolfSSL developed CyaSSL with this need for security and open source development in mind. With a GPL v2.0 license as an option for building with the CyaSSL lightweight, embedded SSL library, content is available to open source projects, further enhancing the security features. Since CyaSSL was designed for embedded devices, developers have the option to seamlessly secure any of their products.

If you are a developer with questions regarding CyaSSL, open source, or securing an embedded device, please contact us at support@wolfssl.com or go to our website at www.wolfssl.com.

Recently at the CRYPTO 2014 conference rump sessions several interesting papers were presented. Ron Rivest presented a paper he and Jacob C. N. Schuldt wrote on finding an improved replacement for the RC4 stream cipher they named Spritz. Their goal was to find a drop in replacement for RC4 that wasn’t susceptible to the known attacks. They used a statistical process to generate and analyze several thousand candidate ciphers.

If anyone is interested in seeing an implementation of Spritz, send us a message at facts@wolfssl.com. We’d love to hear from you.

wolfSSL has released a case study highlighting how Sensity Systems is using the CyaSSL lightweight SSL/TLS library to secure Light Sensory Networks (LSNs).  This case study highlights the key requirements Sensity had for securing their devices, how CyaSSL was used as a solution, and summarizes Sensity’s thoughts on the project.

As stated on the Sensity Systems website, a Light Sensory Network, or LSN, is “a new class of digital sensor network that takes advantage of LED lighting conversions to help light owners enhance energy efficiency while transforming their luminaires into strategic assets.” To learn more about LSNs, we encourage our users to visit the Sensity Systems’ website, listed below.

You can download the case study directly from the wolfSSL website at the following location.  If you have any questions about using CyaSSL to secure embedded or IoT devices, please contact us at facts@wolfssl.com.

wolfSSL / Sensity Systems (LSN) Case Study: wolfSSL Case Studies
Sensity Systems: http://www.sensity.com/

CyaSSL now has example projects that can be compiled in Code Composer Studio (CCS) and debugged on the Tiva™ C Series TM4C1294NCPDT (1294XL) Connected Launchpad. Please see the README under wolfSSL / wolfssl-examples / tirtos_ccs_examples on www.github.com for instructions on building CyaSSL with Texas Instruments-Real Time Operating System (TI-RTOS). Please visit http://www.ti.com/tool/sw-tm4c for all other things Tiva C.

For questions or comments, please email us at facts@wolfssl.com.

IBM`s operating system, AIX (Advanced Interactive eXecutive), is the standard operating system for the RS/6000 series. The RS/6000 series being UNIX servers, workstations, and supercomputers made by IBM. AIX is also currently supported in IBM`s Power Systems. One of the notable features in their 2010 release is that it could support 256 cores /1024 threads in a single virtual machine.

wolfSSL has not been ported to or tested on the operating system and we would like to see if that is something the community is interested in seeing happen. Let us know if you would like to see wolfSSL SSL/TLS and/or wolfCrypt support for AIX operating systems.

For a fun read on hacking the connected home, see Dark Reading at:  How I hacked my home.

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.