RECENT BLOG NEWS

We`ve noticed a couple articles lately mentioning printers as potential attack vectors.  One is particularly disturbing in that not only is a network breach possible, as if that`s not bad enough, but cracked firmware could cause a printer to heat up enough to start a fire: http://redtape.msnbc.msn.com/_news/2011/11/29/9076395-exclusive-millions-of-printers-open-to-devastating-hack-attack-researchers-say .  

An easy way to prevent attack vectors like these is to build in a secure firmware updater.  Of course we think the embedded SSL solution wolfSSL is a perfect fit for this job.  Several printer models already use wolfSSL to secure documents and resources on the network.  We`d like to assist and provide tools to printer vendors (or any device vendor really) to protect the firmware, preventing attacks against data, property, and even lives.  Let us know if you have any questions or comments or are interested in building/using tools for firmware protection.

Team yaSSL.

Ever wondered what forward secrecy is and how it applies to SSL/TLS?  Forward secrecy protects current encryption even in the event of a future crack of a long term private key.  Using ephemeral keying in TLS with DHE or ECDHE yields this protection because the temporary key is unique and never used again.  So even if the server`s private key is cracked two years from now your current communication is still secure.  wolfSSL offers several cipher suites that give users this added security:

TLS_DHE_RSA_WITH_AES_256_CBC_SHA256
TLS_DHE_RSA_WITH_AES_128_CBC_SHA256

TLS_DHE_RSA_WITH_AES_256_CBC_SHA
TLS_DHE_RSA_WITH_AES_128_CBC_SHA

TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA
TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA
TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA
TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA
TLS_ECDHE_RSA_WITH_RC4_128_SHA
TLS_ECDHE_ECDSA_WITH_RC4_128_SHA
TLS_ECDHE_RSA_WITH_3DES_EDE_CBC_SHA
TLS_ECDHE_ECDSA_WITH_3DES_EDE_CBC_SHA
  
If you have any comments or questions please let us know.

Happy Thanksgiving, 
Team yaSSL

We often get asked how wolfSSL compares to OpenSSL and what advantages it brings to a project if it replaces a current OpenSSL implementation. To give you a short comparison, see the points below.

• Size: With a 30-100kB build size and runtime memory usage between 3-36kB, wolfSSL can be up to 20 times smaller than OpenSSL. In an embedded environment where footprint size is critical or a large cloud environment where memory usage per connection makes a big impact on the performance and success of a project, wolfSSL is an optimal SSL and cryptography solution.

• Standards Support: wolfSSL is up-to-date with the most recent standards of TLS 1.2 and DTLS which OpenSSL has yet to address. With the recently-presented crack in TLS 1.0, your project should use either TLS 1.1 or TLS 1.2 for maximum security – both of which wolfSSL fully supports on both the client and server side.

• Progressive Cipher Support: wolfSSL is kept progressive with support for new and secure ciphers. wolfSSL includes some of the best current ciphers for streaming media support, including the HC-128 and RABBIT stream ciphers. Standard ciphers are supported as well including EDH on both the client and server side.

• Portability: wolfSSL is the leading SSL library for real-time, mobile, embedded, and enterprise systems, by virtue of its breadth of platform support and successful implementations. With a long list of supported platforms out of the box, your time to market can be decreased dramatically by using wolfSSL. OpenSSL requires porting to many platforms, which can cost your team both time and money.

• License: wolfSSL is dual licensed and available both under the GPLv2 as well as a standard commercial license. OpenSSL is available under a unique license from multiple sources.

• Support: wolfSSL was written from the ground up and is maintained and developed by the original developers. With a wolfSSL license comes one full year of support. Available directly through phone, email or the yaSSL product support forums, your questions are answered quickly and accurately to help you make progress on your project as quickly as possible.

• Ease of Use: OpenSSL is burdened with legacy code that must be maintained and kept up to date. wolfSSL was written from the beginning with developers in mind. Because of this mindset, wolfSSL has been developed with a simple and documented API, easy-to-use abstraction layers for OS, Custom I/O, and Standard C library, and clear usage examples.

If you have any further questions about how wolfSSL compares to OpenSSL, please let us know at info@yassl.com.

yaSSL has recently ported the MIT Kerberos libraries to Android. The Android platform has previously been void of Kerberos support – forcing Android developers who are creating new applications or porting existing projects to either modify existing code or exclude Kerberos functionality from their apps and libraries altogether.

yaSSL has taken the first steps in bringing Kerberos to the Android platform. The native MIT Kerberos libraries have been cross-compiled for Android and are now able to be used natively with the Android NDK. yaSSL has added the wolfSSL embedded SSL library`s cryptography library (CTaoCrypt) as a crypto implementation for Kerberos, allowing embedded projects to use wolfSSL`s lightweight and fully functional crypto backend on Android.

