RECENT BLOG NEWS

Earlier this month, Google announced that a security compromise had been found which affects applications that improperly initialize, or fail to initialize completely, the PRNG (pseudorandom number generator) before using it for key generation, signing, or random number generation.

On the Android Developers Blog, Alex Klyubin, Android Security Engineer, stated that “We have now determined that applications which use the Java Cryptography Architecture (JCA) for key generation, signing, or random number generation may not receive cryptographically strong values on Android devices due to improper initialization of the underlying PRNG. Applications that directly invoke the system-provided OpenSSL PRNG without explicit initialization on Android are also affected”, but also noted that “Applications that establish TLS/SSL connections using the HttpClient and java.net classes are not affected as those classes do seed the OpenSSL PRNG with values from /dev/urandom.”

The Android Developers Blog link provides Android developers with a workaround, suggesting that the PRNG be initialized with entropy from /dev/urandom or /dev/random.

For our wolfSSL and wolfCrypt users on Android, applications should not be affected as wolfSSL and wolfCrypt seed their PRNG from /dev/urandom or /dev/random by default. When using crypto directly through wolfCrypt, this happens when the application calls InitRng(). When using SSL/TLS through wolfSSL, the PRNG is automatically seeded.

For users who want to write their own seed generation code, wolfSSL and wolfCrypt allow programmers to define NO_DEV_RANDOM and write their own GenerateSeed() function in /ctaocrypt/src/random.c. For more information about doing so, or questions, please contact us at facts@wolfssl.com.

“Some SecureRandom Thoughts”, Android Developers Blog: http://android-developers.blogspot.com/2013/08/some-securerandom-thoughts.html

Hi!  If you are interested in IoT and specifically security of IoT, then you’ll probably like this article on SEP 2.0.  SEP stands for Smart Energy Profile.  This note is just to let our users know that we’re following the evolution of the standard as it relates to SSL/TLS, and have provided our CyaSSL embedded TLS solution to a number of progressive companies that are building out the smart grid.  If you have questions about how CyaSSL fits into the smart grid and SEP 2.0, then contact us at facts@wolfssl.com.

If you need background information, there is an excellent article at EE Times that you can review here:  https://www.eetimes.com/document.asp?doc_id=1280846

CyaSSL now supports the Cavium NITROX processors, thus enabling CyaSSL users to take advantage of the incredible performance boosts provided by the NITROX family.  Cavium’s NITROX processors combine cryptographic acceleration with the latest security algorithms.

The NITROX PX family can deliver performance ranging from 500 Mbps to 2.5 Gbps for full SSL protocol offload, and anywhere from 4K to 17K RSA operations per second using 1024bit exponent RSA.  The NITROX III family can additionally boost SSL offload performance to anywhere from 5 Gbps to 40 Gbps, and can provide 35K to 200K RSA operations per second using 1024bit exponent RSA.

Are you interested in using CyaSSL with a Cavium NITROX processor?  If so, let us know at facts@wolfssl.com.

NITROX Security Processors:  https://www.cavium.com/processor_security.html

Hi!  wolfSSL`s Secure Embedded Web Server is now available for FreeRTOS.  Let us know if you`re interested at facts@wolfssl.com.

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.