RECENT BLOG NEWS

Although ECC support for the wolfSSL lightweight SSL library has been available in our GitHub repository for the past several weeks, we wanted to officially announce it to our users and customers. An official download of wolfSSL with ECC will be available on the www.yassl.com website with the next official release of wolfSSL.

wolfSSL’s ECC implementation can be found in the /cyassl/ctaocrypt/ecc.h header file and the /ctaocrypt/src/ecc.c source file. Supported ECC cipher suites include:

/* ECDHE suites */
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

/* ECDH suites */
TLS_ECDH_RSA_WITH_AES_256_CBC_SHA
TLS_ECDH_RSA_WITH_AES_128_CBC_SHA
TLS_ECDH_ECDSA_WITH_AES_256_CBC_SHA
TLS_ECDH_ECDSA_WITH_AES_128_CBC_SHA
TLS_ECDH_RSA_WITH_RC4_128_SHA
TLS_ECDH_ECDSA_WITH_RC4_128_SHA
TLS_ECDH_RSA_WITH_3DES_EDE_CBC_SHA
TLS_ECDH_ECDSA_WITH_3DES_EDE_CBC_SHA

/* AES-GCM suites */
TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256
TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384
TLS_ECDH_ECDSA_WITH_AES_128_GCM_SHA256
TLS_ECDH_ECDSA_WITH_AES_256_GCM_SHA384
TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256
TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384
TLS_ECDH_RSA_WITH_AES_128_GCM_SHA256
TLS_ECDH_RSA_WITH_AES_256_GCM_SHA384

