RECENT BLOG NEWS

If you’ve been following our blog, you know we are planning on answering some common questions that we were asked during the 2011 RSA Conference.  Today is the first post in this series.  The first questions we will be looking at are:

Does wolfSSL have sniffer, also known as SSL Inspection functionality?
What about resiliency in the TCP reassembly library?

Q:  Does wolfSSL have sniffer, also  know as SSL Inspection functionality?

Yes, wolfSSL has had SSL Inspection (sniffer) functionality since version 1.5.0.  We have provided a build option allowing the wolfSSL library to be built with this functionality.  This means you are able to collect SSL traffic packets and with the correct key file, are able to decrypt them as well.  This is useful for many reasons, some of which include:

– Analyzing Network Problems
– Detecting network misuse by internal and external users
– Monitoring network usage and data in motion
– Debugging client/server communications

To enable SSL Inspection (sniffer) support, build wolfSSL with the “–enable-sniffer” option on *nix or use the vcproj files on Windows. You will need to have pcap installed on *nix or WinPcap on Windows.  To learn more about functions provided and more detailed usage, please see either the wolfSSL Manual, or the “wolfSSL Additional Features” document.

Q:  What about resiliency in the TCP re-assembly library?

The wolfSSL TCP re-assembly library is currently functional, but not resilient.  This is something that several people have asked about, and something we are looking into.  If you have a need for a resilient TCP re-assembly library, or think this would be beneficial to your project, please let us know at info@yassl.com.

While at FOSDEM 2011, we had the opportunity to listen to Arnout Vandecappelle’s presentation titled “Creating secure web based user interfaces for Embedded Devices.” We really enjoyed it, and wanted to share it with our readers. You can read the abstract, taken from mind.be, below:

Abstract:

A web interface is the easiest way to add something GUI-ish to an embedded system. However, setting up an Apache and writing CGI scripts requires too much work and overburdens resource constrained systems.. This presentation shows you the best tools to simplify your life for adding an interface to your embedded system. The first step is the Mongoose Embedded Web Server. It is a tiny (40K) yet fully-featured web server that can be embedded directly in your application. Combining it with the efficient wolfSSL library gives you a secure environment. For a more advanced GUI, there is Wt, which completely removes the burden of web programming from you – you`ll hardly even notice there`s a web server in your application!

You can download Arnout’s presentation in both PDF and ODP formats from the mind.be publication page. We’ll also be linking to Arnout’s slides on our media page as well.

Link to mind.be publication page: http://mind.be/?page=publications
Direct link to PDF slides: http://mind.be/content/110206_Web-ui.pdf

wolfSSL+ (pronounced plus) is now available. wolfSSL+ includes NTRU public key encryption. NTRU works well in mobile environments because of the reduced bit size needed to provide the same security as other public key systems. NTRU also isn’t vulnerable to quantum attacks. Several new cipher suites utilizing NTRU are available including AES-256, RC4, and HC-128. Please contact us if you have any questions.

For everyone out there prototyping on the cool mbed board (http://mbed.org/), we`ve recently published our wolfSSL TLS/SSL embedded library to their cloud compiler so that developers can easily add it to their project.  It`s available at http://mbed.org/users/toddouska/libraries/wolfSSL/lm43pv .  We also have an example client you can try out at http://mbed.org/users/toddouska/programs/cyassl-client/lm394s .  Now securing connections, even during a prototype, is easily and rapidly attainable.  Please send us any comments or questions.

For those developers that prefer git, using GitHub, or just have to have the latest CyaSSL source code it’s now available on GitHub.  You can grab the latest sources from https://github.com/wolfSSL/wolfssl.git .  We’ve got all the source now there but we’re gradually moving away from sourceforge.  So we’re still in transition.  Please let us know if you have any questions or comments.

The second release of the yaSSL Embedded Web Server is now available for download!  New features with this version include a source release, better documentation, examples, and new run-time options.  

Our Web Server is focused on being small, fast, and embeddable.  Features include CGI, SSI, IP restrictions, access and error log support, and SSL among others. The wolfSSL embedded SSL library can be used to secure ports with SSL, giving you a secure connection while maintaining small size and fast speed.  

On an embedded system you can expect to see the yaSSL Embedded Web Server with wolfSSL enabled to come in around 100kB total.  We offer commercial support, consulting, and licenses for use in a wide variety of projects.

If you have any questions, or would like to learn more about the yaSSL Embedded Web Server and how it can help your project, please contact info@yassl.com.

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. 

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.