wolfSSL and libFuzzer

libFuzzer, a fuzzing engine created by LLVM, is now being used to test the wolfSSL library. Below is a short description of libFuzzer, taken from LLVM’s website here.

LibFuzzer is linked with the library under test, and feeds fuzzed inputs to the library via a specific fuzzing entrypoint (aka “target function”); the fuzzer then tracks which areas of the code are reached, and generates mutations on the corpus of input data in order to maximize the code coverage. The code coverage information for libFuzzer is provided by LLVM’s SanitizerCoverage instrumentation.

With this tool, wolfSSL API are being tested on how well they can handle random gibberish, poorly formatted certificates, and other forms of data that are created and input by the user. These tests are being used to detect buffer-overflow bugs, segmentation faults, memory leaks, undefined behaviors, and many other bugs that could potentially be used to exploit the wolfSSL library.

If you are interested in further details of how wolfSSL is using libFuzzer, email us at facts@wolfssl.com.

wolfSSL FIPS – A Year in Review (Part 1 of a 3 Part Series)

wolfSSL is pleased to bring our community a report of the past years FIPS activities. In part one of this three-part series we will cover the new Operating Environments (OEs) added to the wolfSSL certificate in the past year + CAVP algorithm testing done by wolfSSL.

Part two of this series will cover OEs tested by wolfSSL for OEM partners.

Part Three of this series will cover on-site consulting services offered by wolfSSL and some of the commentary from our on-site consulting engineers.

This past year wolfSSL added the following OEs to the wolfCrypt certificate on 06/23/2016

wolfSSL also performed algorithm testing or CAVP only validation for AES in these OEs:

The following AES modes of operation were tested: ECB, CBC, CMAC, GMAC, and GCM. The algo certificates can be visited via the following links.
http://csrc.nist.gov/groups/STM/cavp/documents/aes/aesval.html#4452 (3/31/2017)
http://csrc.nist.gov/groups/STM/cavp/documents/aes/aesval.html#4027 (7/31/2016)

wolfSSL also performed algorithm testing or CAVP only validation for SHA-256 on the Same OEs.
Those certificates can be found via the following links.
http://csrc.nist.gov/groups/STM/cavp/documents/shs/shaval.html#3665 (3/31/2017)
http://csrc.nist.gov/groups/STM/cavp/documents/shs/shaval.html#3320 (7/31/2016)

wolfSSL offers several FIPS services including but not limited to: OEM revalidations, on-site consulting for receiving your own FIPS validation, or just a traditional FIPS validation for your operating environment. For more info please contact fips@wolfssl.com and we will be happy to discuss details with you!

TLS 1.3 Reducing Latency

As we’ve mentioned in a previous blog post one of the key advantages of TLS 1.3 is the reduction in round-trips.  Older versions of the TLS protocol require two complete round-trips before the client sends the application data.  With TLS v1.3 only 1 round-trip is required!  This means network latency has less impact on the time required to establish a secure connection.  We recently completed a handshake benchmark with various latencies to make sure wolfSSL is taking advantage of the reduced latency in TLS 1.3.

For more details on using TLS v1.3 with wolfSSL, please contact us at facts@wolfssl.com

wolfCrypt JNI Wrapper and JCE Provider

The wolfCrypt cryptography library is now available to Java developers! wolfSSL recently released a JNI wrapper and JCE provider that wraps the native C wolfCrypt library.

The JCE (Java Cryptographic Extension) framework supports the installation of custom Cryptographic Service Providers which can in turn implement a subset of the underlying cryptographic functionality used by the Java Security API. The “wolfcrypt-jni” package contains both a thin wolfCrypt JNI wrapper as well as a wolfCrypt JCE provider.

This package 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 verify JCE provider classes.

Classes and algorithms currently supported by the wolfCrypt JCE Provider:

java.security.MessageDigest
MD5, SHA-1, SHA-256, SHA-384, SHA-512

java.security.SecureRandom
HashDRBG

javax.crypto.Cipher
AES/CBC/NoPadding
DESede/CBC/NoPadding
RSA/ECB/PKCS1Padding

javax.crypto.Mac
HmacMD5, HmacSHA1, HmacSHA256, HmacSHA384, HmacSHA512

