Category: Uncategorized

We are at Black Hat 2013 this week and have seen some really cool hacks. Today, we saw “Honey, I`m Home!! Hacking Z-Wave Home Automation Systems” presented by Behrang Fouladi and Sahand Ghanoun. They demonstrated how easy it is to unlock someone`s house with a laptop and a sub-$75 radio card. While you can encrypt your data and add protections to prevent packet replay, if you assume the other end is always friendly you can have a problem.

The Z-Wave protocol uses a pre-shared key to encrypt a proper random number for use as the key for AES encryption of the connection. Teasing the pre-shared key out of the devices wasn`t interesting to the researchers. They found an easier method.

The demo involved forcing a controllable dead-bolt lock using the protocol stack to rekey with a new home-controller: a human sitting at a laptop with a cheap radio. Once the dead-bolt rekeyed, it accepted the human`s unlock command and opened the door.

Public-key cryptography can solve this problem. Providing a method for your home automation equipment to trust each other will give you the physical security you desire with your dead-bolt locks.

wolfSSL provides public-key authentication with industry standard bulk encryption in a small package. Please contact us today for more information.

Carmakers these days are clearly seduced by the power automotive electronics have to help sell their cars.  At wolfSSL, we`re seeing more and more connected auto devices getting designed (and secured by CyaSSL) in recent years.  All of the carmakers and their suppliers we deal with are quite cognizant of the security risks their connected devices pose, and the need for high quality small footprint SSL/TLS and encryption in their cars to battle man in the middle attacks.  That said, given the state of flux of the `connected car`, the inexperience of many automotive electronics engineers with security considerations, hacks will happen.  Today we note a great article on the topic.  

Charlie Miller and Chris Valasek will be presenting a fresh round of Automobile Hacks at Defcon next month, and a well written teaser article on their work is available here from Andy Greenberg of Forbes:  http://www.forbes.com/sites/andygreenberg/2013/07/24/hackers-reveal-nasty-new-car-attacks-with-me-behind-the-wheel-video/
(this article is no longer accessible on the forbes website as of Aug. 7, 2018)

If you`re at Black Hat or Defcon in the coming weeks, and want to discuss mitigating MITM automotive attacks with SSL, we`ll be available.  We`ve been helping automakers secure their electronics for 8 years now, and can share some of our experiences.  Just flag us down through facts@wolfssl.com.

Hi!  If you follow the networking market, you probably know that Software Defined Networks (SDN) represent a potential tectonic shift in how we think about and design network environments.  The concept has been around since 2005, but has gained significant momentum in the last couple of years, to the point where it is not just the talk of networking industry insiders, but has reached the mainstream financial press.  For a backgrounder on SDN, see http://en.wikipedia.org/wiki/Software-defined_networking.

Our interest in SDN at wolfSSL is specific to the security aspects, and even more specifically to the SSL/TLS.  From our vantage point, there are a lot of things to think about, including SDN languages like Frenetic, standards like OpenFlow and vendors like IpInfusion and their ZebOS.  

Currently, we believe that hardware cryptography is critical to the successful rollout of SDN, primarily for performance reasons.  As such, we are actively integrating performant support for a variety of hardware crypto solutions.  Recent examples include support for Cavium, AES-NI, STMicroelectronics, and Freescale.  

It is still the early days for SDN, so we recognize that there are additional considerations for us beyond just hardware crypto.  We`d like your feedback.  If you have commentary on CyaSSL for SDN, then let us know at facts@wolfssl.com.

Last month the NSA released a paper on Simon and Speck, which are lightweight block ciphers that appear to be applicable to a large part of our embedded user base.  The paper can be found here:  http://eprint.iacr.org/2013/404.pdf

Our users who have a keen interest in small size and low power consumption will find this paper particularly interesting.  

We are considering the possibility of implementing Simon and Speck in wolfSSL and WolfCrypt.  Does this sound interesting to you?  If your answer is yes, then let us know your thoughts at facts@wolfssl.com.

wolfSSL has made considerable progress in the first half of 2013, including a company name change to wolfSSL,  improvements to the CyaSSL lightweight SSL library, initiation of our FIPS 140-2 certification, and the introduction of our wolfCrypt cryptography library.  Being an open source company, we like to keep our users, customers, and followers up to date on our progress.  As such, we have compiled an overview of wolfSSL`s steady development in the first half of 2013.

Business and Company Progress

– Successfully participated in the following events: CES 2013, RSA USA 2013, DESIGN West 2013, and Interop 2013.  
– Name change that better reflects our company and culture.  To us the wolf represents us well as it is a creature that communicates effectively, works well in groups, and shares with the pack.
– Added more developers to the team
– Increased activity in onsite consulting to help customers design and validate their security architectures
– Dramatic increase in design wins for wolfCrypt
– Added many more high profile customers
– On track to double our business again this year
– We continue to actively support the open source community

CyaSSL Technical Progress

– Timely fix for Lucky13 attack
– BLAKE2 (SHA-3 candidate) hash function support
– Memory/stack tracking with examples
– IPv6 example support including link local addresses
– Alignment support at the SSL layer for hardware devices that require it
– New configure switches per algorithm
– Wildcard domain name match check including Subject altnames
– Ability to unload certs/keys for lower memory use
– SNI (Server Name Indication) support
– DTLS 1.2 support including AEAD ciphers
– DTLS reliability enhancements
– SHA-384 cipher suites
– AES-CCM-8 crypto and cipher suites
– Camellia crypto and cipher suites
– Updated API documentation
– Added LeanPSK build option able to get size down to 20k

CyaSSL Porting Progress

