wolfCrypt JNI provides a Java, JNI-based wrapper to the native wolfCrypt API and implements wolfJCE as a JCE provider for Java’s built in security packages. wolfSSL is committed to providing the best tested cryptography available, and as such have expanded our automated testing of wolfCrypt JNI and JCE.  Both FIPS 140-2 and non-FIPS builds of wolfCrypt JNI and wolfJCE are tested nightly through our Jenkins CI, with JUnit and Project Wycheproof unit tests.

Project Wycheproof is a test suite developed and maintained by the Google Security Team. Their unit tests use Java security packages (java.security and javax.crypto) to allow for multiple JCA/JCE provider implementations to be tested, including wolfJCE. Over 80 of their unit tests attempt to detect unexpected behavior, vulnerabilities to attacks, and other known weaknesses.

wolfSSL has confidence in having high quality security software built on a foundation of continuously expanding unit tests.

Please send any feedback or questions to us at facts@wolfssl.com.

wolfCrypt-JNI
Download: https://wolfssl.com/download
GitHub: https://github.com/wolfSSL/wolfcrypt-jni
Manual: https://www.wolfssl.com/docs/wolfcrypt-jni-jce-manual

Project Wycheproof
GitHub: https://github.com/google/wycheproof

And a shout out to Project Wycheproof maintainers:

• Daniel Bleichenbacher
• Thai Duong
• Emilia Kasper
• Quan Nguyen

We have created a new repository for hosting the FreeRTOS classic and Amazon FreeRTOS support for wolfSSL located here:
https://github.com/wolfSSL/wolfssl-freertos

There are two pull requests with support for wolfSSL including demos:

FreeRTOS Classic v10.0.1 with wolfSSL/wolfMQTT demos:
https://github.com/wolfSSL/wolfssl-freertos/pull/1

• Added a wolfMQTT FreeRTOS TCP demo. This demo connects to the iot.eclipse.org MQTT broker with TLS on port 8883. It sends a counter publish message every second.
• Updated wolfSSL demo:
• Project built and tested against latest v3.14.4 release.
• Switched to using user_settings.h (WOLFSSL_USER_SETTINGS).
• Updated the certs (expired Jan 31, 2018).
• Stop tracking the .filter project file.
• Add submodule for wolfMQTT v1.0 plus FreeRTOS TCP support.
• Replace wolfSSL sources with submodule wolfSSL v3.14.4 plus some Win VS fixes.
• Initial FreeRTOS v10.0.1

Amazon FreeRTOS v1.2.3 port to use wolfSSL:
https://github.com/wolfSSL/wolfssl-freertos/pull/2

• Port of the Amazon FreeRTOS v1.2.3 to use wolfSSL.
• Added a new solution and project for demo at FreeRTOS-AWS/demos/pc/windows/visual_studio/aws_demo_wolf.sln.
• Added wolfssl as submodule.

Are you a Java developer looking for a industry-leading SSL/TLS and crypto implementation?  If so, you’re in luck!  wolfSSL provides has several options for you to use the native wolfSSL embedded SSL/TLS library and wolfCrypt cryptography libraries from Java.

wolfSSL TLS from Java

wolfSSL packages and maintains a JNI wrapper around the native C wolfSSL SSL/TLS library.  This wrapper encapsulates the SSL/TLS functionality of wolfSSL to be used from Java applications.

This wrapper is a thin wrapper around the native wolfSSL C API.  wolfSSL does not currently have a pluggable TLS-level JSSE provider.  If this is something you are interested in, please contact us at facts@wolfssl.com!  wolfSSL does offer a wolfCrypt-level pluggable JCE provider (see section below).

Full documentation on the wolfSSL JNI wrapper can be found here:  wolfSSL JNI Manual

wolfSSL JNI ships with both a client and server example to make plugging it into a Java application easy!

wolfCrypt Cryptography from Java

wolfSSL packages and maintains a JNI wrapper and JCE provider for the native C wolfCrypt library.  The “wolfcrypt-jni” package contains both a thin wolfCrypt JNI wrapper around the native C library as well as a pluggable wolfCrypt JCE provider.

Both of the following wrappers can be used with either normal wolfCrypt or wolfCrypt FIPS for those users who require a FIPS 140-2 validated cryptography library.

wolfCrypt JNI Wrapper

This wrapper is a thin wrapper around the native C wolfCrypt API.  It is designed for users who want to use wolfCrypt directly from a Java application, but do not want to go through the default Java Security API.

