Category: Uncategorized

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

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.

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

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.

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

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

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

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.

Fuzz testing is an important part of maintaining a secure code base here at wolfSSL. While we already have fuzzers in use ensuring that our library is as secure as possible, we recently decided to integrate 4 more fuzzers with our library to ensure that no potential bugs go undetected. This is one of many reasons that wolfSSL remains the best choice for an SSL/TLS library.
 
One of the new fuzzers being implemented into our system is the tlsfuzzer. This fuzzer was developed by Hubert Kario at Red Hat and was written purely in Python. Kario has developed over 60 unique scripts within the tlsfuzzer that run against the server of a given SSL/TLS library. These scripts attempt to find bugs and flaws in the system being tested against. After making a few slight modifications to our server, the tlsfuzzer scripts are now able to run against our server and provide us with detailed performance reports. The tlsfuzzer is an open source project available on Github.
 
Once the tlsfuzzer was successfully implemented with our system, we tested our server against each script and compared these results to other SSL/TLS libraries. Using these results, we know exactly where to make improvements and how to proceed with their implementations. We are excited to be taking further steps in improving the security of our library.
 
For further details regarding our process of testing the wolfSSL library to ensure code quality and security, please reference this blog page.

By Todd Ouska, wolfSSL

The Message Queuing Telemetry Transport protocol, or MQTT, has become a favorite of Internet of Things (IoT) developers, and why not? It’s incredibly lightweight (on the order of a couple Kb for client implementations), has easy-to-use APIs, and is available for free under the Eclipse Public License (EPL). If your connected application is something simple and relatively contained – like remote monitoring the temperature in your living room, for example – that much is probably enough to make you happy.

But what if your application is a little more complex? Say you’re combining multiple sensors, an HVAC system, a little intelligence, and MQTT to automatically adjust the climate in your home based on occupancy, and you’ve also configured remote management into the application so you can manually override instances where your dog tripped the infrared proximity sensor (sorry, Spot). Or maybe after some hard work you’re deploying a similar commercial system and need to update a sensor platform’s firmware to provide more precise measurements. So at what point is “enough” good enough? The answer depends on you and your application.

MQTT is a publish/subscribe protocol, meaning that would-be “clients” in the traditional networking model can act as both publishers of and subscribers to messages related to particular topics. Messages are distributed using the transmission control protocol (TCP), but rather than being indiscriminately broadcast, clients send messages through a central MQTT broker that accepts messages from a publisher and distributes them to the subscriber(s) to that topic at varying quality of service (QoS) levels.

However, in order to keep the protocol as lightweight as possible for resource-constrained IoT edge devices, the MQTT specification offers nothing on top of TCP for security outside of a recommendation that the transport layer security (TLS) protocol be used for applications that require additional levels of authentication. As a result, MQTT communications that rely on TCP alone are unencrypted and susceptible to man-in-the-middle attacks.

To illustrate what this means in more detail, let’s go back to our two “complex” examples from earlier. Say a proximity sensing platform publishes a message to the MQTT broker with the topic “home/occupancy.” The MQTT protocol does allow the use of a username and password for client identification, but these are displayed in text if some form of encryption isn’t used. Therefore, an eavesdropper could potentially impersonate a client subscriber and decrypt a message payload, or even imitate a client publisher and issue fake or modified messages. In terms of the personal home application this could signal to prospective thieves that no one is home, and in the commercial deployment scenario has serious implications on processes like remote firmware updates.

TLS tradeoffs

As mentioned, the MQTT protocol does recommend the use of TLS for more sensitive MQTT implementations, and a network port (port 8883) has even been reserved for this purpose. TLS is the successor of the secure sockets layer (SSL) protocol, and provides an encrypted communication channel over which MQTT messages can be sent. Before the channel is established TLS uses a handshake to pass certificates (or keys) from the publisher to the broker, but also between the broker and subscribers. If successful a secure channel is established, if not, the connection is aborted. Easy enough, right?

Well, maybe not. The downside of using TLS, SSL, and other methods of encryption is that they can add significant overhead, which is probably why you chose to use MQTT in the first place. For example, at wolfSSL we recently released an MQTT client library (wolfMQTT) with a compiled size of 3.6 kB. A TLS handshake alone can consume that much, without accounting for the encryption overhead on the individual packets themselves. For certain resource-constrained embedded devices, particularly those based on small microcontrollers, this added workload can simply consume too much in terms of CPU resources.

Techniques such as session resumption can compensate for some of the connection costs of TLS, and hardware acceleration is also a method for reducing the size penalty for encryption. Another important consideration is selecting an optimized encryption library when securing system communications, and in the case of wolfMQTT, integrating the lightweight wolfSSLembedded SSL/TLS library resulted in a compiled size of 20-30 kB when paired with hardware acceleration.

In the end, the decision when and how to implement security in your MQTT-based IoT system depends on you and your application. If you decide to move forward with transport-layer encryption, some best practices include working with MQTT libraries that are open source and allow you to look under the hood, but also provide documentation and examples of how encryption could be implemented in your application. If you’re a commercial entity using MQTT, make sure to partner with a vendor that has security credentials and also supports the widest range of operating systems and embedded chipsets possible in order to avoid lock-in.

For more, check out our secure firmware update example written in C that demonstrates encrypted communications to and from an MQTT broker using TLS.

For more information about wolfSSL and wolfMQTT, or about some of our other products (wolfSSH, wolfCrypt), contact us at facts@wolfssl.com

Todd Ouska is Co-Founder and CTO of wolfSSL.

wolfSSL

www.wolfssl.com

@wolfSSL

LinkedIn: www.linkedin.com/company/wolfssl

Facebook: www.facebook.com/wolfssl