RECENT BLOG NEWS

Here at wolfSSL, we’re always excited to see fan art! Today we’d like to thank Steve Barker (https://plus.google.com/103515628980768116177/posts) for the rendition of our logo and tagline!

One of the consistent themes at Black Hat is attacks on industrial control systems; which includes water plants, power plants, and oil refineries.  One of the presentations was centered around using honeypots to determine the level of attack activity.  An excellent article on the presentation and related material can be found here:  http://gcn.com/Articles/2013/08/07/ics-honeypots.aspx?s=security_080813&admgarea=TC_SecCybersSec&Page=1

Some of the attacks can be mitigated with wolfSSL, by using our embedded SSL to secure firmware updates and eliminate MITM attacks.  We`ve seen a number of progressive companies adopt our products to do exactly that.  

Qualys put out an excellent SSL deployment best practices paper a few months ago.  If you have not seen it, then check it out here:  https://www.ssllabs.com/projects/best-practices/

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.