– Cavium NITROX support
– Updated ThreadX/NetX support
– KEIL MDK-ARM project files
– Updated Xcode project file
– HP/UX support
– Microchip PIC32 support
– Microchip MPLAB X project files for PIC32 Ethernet Starter Kit
– STM32F2 support including hardware crypto and RNG

Community

– Gearman now support CyaSSL

Team wolfSSL is looking forward to continued growth and development in the second half of 2013!  Stay tuned to our blog or social media streams to stay up-to-date on new developments.

The wolfSSL lightweight SSL library has supported ECC (Elliptic curve cryptography) since version 2.4.6 in December of 2012. Currently wolfSSL supports the most common ECC curve type at each bit strength defined by the standard, including the following.

SECP160R1
SECP192R1   (also called PRIME192V1)
SECP224R1
SECP256R1   (also called PRIME256V1)
SECP384R1
SECP521R1

wolfSSL defaults to SECP256R1, as is suggested, and as other SSL implementations do. We would like to get our users’ and readers’ feedback on these supported ECC curves. Are there additional curves you would like to see added to wolfSSL? If so, please let us know at facts@wolfssl.com.

We are often asked about how we test wolfSSL.  At this point, we believe we have testing that is quite robust, but we acknowledge that there is no such thing as perfect testing.  With that knowledge in mind, we have the goal of incrementally improving and automating our testing rigs over time.  Our overriding goal in testing is to have the most advanced and robust and ever improving testing that we can, subject to our resources.

We used to think of our testing plans in terms of a hierarchy, but we`ve improved on that thinking over time.  We currently represent our testing as a series of concentric universes, with each successively larger universe being vastly larger and more complex than the smaller one inside of it.  We`ll post some pictures in upcoming blog posts.  For now, here`s a rough representation of our testing universes in order of sequence:  

1.  Build options:  We have an extremely large number of build option combinations.  So our most basic test universe is to build successfully with every possible combination of options.

2.  API testing:  We test every available call in a particular build.

3.  Connection testing and data passing variables:  We start with simple connection tests with limited data transmitted and then gradually dial up complexity.

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

5.  We then connect to unknown servers in the real world.

6.  We then 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.  Finally, we engage in another ever expanding universe of benchmark testing, where we look at sizing, transmission rates, connection speeds, etc.  More to come on that topic, as it is quite popular!

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.

Many of our customers use the wolfSSL lightweight SSL/TLS package in M2M applications where usage is charged based on data transfer.  As such, it becomes important to minimize data transfer rates when running SSL.  Here are a few thoughts on how wolfSSL M2M users can minimize data packet overhead when implementing our embedded SSL:

1) Use a stream cipher like RC4, HC-128, or RABBIT.  Stream ciphers don`t require padding, this will save at least half the cipher`s block size per message.

2) Use session resumption as much as possible.  TLS session resumption uses less round trips and about 1/3 of the data compared to a full handshake, depending on certificate sizes and the certificate chain length mainly.  wolfSSL now has a built-in client session cache so using session resumption no longer places a burden on the application developer to map remote servers with session instances.

3) Only sending the peer certificate instead of certificate chains can greatly reduce the data usage of a full TLS handshake.  This will require the receiver to know about the root CAs and intermediate CAs ahead of time but it can often be worth it.

4) Use the shortest MAC you can, but still with good security.  This is probably SHA1 for now.  As more implementations begin to support truncated HMAC you could have the best of both.  SHA-384 for example, but truncated to 10 bytes.

5) Group output messages.  wolfSSL has the ability to send each TLS record individually or to send each group as flight.  This is a small savings, mainly in IP/TCP/TLS record headers but it adds up over time.

6) Use compression at the TLS level if you`re not doing it at the application level.  No sense in doing it twice though.

Did you like the addition of SNI in the last wolfSSL release? If so, you probably will like the Maximum Fragment Length extension as well!

TLS specifies a fixed maximum plaintext fragment length of 2^14 bytes. It may be desirable for constrained clients to negotiate a smaller maximum fragment length due to memory or bandwidth limitations. To enable the usage of Maximum Fragment Length at wolfSSL you can simply do:

./configure –enable-maxfragment

Using Maximum Fragment Length on the client side requires an additional function call, which should be one of the following functions:

wolfSSL_CTX_UseMaxFragment()
wolfSSL_UseMaxFragment()

wolfSSL_CTX_UseMaxFragment() is most recommended when the client would like to contact the same server multiple times with the same configuration. Setting the Maximum Fragment Length extension at context level will enable it in all SSL objects created from that same context from the moment of the call forward.

wolfSSL_UseMaxFragment() will enable it for one SSL object only, so it`s recommended to use this function when the maximum possible length between sessions changes.

On the server side no call is required. The server will automatically attend to the client`s request for Maximum Fragment Length. It is the client`s responsibility to choose the proper length.

Both SNI and Maximum Fragment Length extensions can be enabled with either:

./configure –enable-sni –enable-maxfragment

OR

./configure –enable-tlsx

If you have any questions about using Maximum Fragment Length with TLS please let us know at facts@wolfssl.com.

We would like to announce to our community that Gearman, a framework designed to distribute tasks to multiple machines or processes, now has SSL/TLS support using the wolfSSL lightweight SSL library.

From the Gearman site, Gearman “allows you to do work in parallel, to load balance processing, and to call functions between languages. It can be used in a variety of applications, from high-availability web sites to the transport of database replication events. In other words, it is the nervous system for how distributed processing communicates.”

If you are interested in using Gearman with wolfSSL, Brian Aker explains how to do so in this Google Groups post: https://groups.google.com/forum/?fromgroups#!topic/gearman/kHvarqZ6OYk.

Gearman: http://www.gearman.org/