To view or download the most recent version of the wolfSSL sources with ECC integrated, please visit our source repository on GitHub (https://github.com/cyassl/cyassl). If you have any questions about ECC support in wolfSSL, please let us know at info@yassl.com

Support for the MIT GSS-API library is now available for the Android platform – complete with an org.ietf.jgss (RFC 5653) compatible application programming interface, wolfSSL cryptography integration, and NDK sample application.

You may have read our previous blog entry announcing the initial phases of our effort to port the MIT Kerberos libraries and wolfSSL embedded SSL library to the Android platform (see link in Reference section, below). This post described initial availability of the Kerberos libraries to Android through the native NDK framework – enabling Android NDK developers to add Kerberos support to their NDK applications at a native C or C++ programming level. At that time, we also commented on next steps for the project and sought feedback from the community on adding a Java API to make using Kerberos on Android easier and more standardized.

Since that time, we have been hard at work enhancing the project, adding support for a new Java GSS-API wrapper, updating our example code, and adding new features to our sample NDK application.

1. Java GSS-API Wrapper

The addition of a Java wrapper around the native MIT GSS-API took part in two stages – a SWIG-generated (http://www.swig.org/) Java interface, which then in turn was used as a building block for a org.ietf.jgss Java API. The individual layers are visualized in the figure below. Both the SWIG layer and the Java GSS-API layer are able to be used in a Java application to access the underlying MIT Kerberos/GSS-API libraries. The SWIG layer is more tedious to use and less standardized than the Java GSS-API layer, but is closer to the C programming API of the native MIT GSS-API. We suggest that Java developers use the org.ietf.jgss Java interface over using the SWIG layer directly. As the org.ietf.jgss interface followed RFC 5653, Java developers should be able to refer to the standard Java documentation for the org.ietf.jgss package for usage instructions and class descriptions.

Source code for this project has been released under the open source MIT license, and is currently available for download on GitHub. Both the Java Generic Security Services API wrappers (SWIG and Java GSS-API), as well as example client and server applications and build instructions are located in the kerberos-java-gssapi package, at the following GitHub URL:

http://github.com/cconlon/kerberos-java-gssapi

2. Enhanced Example Code

Included in the Java GSS-API package, we have created several example applications to help developers understand how to use this project in their own application. There are two sets of client and server examples provided. The first one is a set of client and server applications which directly use the SWIG-generated Java interface. The second set of applications is a client and server that use the more standardized Java GSS-API interface (org.ietf.jgss).

It is recommended for Java developers to use the Java GSS-API examples, as they demonstrate programming and API usage which is more common in the Java programming language. Before running any of the included examples, the development machine must first have a krb5.conf file and KDC set up correctly to match the principal names used in the examples. For more details about building and running these example applications, please see the README included in the kerberos-java-gssapi package.

3. Sample NDK Application

As one of the main goals of this project was to bring MIT Kerberos/GSS-API support to the Android platform, we have created a sample Android NDK application to serve as an example and reference to Android developers. This sample application provides a GUI wrapper around the MIT Kerberos kinit, klist, kvno, and kdestroy applications. It also provides a sample client using the Java GSS-API interface to connect and communicate with the example server application (from Section 2, above).

This package contains cross-compiled version of the MIT Kerberos libraries, and includes instructions on how to re-compile the Kerberos libraries yourself for the Android platform. For details on how to build and run this example application in the Android emulator, please see the README file located in the NDK application package.

All sources for this sample application are located in the kerberos-android-ndk package, located at the following URL:

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

yaSSL and MIT are excited to bring Android developers MIT Kerberos and GSS-API support and look forward to seeing what kinds of applications will use this functionality. If you have any questions, comments, or feedback, we would enjoy to hear it! Please contact us directly at info@yassl.com.

References:

MIT Kerberos: http://web.mit.edu/kerberos/
wolfSSL: http://yassl.com/yaSSL/Products-cyassl.html
kerberos-java-gssapi: http://github.com/cconlon/kerberos-java-gssapi
kerberos-android-ndk: http://github.com/cconlon/kerberos-android-ndk
Initial announcement: https://www.wolfssl.com/android-kerberos-port-using-wolfssl-embedded-ssl/

Thanks,
Team yaSSL

Hello Kinetis users!  

Our team has now ported and released wolfSSL lightweight SSL for Freescale Kinetis.  The newest work is for MQX/RTCS/MFS on Kinetis tower systems.  Check our Github repository for the most recent source code:

https://github.com/cyassl/cyassl

If you are a Kinetis user, you will also be pleased to know that we support FreeRTOS, Micrium, and bare metal or operating systemless (NO_OS) configurations as well.  You will find wolfSSL is optimal for connected home and Smart Grid security applications on Kinetis.

In addition to MQX/RTCS/MFS support, Kinetis onboard Random Number Generator Accelerator (RNGA) support is also available for wolfSSL.  If you have a demanding performance requirement for your crypto, then let us know.  We can work with you to optimize the following hardware supported algorithms:  DES, 3DES, AES, MD5, SHA-1, SHA-256.  We are also available to help with SHA-3.

We have bundled several example CodeWarrior projects with wolfSSL for MQX/RTCS/MFS, including a wolfSSL library project, CTaoCrypt test app, and wolfSSL example client. When building wolfSSL for MQX, define FREESCALE_MQX in cyassl/ctaocrypt/settings.h. This in turn defines FREESCALE_K70_RNGA which enables support for the Kinetis H/W RNGA.

You are welcome to contact us with any support or configuration questions at support@yassl.com.

Team yaSSL, from Montana, Idaho, Iowa, Washington, and Oregon.  All American Crypto you can Trust.  

Have you been searching for a web server that runs on SafeRTOS? We recently ported the yaSSL Embedded Web Server and wolfSSL embedded SSL library to the SafeRTOS operating system. This means that you can easily serve up HTTPS content from your SafeRTOS-enabled project. The yaSSL Embedded Web Server offers a very small footprint, with build sizes of 100kB with SSL enabled (or 40kB without SSL). It also offers a full list of features including SSI, aliases, digest authorization, IP restrictions, and more.

From the SafeRTOS website, “SAFERTOS® is a unique real-time, deterministic operating system especially designed for critical applications. It is available pre-certified according to key standards in markets including Industrial and Medical. First certified by TÜV SÜD in 2007, SAFERTOS was developed in compliance with IEC61508 SIL3, and it continues to set the pace as the first pre-certified real-time operating system available in the ROM of a micro-controller.”

If you are interested in learning more about our port, or would like to try out either of these products on a SafeRTOS platform, please contact us at info@yassl.com for details.

yaSSL Embedded Web Server: http://yassl.com/yaSSL/Products-yassl-embedded-web-server.html
wolfSSL embedded SSL library: http://yassl.com/yaSSL/Products-cyassl.html
SafeRTOS: http://www.highintegritysystems.com/safertos/

Here`s a good article if you`re wondering how SHA-3 will be used:  http://community.embeddedswstore.com/t5/Embedded-Connection/Why-Does-Embedded-Security-Get-Overlooked/ba-p/286

From the article:

“What then will SHA-3 be good for? While Polk says it may take years to identify all the possibilities for Keccak, it immediately provides an essential insurance policy in case SHA-2 is ever broken. He also speculates that the relatively compact nature of Keccak may make it useful for so-called “embedded” or smart devices that connect to electronic networks but are not themselves full-fledged computers. Examples include sensors in a building-wide security system and home appliances that can be controlled remotely.
 
‘The Internet as we know it is expanding to link devices that many people do not ordinarily think of as being part of a network,’ Polk says. ‘SHA-3 provides a new security tool for system and protocol designers, and that may create opportunities for security in networks that did not exist before.’”

yaSSL is considering implementing a beta of SHA-3 in our wolfSSL embedded SSL product.  Our current timeline will have code available sometime around Christmas this year.  If you`re interested in taking a look at our implementation, then email us at info@yassl.com.

Researchers from two German universities have found that a large number of Android applications available today in the Google Play store have vulnerabilities related to SSL usage which may open the door for malicious man-in-the-middle attacks. You can find several blog posts explaining the vulnerabilities including one from Network World and the H Online.

The researchers explain several of the mis-use cases that can arise in these Android apps in their paper, linked below. Listed from the paper, these include:

“Trusting all Certificates. The TrustManager interface can be implemented to trust all certificates, irrespective of who signed them or even for what subject they were issued.

Allowing all Hostnames. It is possible to forgo checks of whether the certificate was issued for this address or not, i. e., when accessing the server example.com, a certificate issued for some-other-domain.com is accepted.

Trusting many CAs. This is not necessarily a flaw, but Android 4.0 trusts 134 CA root certificates per default. Due to the attacks on several CAs in 2011, the problem of the large number of trusted CAs is actively debated.

Mixed-Mode/No SSL. App developers are free to mix secure and insecure connections in the same app or not use SSL at all. This is not directly an SSL issue, but it is relevant to mention that there are no outward signs and no possibility for a common app user to check whether a secure connection is being used. This opens the door for attacks such as SSL stripping or tools like Firesheep.”

To read the full paper, take a look here. The wolfSSL embedded SSL library runs on Android and can be used in Android NDK-based applications for SSL support. If you need guidance on how to correctly use wolfSSL in your project or application, email us at info@yassl.com for more information.

Research Paper: Why Eve and Mallory Love Android: An Analysis of Android SSL (In)Security
Network World: Some Android apps have serious SSL vulnerabilities, researchers say

On October 12, NIST announced Keccak as the winner of its Secure Hash Algorithm (SHA-3) competition.

Keccak is designed to permute the data in a different manner than MD5, SHA-1, and SHA-2, making it immune to many of the attacks on those hashes. It promises roughly 13 cycles per byte to process the hash. The hash is limited to using bitwise XOR, AND, NOT, and rotations. It will need up to 1600 bytes of RAM for the hash state, but no lookup tables. It provides arbitrary sized output. Keccak can also perform keyed hashing, by setting the initial state by priming the hash with the key. The algorithm is simple and small, perfect for embedded systems.

If you would be interested in talking about Keccak, SHA-3, and wolfSSL embedded SSL, send an email to info@yassl.com.

1. http://www.nist.gov/itl/csd/sha-100212.cfm
2. http://keccak.noekeon.org/

Do you currently use the Yocto Project or OpenEmbedded? We would like to announce the availability of the “meta-yassl” layer for both Yocto and OpenEmbedded. This layer adds support for the lightweight wolfSSL embedded SSL library to these projects and can be easily added to your existing Yocto or OpenEmbedded setup. The layer can be found on GitHub at the following URL:

https://github.com/cconlon/meta-yassl

If you are not familiar with the Yocto Project, it is an “open source collaboration project that provides templates, tools and methods to help you create custom Linux-based systems for embedded products regardless of the hardware architecture.” You can learn more about Yocto at www.yoctoproject.org or OpenEmbedded at www.openembedded.org.

As a reminder, wolfSSL is open source and dual licensed under both the GPLv2 as well as a standard commercial license. This means you are free to prototype with, test with, or use wolfSSL free of charge under the terms of the GPLv2. If your project will need a commercial license or you would like commercial support direct from yaSSL, please contact us and we’ll be happy to give you more details.

If you have any questions about the new meta-yassl layer, the wolfSSL embedded SSL library, or how we can help you integrate SSL into your project, please contact us at info@yassl.com.

yaSSL and Intel have jointly published a white paper describing how Intel’s AES-NI can be used with the wolfSSL embedded SSL library. This paper provides a brief overview of the Intel AES-NI instructions and demonstrates the performance gains realized when Intel AES-NI is used in place of a more traditional software-only based AES implementation. The wolfSSL embedded SSL library developed by yaSSL, is used as a test bed in the white paper to perform the comparison as it can be built with either traditional AES or AES-NI support at compile time. As a secondary goal to demonstrating Intel AES-NI performance, this paper explains how to determine if a pre-built SSL library (static or shared) offers built-in support for the Intel Advanced Encryption Standard New Instructions.

You can download the white paper directly from the yaSSL website at the following location. If you have any questions about using wolfSSL on Intel hardware, please contact us at info@yassl.com.

wolfSSL AES-NI White Paper: yaSSL White Papers (http://yassl.com/yaSSL/cyassl-embedded-ssl-white-papers.html)

You may have noticed that with our most recent release of the wolfSSL embedded SSL library (2.3.0), we have made our example client and server applications more flexible and easier to use. These updated applications – client (./examples/client/client) and server (./examples/server/server) – now offer a variety of command line options to adjust things ranging from SSL certificates to protocol version selection.

Looking at the example client application, if you run the app with the “–help” option, you will see a list of supported options:

./examples/client/client –help
client 2.3.1 NOTE: All files relative to wolfSSL home dir
-? Help, print this usage
-h Host to connect to, default 127.0.0.1
-p Port to connect on, default 11111
-v SSL version [0-3], SSLv3(0) – TLS1.2(3)), default 3
-l Cipher list
-c Certificate file, default ./certs/client-cert.pem
-k Key file, default ./certs/client-key.pem
-A Certificate Authority file, default ./certs/ca-cert.pem
-b Benchmark connections and print stats
-s Use pre Shared keys
-d Disable peer checks
-g Send server HTTP GET
-u Use UDP DTLS
-m Match domain name in cert

Likewise, looking at the server, you can see a variety of command line options available as well:

./examples/server/server –help
server 2.3.1 NOTE: All files relative to wolfSSL home dir
-? Help, print this usage
-p Port to listen on, default 11111
-v SSL version [0-3], SSLv3(0) – TLS1.2(3)), default 3
-l Cipher list
-c Certificate file, default ./certs/server-cert.pem
-k Key file, default ./certs/server-key.pem
-A Certificate Authority file, default ./certs/client-cert.pem
-d Disable client cert check
-b Bind to any interface instead of localhost only
-s Use pre Shared keys
-u Use UDP DTLS

We hope this will make testing connections and wolfSSL builds much easier and less time consuming. If you have any suggestions for future improvement, please let us know at info@yassl.com.