wolfSSL on Google Glass

Hi!  We received our Google Glass a few weeks ago.  It is a fun new toy for our team!  

After getting through the standard process of playing with them and getting familiar with the tools, we have decided to embark on the coding.  We will port and verify a number of items on Glass, including wolfSSL lightweight TLS, wolfCrypt, and MIT Kerberos.  Should be fun!  Let us know if you have an interest in our wolfCrypt cryptography library running on Glass, as it will be the first of our tools that we bring to the environment.  

If you have questions for us about running any of our projects on Google Glass, then don`t hesitate to email us at info@wolfssl.com, or simply call at +1 425 245 8247.

Using the MIT Kerberos GSS-API with wolfSSL on Android

Are you interested on using the GSS-API with Kerberos on Android? If so, you’ll be happy to hear about wolfSSL’s port of the MIT GSS-API library to Android platform – complete with an org.ietf.jgss (RFC 5653) compatible application programming interface, CyaSSL cryptography integration, and NDK sample application.

You may have read our previous blog entries about porting the MIT Kerberos libraries and CyaSSL embedded SSL library to the Android platform (see link in Reference section, below). With this post, we wanted to take a moment to describe current availability of the Kerberos and GSS-API libraries on Android through the native NDK framework and the Java GSS-API wrapper.

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 follows 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

wolfSSL looks 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@wolfssl.com.

References:

MIT Kerberos: http://web.mit.edu/kerberos/
CyaSSL: http://wofssl.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: http://yassl.com/yaSSL/Blog/Entries/2011/11/15_Android_Kerberos_Port_using_CyaSSL_Embedded_SSL.html

Thanks,
Team wolfSSL

More Dual_EC_DRBG News

It was reported yesterday in The Guardian and elsewhere that the NSA paid RSA $10M to set Dual_EC_DRBG as their default PRNG.  See the news here:  http://www.theguardian.com/world/2013/dec/20/nsa-internet-security-rsa-secret-10m-encryption.  

As we have previously stated, we never implemented Dual_EC_DRBG in any of our products, much less set it as default, because of its suspect nature.  If you`re not familiar with Dual_EC_DRBG, the background on wikipedia is here:  http://en.wikipedia.org/wiki/Dual_EC_DRBG.

For even more background, here`s a great Black Hat talk by Derek Soeder, Christopher Abad, and Gabriel Acevedo from Cylance on the subject of breaking Pseudorandom Algorithms.

Assembly Optimizations Available in wolfSSL for ARM Processors

wolfSSL, as a long standing partner to ARM, has always been well optimized for ARM environments. One of the ways CyaSSL can be optimized for ARM platforms includes assembly optimizations for Public Key operations with the CTaoCrypt fastmath option. This translates to a speed increase when using RSA, Diffie-Hellman, DSA, or ECC.

If you dive into our code, these optimizations can be found in the asm.c source file.

When using the ./configure system, fastmath is enabled by default on 64-bit platforms. On 32-bit platforms, it can be enabled by using the “–enable-fastmath” option. In environments not using the ./configure system to build CyaSSL, fastmath can be enabled by defining USE_FAST_MATH. Since stack usage can be high when using fastmath, we recommend defining TFM_TIMING_RESISTANT as well.

If you have any questions about using CyaSSL in an ARM environment, please contact us at info@wolfssl.com.

More on we`re dumping SSL 3.0 support from wolfSSL

We`ve been encouraged by the feedback from the community on dropping SSL 3.0 support from wolfSSL, meaning that people think we should drop it as insecure and eliminate the legacy which goes back to 1996.  Many thanks to Paul Kocher, Phil Karlton, Alan Freier, and the many shoulders they were standing on for designing the SSL 3.0 protocol, but after 17 years, it is time to evolve to a TLS only world.  

Practically speaking, this means that we`ll deprecate SSL 3.0 code from our tree, and only apply critical security fixes.  We will of course support existing customers and open source users that need SSL 3.0 for specific reasons that are private to them.  

It might be fun to think about a name for our Q1 release of wolfSSL without SSL support.  Here`s some ideas:  SSL Minus, SSL Minas Tirith, CaTLS defend Minas Tirith.  It can go on for a while.  See http://en.wikipedia.org/wiki/Minas_Tirith for reference.  Oh, here`s another idea, how about wolfTLS?

Send in your ideas for the new name to info@wolfssl.com.

Dumping SSL v3 from wolfSSL

Hi!  We`re considering the elimination of SSL 3.0 support from wolfSSL.  There`s a lot of reasons to do it, including better security, cleaning up our code, and its time to move on and modernize.  Anybody have an opinion?  The code would still be available, but not mainline.

wolfSSL is looking to Hire!

wolfSSL 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, CyaSSL. We are also the developers of the yaSSL Embedded Web Server and wolfCrypt Crypto Engine. Our users are primarily building devices or applications that need security.

Operating environments of particular interest to us include Embedded Linux, VxWorks, QNX, ThreadX, FreeRTOS, and ARM RTX. 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@wolfssl.com.

Using Truncated HMAC with wolfSSL

Are you fan of TLS Extensions? We are here today to present the addition of Truncated HMAC on wolfSSL!

Currently defined TLS cipher suites use the HMAC to authenticate record-layer communications. In TLS, the entire output of the hash function is used as the MAC tag. However, it may be desirable in constrained environments to save bandwidth by truncating the output of the hash function to 80 bits when forming MAC tags. To enable the usage of Truncated HMAC at wolfSSL you can simply do:

./configure –enable-truncatedhmac

Using Truncated HMAC on the client side requires an additional function call, which should be one of the following functions:

wolfSSL_CTX_UseTruncatedHMAC();
wolfSSL_UseTruncatedHMAC();

wolfSSL_CTX_UseTruncatedHMAC() is most recommended when the client would like to enable Truncated HMAC for all sessions. Setting the Truncated HMAC extension at context level will enable it in all SSL objects created from that same context from the moment of the call forward.

wolfSSL_UseTruncatedHMAC() will enable it for one SSL object only, so it`s recommended to use this function when there is no need for Truncated HMAC on all sessions.

On the server side no call is required. The server will automatically attend to the client`s request for Truncated HMAC.

All TLS extensions can also be enabled with:

./configure –enable-tlsx

If you have any questions about using TLS Extensions with wolfSSL please let us know at info@wolfssl.com.