RECENT BLOG NEWS

wolfSSL embedded ssl has been available for QNX since the first source release of the product.  We have compared wolfSSL’s current build size on QNX against OpenSSL and the results surprised us.  A standard wolfSSL build for QNX is 80k.  This compares to a standard OpenSSL build size of 2M.  The wolfSSL embedded implementation is more than 25 times smaller than OpenSSL on QNX! 

You can find more information about QNX from their website: http://www.qnx.com/

If you have any questions or want more information, please contact info@yassl.com.

wolfSSL is a popular tool for digitally signing applications, libraries or files prior to loading them on embedded devices. As such, it is ideal for signing firmware updates. The reason that embedded RTOS environments do not include digital signature functionality is because it has historically not been a requirement for most embedded applications.  However, 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. 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.

The yaSSL team will be in Boston at the Embedded Systems Computing show next week as well. If you are attending and have questions, inquiries, or just want to visit, stop by our booth to say Hi! We look forward to seeing you there!
 
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

Hi!  Most of our readers will already know that AES is a key encryption standard used by governments worldwide, and that wolfSSL has always supported AES. 
 
Intel has released a new set of instructions that is a faster way to implement AES, and wolfSSL is currently the first ssl library to fully support the new instruction set for production environments. 
 
Essentially, Intel has added AES instructions at the chip level that perform the compute intensive parts of the AES algorithm, boosting performance. 
 
What we’ve done is add the functionality to wolfSSL to allow it to call  the instructions directly from the chip, instead of running the algorithm in software.  This means that when you’re running wolfSSL on a chipset that supports AES-NI, you can run your AES crypto 5-10 times faster! 
 
If you’re doing some benchmarking for your environment, let us know at info@yassl.com we’ll be happy to support you with the effort.  Our current benchmarks are in the lab, and we’d like to work with users that can help us further define real world expectations for speed improvements from AES-NI.
 
References and further reading, ordered from general to specific: 
 
Wikipedia entry on AES:  http://en.wikipedia.org/wiki/Advanced_Encryption_Standard
Wikipedia entry on AES-NI:  http://en.wikipedia.org/wiki/AES_instruction_set
Intel Software Network page on AES-NI:   http://software.intel.com/en-us/articles/intel-advanced-encryption-standard-instructions-aes-ni/
 
See the README of wolfSSL 1.6.5 for instructions on building with AES-NI.

Release 1.6.5 for CyaSSL adds bug fixes and x509 v3 self signed certificate generation.  For general build instructions see doc/Building_CyaSSL.pdf.  For details on how to use certificate generation, refer to section 11 in the wolfSSL manual.

To enable certificate generation support, add this option to ./configure

./configure –enable-certgen

An example is included in ctaocrypt/test/test.c and documentation is provided in doc/CyaSSL_Extensions_Reference.pdf item 11. Please contact support@yassl.com with any questions.

Here’s a nice article for embedded designers faced with securing an 802.11 device:  https://www.embedded.com/design/prototyping-and-development/4206409/10-things-to-consider-when-securing-an-embedded-802-11-Wi-Fi-device.
 
Stapko’s item 8 on the list caught our attention.  He correctly states that “Wi-Fi security protocols are big and slow.”  However, the article is an overview, and is not intended to discuss which ones are bigger and slower, and which ones are smaller and faster.  This, of course, is where we must chirp up and make the point that the wolfSSL embedded ssl solution is sized under 50k, as opposed to some solutions which are 20-50 times that size.

John Sawyer of Dark Reading has put out another great blog post on using SHODAN to find exposed network devices like “printers, routers, fiber channel switches and industrial control systems” on a corporate network, and provides some useful advice for discovering those devices.  See:  https://www.darkreading.com/risk/finding-exposed-devices-on-your-network/d/d-id/1134269? for the full post.

Have you ever wondered if there is a reason for the wolf in our logo? Why does a security company that focuses on embedded SSL products choose a wolf over any number of possible logo designs? We chose a wolf to be part of our logo for several reasons:

• Wolves like to live in free and open environments.
• Wolves communicate and hunt in packs, like open source developers hunt bugs.
• Wolves are lean and fast.

Our recent release of the yaSSL Embedded Web Server:

http://www.prweb.com/releases/2010/06/prweb3468504.htm

The yaSSL Embedded Web Server is available for download for both OSX and Linux from our downloads page.  We look forward to hearing your feedback!  Please contact us for more information regarding the yaSSL Embedded Web Server.

The yaSSL Embedded Web Server is now available for download on Mac OS X and Linux!  The yaSSL Embedded Web Server is based on the popular Mongoose embedded web server – adding built-in SSL functionality.  Working closely with the Mongoose community, we have made it a priority to keep our focus on what customers want.  Reasoning behind choosing the Mongoose web server included:

•   Default size, with CyaSSL enabled, of less than 200K.

•   Excellent code base and community.

•   Portability to real time and embedded operating systems.

For more information about the Mongoose Web Server, documentation (including a manual, full web application example, API reference, and embedding strategies) can be viewed here: http://code.google.com/p/mongoose/w/list

Please contact us at info@yassl.com for more information regarding the yaSSL Embedded Web Server.  Download test and evaluation copies for OS X and Linux here: Download yaSSL Embedded Web Server.  We welcome your feedback!

Release 1.6.0 for the wolfSSL embedded ssl library adds bug fixes, support for RIPEMD-160 and SHA-512 algorithms and RSA key generation.  For general build instructions see doc/Building_wolfSSL.pdf.  For build options to enable RIPEMD-160 and SHA-512, please see the README included in the download.

Please contact support@yassl.com with any questions.