Month: January 2011

Here’s a great article from EE Times on smart utility meter design. Two of the big challenges described in the article are ones that we’ve dealt with before with our current users in the utility space. Securing the meter, and getting updates to the device securely.

wolfSSL embedded SSL is a critical component for both design requirements. It’s not talked about in the article, but the yaSSL Embedded Web Server is also useful when the meter design calls for delivery of web pages from the meter for field service technicians. 

See the article here:  https://www.embedded.com/design/real-time-and-performance/4212469/Addressing-the-challenges-of-smart-utility-meter-design-.

Find it here:  https://sdtimes.com/back-issues/.  To quote the SD Times Editors:  “If your organization still maintains the view that open-source software is code written by amateurs, well, it’s time to move on.”  We think that sums it up nicely. 

We can sum up our thinking on open source with a simple statement:  Open source is a better way to develop, distribute, and support software. 

yaSSL.com is a growing company looking to add a top notch embedded systems software developer to our organization. We develop, market and sell the leading open source embedded SSL protocol implementation, wolfSSL. We are also the developers of the yaSSL Embedded Web Server. Our users are primarily building devices or applications that need security.

Operating environments of particular interest to us include Embedded Linux, VxWorks, QNX, ThreadX, micro-C, RL-ARM. Skill with the new mobile and embedded environments like Android and iOS is a plus.

Currently, we are seeking to add a master level C developer interested in a fun young company with tremendous upside.

Backgrounds that are useful to our team include networking, security, and hardware optimizations. Assembly experience is a plus. Experience with encryption software is a plus. RTOS experience is a plus.

To apply or discuss, please contact larry@yassl.com.

yaSSL will be attending ESC Silicon Valley 2011, the industry’s leading embedded systems event. ESC brings together the largest community of designers, technologists, business leaders, and suppliers all in one place.

ESC Silicon Valley will be held in the McEnery Convention Center in San Jose, CA on May 2-5, 2011. The yaSSL team will be talking about wolfSSL and the yaSSL Embedded Web Server, and will look forward to visiting with members of the embedded community!

If you are planning on attending ESC Silicon Valley this year and would like to visit, please let us know! You can email any comments or questions to info@yassl.com.

ESC Silicon Valley: http://esc-sv09.techinsightsevents.com/

We believe that in today’s world of connected devices and heightened security concerns, digitally signing the firmware that is loaded onto your embedded or mobile device has become a top priority. One of the reasons that embedded RTOS environments do not include digital signature functionality is because it has historically not been a requirement for most embedded applications. This is no longer true today – without secure firmware updates, even if a system has been secured, a malicious firmware update can undermine much of the work which was put into securing the device.

wolfSSL is a popular tool for digitally signing applications, libraries or files prior to loading them on embedded devices and as such, it is ideal for signing firmware updates. Because wolfSSL supports the key embedded and real time operating systems, encryption standards, and authentication functionality, it is a natural choice for embedded systems developers to use when signing firmware updates.
 
Generally, the process for setting up code and file signing on an embedded device are as follows:
 
1. The embedded systems developer will generate an RSA key pair.
2. A server side script based tool is developed
a. The server side tool will create a hash of the code to be loaded on the device with SHA-256 for example.
b. The hash is then digitally signed, also called a RSA private encrypt.
c. A package is created that contains the code along with the digital signature.
1. The package is loaded on the device along with a way to get the RSA public key.  The hash is re-created on the device and then digitally verified (also called RSA public decrypt) against the existing digital signature.
 
Digitally securing your firmware updates can:

1. Protect against updates from unauthorized parties
2. Enable a secure method for allowing third parties to load files to your device
3. Ensure against malicious files finding their way onto your device
 
Do you need help setting up code signing for your firmware updates?  Let us know as we can help in setting up server-side scripts as well as device-side requirements.  Contact us at info@yassl.com.

More background on code signing:
 
A great article on the topic at embedded.com:  http://embedded.com/design/216500493?printable=true
General information on code signing:   http://en.wikipedia.org/wiki/Code_signing

With the release of CyaSSL 1.8.0, users are now able to create CA signed x509 v3 certificates. Certificate generation is turned off by default, but may be turned on during the ./configure process with the following option or by defining CYASSL_CERT_GEN in Windows or non-standard environments:

–enable-certgen

Currently CyaSSL only supports the MD5_WITH_RSA signature algorithm type (which is by far the most common) and the creation of self signed certificates. The next release will allow other signers and other signature types. To create a self-signed certificate the general steps taken by the user include:

1. Create the Cert structure

2. Initialize the Cert structure

3. Complete the information in the CertName structure

4. Generate the self-signed certificate using any valid RsaKey and RNG.

The result of the above steps will be a DER formatted certificate which may also be converted into a PEM formatted certificate if desired. For more information on how CyaSSL generates RSA keys, please see the CyaSSL Extensions Reference, Section X. For complete details of the above steps to create a self-signed certificate and how you can create a CA signed certificate, see the CyaSSL Extensions Reference, Section XI.

For more information about CyaSSL, please contact info@yassl.com.

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!