RECENT BLOG NEWS

See their picks here:  https://www.eetimes.com/document.asp?doc_id=1258133.  We’re keenly interested in Augmented Reality and Automotive Radar for personal reasons.  It’s just good and useful stuff that will make our lives better. 
 
For business reasons, we’re closely following Personal Power Management, which allows you to see your power consumption in timely (not real timely), but actionable increments.  For those who’ve grappled with Thermodynamics and Heat and Mass Transfer at their University and want to apply some of that hard earned learning in their personal home energy management, there’s technology on the way to help!  See:  https://www.eetimes.com/document.asp?doc_id=1258133&page_number=6.  wolfSSL has been the embedded SSL implementation chosen to secure home energy usage information in some existing projects, and we expect it to be a budding market for us going forward. 

See here http://www.embeddedinternetdesign.com/showArticle.jhtml?articleID=228800856 (as of 26 March 2018 at 9:24am MDT, this link no longer works and has no alternative)  for the latest research on the growth and adoption of smart appliances from IMS research.

2011 looks to be another interesting year in the embedded systems marketplace according to VDC’s predictions outlined here:  https://www.eetimes.com/author.asp?section_id=36&doc_id=1265937.

If you’ve been reading our commentary, then you know that we think they’re right on with item 5:  OEMs to increase use of web security test tools.  This just makes a world of sense given the high profile attacks where embedded systems have been used as the key attack vector. However, test tools is just a single piece of the security puzzle. Secure connectivity will be just as important as the market progresses.

So what made it into the wolfSSL Holiday Release?  We think a few items that users will appreciate.  Some concern increased portability through the os_settings.h file and the new C Standard Library Abstraction layer.  Others lower memory use through configurable input/output buffer sizes and less dynamic memory use.  For the readers out there we now have a complete manual available on the website as well as in the release.  wolfSSL can now create CA signed x509v3 certificates too.  There`s also the ability to use new cipher suites in conjunction with a library we`ll be talking about soon.  Happy Holidays from the yaSSL team!

You may have recently read our blog post regarding Exposed Private Keys and how you may create secure private keys for SSL-enabled devices using wolfSSL. If your application or framework needs to be secured with SSL/TLS but you are uncertain about how the optimal design of a secured system would be structured, we can help!

We offer design consulting for building SSL/TLS security into devices using wolfSSL. Our consultants can provide you with the following services:

1. Assessment:  An evaluation of your current SSL/TLS implementation. We can give you advice on your current setup and how we think you could improve upon this by using wolfSSL.

2. Design:  Looking at your system requirements and parameters we`ll work closely with you to make recommendations on how to implement wolfSSL into your application such that it provides you with optimal security.

If you would like to learn more about design consulting for building SSL into your application or device, please contact info@yassl.com for more information.

A recent blog about “Breaking SSL on Embedded Devices” has been making the rounds recently.  It`s not an attack on SSL, it`s an attack on weak private key security. Specifically, embedding a private key into firmware allows anyone to extract the key and turns an otherwise secure connection into something nothing more secure than TCP.

We have a few ideas about creating private keys for SSL enabled devices.

1. Each device acting as a server should have a unique private key, just like in the non-embedded world.

2. If the key can`t be placed onto the device before delivery, have it generated during setup.

3. If the device lacks the power to generate it`s own key during setup have the client setting up the device generate the key and send it to the device.

4. If the client lacks the ability to generate a private key have the client retrieve a unique private key over an SSL connection from the devices known website for example.

wolfSSL can be used in all of these steps to help ensure an embedded device has a secure unique private key.  That will go a long ways towards securing the SSL connection itself.

We saw a post on a mailing list recently that questioned the maturity of wolfSSL.  The post came as a surprise.  We think wolfSSL is pretty mature by most standards!  Here’s our key points on wolfSSL’s maturity:
 
1. It is on its 29th release.
2. It has been vetted out in the open source community for 6 years. (View our community page)
3. It is distributed in over 20 million devices, based on our estimates.  That includes commercial distributions such as printers, home monitoring, VoIP phones, hubs, routers, sensors, telecom infrastructure, as well as open source projects.
 
Let us know what you think!  If you think wolfSSL is mature/not mature, email us at info@yassl.com, or post to our forums.

Will it be a new release with awesome new embedded ssl features?  What could those features possibly be?  Will it be even faster and smaller?  More portable?  New ciphers?  Do you think you know what the yaSSL community is getting for Christmas this year?  Send us your guess to info@yassl.com!

Here’s a nice article on Android’s security flaws and latent bugs from the CTO of Green Hills Software, Dave Kleidermacher :  https://www.embedded.com/electronics-blogs/davek-security-blog/4211444/Angry-Bird-droppings.
 
Looks like there is some work to be done to help properly secure Android!

wolfSSL is modular. We’ve got two key modules: wolfSSL handles all SSL needs while CTaoCrypt handles all cryptographic needs including block ciphers, stream ciphers, message digests, hashing, public key cryptography, certificates, and various helper utilities.  Our topic for this post is our crypto module CTaoCrypt. 
 
CTaoCrypt is our implementation of cryptography components including various block and stream ciphers that can be used underneath the SSL protocol. A complete description of our ciphers is available here:

https://www.wolfssl.com/docs/wolfssl-manual/ch10/. 

Not all ciphers are created equally. Some are better than others, depending on the task at hand. CTaoCrypt includes the traditional and most popular block ciphers, which are DES, 3DES, and AES, and the popular stream cipher ARC4. In recent years, the European Union funded the eStream project to identify next generation stream ciphers. The project concluded in 2008. A description of the eStream project is found here:  http://en.wikipedia.org/wiki/ESTREAM. The eStream project was looking to identify ciphers that could handle high throughput requirements and/or operate well in resource constrained environments. 
 
High throughput and resource constrained environments (like VoIP on devices) is where wolfSSL maintains a technology lead over the pack of SSL libraries, so it was natural for us to maintain a keen interest in the results from eStream. The net result is our implementation of the HC-128 and RABBIT ciphers in wolfSSL. If you’d like to see a comparison of cipher performance, see slide 16 of our OSCON presentation http://www.yassl.com/files/ToddOuska_SecuringMemcache.pdf, showing relative performance of the cipher suites in specific implementation of Secure Memcache. 
 
Other ciphers can be added to CTaoCrypt for additional purposes, and we’re happy to do it if we see a need from our customers. Watch this space for further announcements!