wolfCrypt JCE Provider

The JCE (Java Cryptographic Extension) framework supports the installation of custom Cryptographic Service Providers which can implement a subset of the cryptographic functionality used by the Java Security API.

The wolfCrypt JCE provider has been tested with several different JDK variants, including OpenJDK, Oracle JDK, and Android. It also ships with pre-signed JAR files for use with Oracle JDK versions that will correctly verify JCE provider classes.  OpenJDK does not have the requirement that JCE provider JAR’s be signed.

Classes and algorithms currently supported by the wolfCrypt JCE Provider:

You can download wolfSSL JNI as well as the wolfCrypt JNI wrapper and JCE provider from the wolfSSL download page.  Please send any feedback or questions to us at facts@wolfssl.com.

wolfSSL is pleased to announce the following addition to the wolfSSL FIPS certificate!

The wolfCrypt FIPS validated cryptographic module has been validated while running inside an Intel SGX enclave and examples have been setup for both Linux and Windows environments.

Intel ® SGX (Software Guard Extensions) can be thought of as a black-box where no other application running on the same device can see inside regardless of privilege. From a security standpoint this means that even if a malicious actor were to gain complete control of a system including root privileges, that actor, no matter what they tried, would not be able to access data inside of this “black-box”.

An Intel enclave is a form of user-level Trusted Execution Environment (TEE) which can provide both storage and execution. Meaning one can store sensitive information inside and also move sensitive portions of a program or an entire application inside.

While testing, wolfSSL has placed both individual functions and entire applications inside the enclave. One of the wolfSSL examples shows a client inside the enclave with the only entry/exit points being “start_client”, “read”, and “write”. The client is pre-programmed with a peer to connect with and specific functionality. When “start_client” is invoked it connects to the peer using SSL/TLS and executes the pre-programmed tasks where the only data entering and leaving the enclave is the info being sent to and received from the peer. Other examples show placing a single cryptographic operation inside the enclave, passing in plain-text data and receiving back encrypted data masking execution of the cryptographic operations.

If you are working with SGX and need FIPS validated crypto running in an enclave contact us at fips@wolfssl.com or support@wolfssl.com with any questions. We would love the opportunity to field your questions and hear about your project!

Resources:
https://software.intel.com/en-us/blogs/2016/12/20/overview-of-an-intel-software-guard-extensions-enclave-life-cycle

Recent releases of wolfSSL have included new assembly code targeted at the Intel x86_64 platform. Large performance gains have been made and are being discussed over six blog posts of which this is the last part. In this blog, we will talk about the performance of Elliptic Curve (EC) operations over the P-256 curve.

Elliptic curve cryptography (ECC) is the alternative to finite field (FF) cryptography which has algorithms like RSA, DSA and DH. ECDSA is the elliptic curve variant of RSA and DSA while ECDH is the elliptic curve variant of DH. ECDSA and ECDH can be used anywhere their FF counterparts can be used. ECC requires a pre-defined curve to perform the operations on. The most commonly used curve is P-256 as it has 128-bit strength and is in many standards including TLS, for certificates in IETF, and NIST’s FIPS 186-4. Browsers and web servers are preferring ECDH over DH as it is much faster.

wolfSSL 3.13 and later have completely new implementations of the EC algorithms over the P-256 curve. The implementation is constant-time with respect to private key operations. The implementations include variants in C, and assembly code targeted at Intel x86_64 and x86_64 with BMI2 and ADX. There is a small code size variant of the assembly code that is about 1/3rd the size (smaller pre-computed tables) yet remains very fast.

The two charts below show the relative performance of the old wolfSSL code, new small wolfSSL assembly code, new fast wolfSSL assembly code and OpenSSL as compared to the new wolfSSL C implementation on Ivy Bridge and Skylake CPUs. Note that the OpenSSL super-app does not measure the speed of the ECDH key generation operation. The new C implementation is a lot faster than the old generic C/ASM code for both CPUs. The assembly code is many times better than the C code mostly due to the use of larger pre-computed tables of elliptic curve points. The OpenSSL code is around 10% slower than the new fast wolfSSL assembly code using the generic x86_64 code and between 5% and 35% slower than wolfSSL assembly code for x86_64 with BMI2 and ADX instructions.

Contact us at support@wolfssl.com with questions about the performance of the wolfSSL embedded TLS library.

References:

ECDSA (Elliptic Curve Digital Signature Algorithm)
ECDH (Elliptic-curve Diffie–Hellman)