java.security.Signature
MD5withRSA, SHA1withRSA, SHA256withRSA, SHA384withRSA, SHA512withRSA
SHA1withECDSA, SHA256withECDSA, SHA384withECDSA, SHA512withECDSA

javax.crypto.KeyAgreement
DiffieHellman, DH, ECDH

java.security.KeyPairGenerator
EC, DH

You can download the wolfCrypt JNI wrapper and JCE provider from the wolfSSL download page, or look over the wolfJCE User Manual. Please send any feedback or questions to us at facts@wolfssl.com.

NXP Kinetis K8X LTC support for PKI (RSA/ECC) with #TLS13

As our readers have seen us post about in the past, NXP has a new LP Trusted Crypto (LTC) core which accelerates RSA/ECC PKI in their Kinetis K8x line.

The LTC hardware accelerator improves:
* RSA performance by 12-17X
* ECC performance by 18-23X
* Ed/Curve25519 performance by 2-3X.

wolfSSL now provides support for TLS 1.3 (#TLS13), which was introduced in an internet draft in October of 2016.

If desired, the LTC hardware accelerator can be combined with TLS 1.3, providing:

* Reduced number of round trips while performing a full handshake
* A repurposed ticketing system allows for servers to be stateless
* More attack resistance from improvements to renegotiation, compression, CBC, padding, etc.

Support for the NXP LTC adds to wolfSSL’s existing mmCAU support, now accelerating RNG, AES (CBC, CCM, GCM, CTR), DES/3DES, MD5, SHA, SHA256, SHA384/512 and ChaCha20/Poly1305.

The combined LTC/MMCAU hardware acceleration improves performance, reduces power consumption and reduces code size by 40%.

Here are the benchmarks on a FRDM-K82F Cortex M4 @ 150MHz:

Hardware Accelerated (LTC / MMCAU):
RNG      25 kB took 0.026 seconds,    0.939 MB/s
AES enc  25 kB took 0.002 seconds,   12.207 MB/s
AES dec  25 kB took 0.002 seconds,   12.207 MB/s
AES-GCM  25 kB took 0.002 seconds,   12.207 MB/s
AES-CTR  25 kB took 0.003 seconds,    8.138 MB/s
AES-CCM  25 kB took 0.004 seconds,    6.104 MB/s
CHACHA   25 kB took 0.008 seconds,    3.052 MB/s
CHA-POLY 25 kB took 0.013 seconds,    1.878 MB/s
POLY1305 25 kB took 0.003 seconds,    8.138 MB/s
SHA      25 kB took 0.006 seconds,    4.069 MB/s
SHA-256  25 kB took 0.009 seconds,    2.713 MB/s
SHA-384  25 kB took 0.032 seconds,    0.763 MB/s
SHA-512  25 kB took 0.035 seconds,    0.698 MB/s
RSA 2048 public          12.000 milliseconds, avg over 1 iterations
RSA 2048 private         135.000 milliseconds, avg over 1 iterations
ECC  256 key generation  17.400 milliseconds, avg over 5 iterations
EC-DHE   key agreement   15.200 milliseconds, avg over 5 iterations
EC-DSA   sign   time     20.200 milliseconds, avg over 5 iterations
EC-DSA   verify time     33.000 milliseconds, avg over 5 iterations
CURVE25519 256 key generation 14.400 milliseconds, avg over 5 iterations
CURVE25519 key agreement      14.400 milliseconds, avg over 5 iterations
ED25519  key generation  14.800 milliseconds, avg over 5 iterations
ED25519  sign   time     16.800 milliseconds, avg over 5 iterations
ED25519  verify time     30.400 milliseconds, avg over 5 iterations

Software only:
RNG      25 kB took 0.179 seconds,    0.136 MB/s
AES enc  25 kB took 0.099 seconds,    0.247 MB/s
AES dec  25 kB took 0.102 seconds,    0.239 MB/s
AES-GCM  25 kB took 1.486 seconds,    0.016 MB/s
AES-CTR  25 kB took 0.099 seconds,    0.247 MB/s
AES-CCM  25 kB took 0.201 seconds,    0.121 MB/s
CHACHA   25 kB took 0.043 seconds,    0.568 MB/s
CHA-POLY 25 kB took 0.055 seconds,    0.444 MB/s
POLY1305 25 kB took 0.010 seconds,    2.441 MB/s
SHA      25 kB took 0.029 seconds,    0.842 MB/s
SHA-256  25 kB took 0.079 seconds,    0.309 MB/s
SHA-384  25 kB took 0.109 seconds,    0.224 MB/s
SHA-512  25 kB took 0.113 seconds,    0.216 MB/s
RSA 2048 public          147.000 milliseconds, avg over 1 iterations
RSA 2048 private         2363.000 milliseconds, avg over 1 iterations
ECC  256 key generation  355.400 milliseconds, avg over 5 iterations
EC-DHE   key agreement   352.400 milliseconds, avg over 5 iterations
EC-DSA   sign   time     362.400 milliseconds, avg over 5 iterations
EC-DSA   verify time     703.400 milliseconds, avg over 5 iterations
CURVE25519 256 key generation 66.200 milliseconds, avg over 5 iterations
CURVE25519 key agreement      65.400 milliseconds, avg over 5 iterations
ED25519  key generation  25.000 milliseconds, avg over 5 iterations
ED25519  sign   time     30.400 milliseconds, avg over 5 iterations
ED25519  verify time     74.400 milliseconds, avg over 5 iterations

For more information on how wolfSSL supports TLS 1.3, check out this page.

Download wolfSSL from our download page today!  These changes are also included in the KSDK 2.0.

TLS 1.3 is now available

wolfSSL has added AFL to its Testing Suite

wolfSSL is glad to announce that it is incorporating American Fuzzy Lop (AFL) into its testing suite.

Improving security is the at the heart of what wolfSSL is about. That is why wolfSSL has decided to include the AFL fuzzer to its list of tools. Finding bugs first locally allows our teams to make improvements to our libraries helping to eliminate vulnerabilities before they are released in our stable product releases.

Why choose AFL?

AFL is fast and efficient and here at wolfSSL we preach the importance of speed and efficiency. There is also an impressive “trophy case” of bugs found on the AFL home page here. Among the programs listed in the trophy case are several SSL/TLS libraries proving that this fuzzer works for encrypted communications. Finally, AFL is open source like wolfSSL allowing the freedom to look under the hood.

Where we Stand now and our Plans for the Future.

Currently we have 26 individual API tests that cover some of the most common function calls in the wolfSSL library. These tests will be ran daily and if anything of interest is found our teams will be notified right away. We plan to increase the number of tests run as our team determines which API stands to benefit from fuzz testing the most. Our teams are excited to see what AFL can find in the upcoming months as they work alongside it to bring you one of the best TLS/SSL libraries available.

american fuzzy lop (AFL)
wolfSSL SSL/TLS library

Upcoming in wolfSSH v1.2.0

wolfSSH v1.2.0 is currently a work in process. We have just added support for Elliptic Curve algorithms and AES-GCM. The following key exchange and public key algorithms are now available:

• ecdh-sha2-nistp256
• ecdh-sha2-nistp384
• ecdh-sha2-nistp521
• ecdsa-sha2-nistp256
• ecdsa-sha2-nistp384
• ecdsa-sha2-nistp521

The new encryption algorithm that is available is “aes128-gcm@openssh.com”, which is an implementation of RFC 5647, using the MAC algorithm implied with using the AEAD algorithm AES-GCM.

We look forward to bigger and better additions to wolfSSH in the near future, allowing a richer SSH experience in the IoT. Please see our wolfSSH page for more information and check out a download of wolfSSL.

Using wolfSSL on the Atmel ATECC508A with TLS 1.3 (#TLS13)

As previously announced, the wolfSSL embedded SSL/TLS library and wolfCrypt embedded crypto engine support the Atmel ATECC508A crypto element.  This allows wolfSSL to take advantage of the ECC hardware acceleration and protected private key storage on the ATECC508A.

Using wolfSSL, ATECC508A users can benefit from both increased ECC performance and secure key storage, thus hardening their TLS connections. Now that wolfSSL supports TLS 1.3, users also have the ability to use this new protocol version for even better performance for TLS connections!

The wolfCrypt ATECC508A port adds the following (and more!) when used with TLS 1.3:

+ wolfCrypt support for ECC hardware acceleration using the ATECC508A.  The defines for this port are WOLFSSL_ATMEL and WOLFSSL_ATECC508A
+ Public key callback for Pre Master Secret
+ Reduced quantity of round trips for performing a full handshake
+ A repurposed ticketing system allows for servers to be stateless

For more complete details please visit the wolfSSL Atmel webpage.  The code can be downloaded directly from wolfSSL’s “More Downloads” page, with the title “Atmel_ATECC508_Demos.zip”.

For more complete details on TLS 1.3, please visit https://tools.ietf.org/html/draft-ietf-tls-tls13-18. For more complete details for on how wolfSSL supports TLS 1.3, please visit https://www.wolfssl.com/docs/tls13/.

wolfSSL is dual licensed under both the GPLv2 as well as a standard commercial license.  For licensing information, please see the wolfSSL License Page, or contact us facts@wolfssl.com or call us at (425) 245-8247

TLS 1.3 is now available

wolfSSL with Intel SGX and TLS 1.3 (#TLS13)

As we announced last month, wolfSSL now includes a port for Intel® SGX (Software Guard Extensions) with Linux (specifically, Ubuntu 16.04). Using wolfSSL with SGX Linux takes advantage of Intel® SGX technology to separate untrusted and trusted code, isolating the wolfSSL library from potentially malicious applications running on the host machine.

Curious about using wolfSSL’s TLS 1.3 functionality in a secure enclave with SGX? After checking out the example application below, check out wolfSSL’s TLS 1.3 support page. It details building wolfSSL with TLS 1.3, as well as executing the examples specifically with TLS 1.3.

You can try out wolfSSL for Intel® SGX yourself with the port at wolfssl-root/IDE/LINUX-SGX which covers building a static library for linking with other SGX Enclaves.

wolfSSL also has an example Enclave and Application that demonstrate how to use wolfSSL SGX. The sample application covers:

1.  wolfCrypt API Testsuite
2.  wolfCrypt Benchmarks
3.  Simple TLS Client Example with client and server authentication

The example can be found at https://github.com/wolfssl/wolfssl-examples/tree/master/SGX_Linux.

For more information about Intel SGX see the sites below.
https://en.wikipedia.org/wiki/Software_Guard_Extensions
https://software.intel.com/en-us/sgx
https://software.intel.com/sites/default/files/managed/77/98/IntelSGX-infoQ-SolutionBrief.pdf?utm_source=InfoQ&utm_campaign=InfoQSGXGTM&utm_medium=AssetPDF

For more information about wolfSSL TLS 1.3 see the sites below.
https://en.wikipedia.org/wiki/Transport_Layer_Security#TLS_1.3_.28draft.29
https://www.wolfssl.com/docs/tls13/

If you have a need for an embedded SSL/TLS library with Intel® SGX contact us today at facts@wolfssl.com.

TLS 1.3 is now available

wolfSSL and OSS-Fuzz

Recently, Google announced OSS-Fuzz with the aim of making “common open source software more secure and stable by combining modern fuzzing techniques and scalable distributed execution.” And when they said that they would like to see us at OSS-Fuzz, we were interested.

You can read up on OSS-Fuzz at their official Github page, but to summarize the whole thing, it is at it’s core an entry point to Google’s expansive ClusterFuzz system. ClusterFuzz itself is an impressive network of virtual machines utilized originally for fuzz testing the Chrome project, but since opened up to other security software.

On our end, we expect to see a massive increase in our capability to test the wolfSSL library. Any bug found will be disclosed to wolfSSL, then giving us 90 days to release a patch for it before Google discloses its existence to the world.

On your end, you will have access to bugs that are found by this service. It also acts as a mechanism to hold us accountable. Once ClusterFuzz finds and logs a vulnerability, that vulnerability will be made public whether we fix it or not. This, of course, just keeps the pressure on us to keep wolfSSL as secure as possible.

Currently, the plan is to continue our own internal fuzzing projects, and test the waters over at OSS-Fuzz to see just how valuable we end up finding the service. If we like the results that we end up getting, we plan to increase the amount of fuzzing we do through OSS-Fuzz.

Posts navigation

1 2