RECENT BLOG NEWS

One of the improvements made in wolfSSL 1.8.0 is lower overall memory use through the use of configurable input / output buffer sizes and less dynamic memory use.

wolfSSL 1.8.0 uses small static buffers for input and output. They default to 128 bytes and are controlled by the RECORD_SIZE define in cyassl_int.h. If an input record is received that is greater in size than the static buffer, then a dynamic buffer is temporarily used to handle the request and then freed. You can set the static buffer size up to the MAX_RECORD_SIZE which is 2^16 or 16,384. For more information about wolfSSL`s input and output buffer`s, see the wolfSSL Extensions Reference, Section XIII.

In addition to the input and output buffers, If the fast-math library is used when building wolfSSL, all dynamic memory use for public key cryptography may be reduced. The normal math library uses dynamic memory for big integers, but fastmath uses fixed-size buffers that hold 4096 bit integers by default (allowing for 2048 bit by 2048 bit multiplications). You can learn more about fastmath and how to enable it in the wolfSSL 1.8.0 Manual.

If you would like more information on wolfSSL or are interested in using it in your product, please contact info@yassl.com.

With the release of wolfSSL 1.8.0 we have made wolfSSL even more portable with the addition of a C Standard Library Abstraction Layer.  This means that wolfSSL may now be built without parts of the C Standard Library and user-defined functions may be used instead.

The C Standard Library consists of a set of sections of the ISO C standard which describe a collection of headers and library routines used to implement common operations such as I/O, math operations, string handling, and much more.  wolfSSL allows you to override functions in the following areas:

A. Memory Use

Most C programs use malloc() and free() for dynamic memory allocation. wolfSSL uses XMALLOC() and XFREE() instead. By default, these point to the C runtime versions. By defining XMALLOC_USER, the user can provide their own hooks. Each memory function takes two additional arguments over the standard ones, a heap hint, and an allocation type. The user is free to ignore these or use them in any way they like.  You can find the wolfSSL memory functions in types.h.

B. string.h

wolfSSL uses several functions that behave like string.h’s memcpy(), memset(), and memcmp() amongst others. They are abstracted to XMEMCPY(), XMEMSET(), and XMEMCMP() respectively.  And by default, they point to the C standard library versions. Defining XSTRING_USER allows the user to provide their own hooks in types.h. For an example of this, please see the wolfSSL document wolfSSL Extensions Reference, Section XII or download the wolfSSL Manual.

C. math.h

wolfSSL uses two functions that behave like math.h’s pow() and log(). They are only required by Diffie-Hellman, so if you exclude DH from the build, then you don’t have to provide your own. They are abstracted to XPOW() and XLOG() and found in dh.c.

D. File System Use

By default, wolfSSL uses the system’s file system for the purpose of loading keys and certificates. This can be turned off by defining NO_FILESYSTEM (see the wolfSSL Extensions Reference, Section V). If instead, you’d like to use a file system but not the system one, you can use the XFILE() layer in ssl.c to point the file system calls to the ones you’d like to use.  See the example provided by the MICRIUM define.

For more information regarding the wolfSSL C Standard Library Abstraction Layer or if you have any questions or comments, please contact info@yassl.com.

One of the community projects which uses wolfSSL is the Gargoyle Router. If you haven`t heard about the Gargoyle Router, it is an interface for small, widely available routers such as the Linksys WRT54G series or the Fonera. Adding additional functionality to the normal router firmware, it is based on the kamikaze release of the OpenWrt firmware. Some of the added features include dynamic DNS, quality of service, access restrictions, and bandwidth monitoring tools. It is open source and freely available under the GPLv2.

If you would like to learn more about the Gargoyle Router, consider visiting any of the following links:

Gargoyle Router: http://www.gargoyle-router.com
Wikipedia Entry: http://en.wikipedia.org/wiki/Gargoyle_Router_Firmware

We’re a fan of Ivan Ristic, and suggest you follow his blog at http://blog.ivanristic.com/.  We enjoy his work and appreciate his occasional constructive criticism of our work.  One of his recent presentations caught our eye.  It’s motivating and packed with ideas regarding SSL.  Check it out here:  http://blog.ivanristic.com/2010/11/stop-complaining-and-solve-a-security-problem-instead.html.
 
We like the title:  Stop Complaining and Solve a Security Problem Instead!

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.