In addition to the cross-compiled MIT Kerberos libraries, yaSSL has created a sample Android NDK application wrapping the functionality of kinit, klist, kvno, and kdestroy with a simple GUI front-end. We hope this application provides a starting place for application developers interested in using Kerberos on Android.

The MIT Kerberos libraries and sample application are distributed under the MIT license (using wolfSSL`s FLOSS exception) and the code will be in the MIT Kerberos code repository in the near future. Until it has been merged into the MIT repositories, you can find the sample application on GitHub at the following URL. The sample application includes cross-compiled Kerberos and wolfSSL libraries. Instructions on cross compiling MIT Kerberos yourself will be released in the near future.

https://github.com/cconlon/kerberos-android-ndk

Our next step is to work on adding Java bindings for the native Kerberos GSS-API library on Android. As we have looked into several methods of accomplishing this, we would like to hear what the community would like to see regarding the Java bindings. Also, we would like to explore if there are any existing solutions which could be useful. The options we have looked at thus far include:

– Porting over an existing org.ietf.jgss Java package to Android and tying that into the native GSS-API library through JNI.
– Using SWIG to generate Java wrappers to the native GSS-API.

Are you interested in using Kerberos on Android? What do you think the best path would be for adding Java bindings? Do you have any suggestions about the direction of the project so far? If so, please let us know your thoughts at info@yassl.com.

Thanks!

Team yaSSL
info@yassl.com

We recently did a preliminary port of wolfSSL to Microchip’s PIC32, which will be further explained and announced in a future release of wolfSSL. Are you using wolfSSL with a Microchip board? If so, we’re prepared to support you if you run into any problems or issues.

Let us know at info@yassl.com if you’ve tried wolfSSL with a Microchip board, or if you have any questions about wolfSSL in general.

Microchip PIC32: http://www.microchip.com/en_us/family/32bit/

– Team yaSSL

Why is wolfSSL a great solution when you have millions of connections per server?  Memory consumption per connection can be as low as 3k, varying with the size of input and output buffers. This brings wolfSSL’s runtime memory consumption to 3-36kB depending on buffer size. Input and output buffers are created on demand when smaller than MAX_RECORD_SZ unless the user turns on STATIC_CHUNKS_ONLY.  

In contrast,  OpenSSL typically consumes 50-140k per connection.  wolfSSL emphasizes small size, speed, and low memory use.  These attributes make wolfSSL ideal for scaling on a huge magnitude.   Other libraries often run into problems when trying to scale to hundreds of thousands of connections for applications like load balancing or cloud services.  We have users doing just that.  

Want to hear about how wolfSSL is being scaled in the cloud?  Contact us and we`ll share some of the use cases currently in production.  

If you would like to stay updated on yaSSL news, press releases, and new software versions, please follow us on Twitter, Facebook, or follow our blog RSS feed. You can find us at the following locations:

Facebook: www.facebook.com/wolfssl
Twitter: www.twitter.com/wolfssl
Blog RSS: https://www.wolfssl.com/feed/

If you have any questions about wolfSSL or the yaSSL Embedded Web Server, please let us know at info@yassl.com.

Thanks,
Team yaSSL

During the ARM Technology Conference last week, ARM and Avnet Electronics Marketing announced the launch of their online Embedded Software Store. The goal of this store is to provide developers and companies a single place to easily explore, find, and purchase software components, thus helping bring new products to market faster than ever.

The store is now online and can be viewed at www.embeddedsoftwarestore.com. Users can choose from a large collection of reputable software vendors, including yaSSL! The site offers a streamlined checkout process, including a quick download delivery system and preview of all license agreements in advance of the purchase.

Press Release: http://www.arm.com/about/newsroom/avnet-electronics-marketing-and-arm-launch-embedded-software-store.php

We`ve noticed a trend lately of the latest operating systems and browsers removing support for MD5 signed SSL certificates.  iOS 5, IE 9, and others have moved away from MD5.  wolfSSL now signs certificates with SHA-1 by default and has support for SHA-256 signed certificates as well.  If anyone would like support for SHA-512 please let us know, though it doesn`t appear to be widely adopted at the moment.  The default test certificates for embedded wolfSSL are now all SHA-1 with RSA 2048 bit.  It`s the same combination you`ll notice from most banks, paypal, and google.  If you have any questions or feedback please let us know.

Cheers,
Team yaSSL 

Here`s an excellent article in EE Times on writing energy efficient ARM code https://www.eetimes.com/document.asp?doc_id=1279523 .

Our wolfSSL embedded SSL product is designed with many of these principles in mind, but of course the design goal of energy efficiency takes a back seat to overall security.  In some cases, the goals of energy efficiency and overall security mesh well.

By the way, come see us at ARM TechCon.  If you need a pass, let us know at info@yassl.com and we`ll send you one.