RECENT BLOG NEWS

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

wolfSSH v1.1.0 is now available for download. This release contains an update to use DH GEX with SHA-256 during the key exchange.

The wolfSSH server library is a lightweight implementation of the SSH v2 protocol suite for embedded servers. It is written in C from scratch. wolfSSH keeps a small footprint by using the wolfCrypt cryptography library. If you need FIPS 140-2, wolfCrypt has you covered.

wolfSSH is currently dual licensed. You may download from our website and use it for free, so long as you abide by the GPLv3 licensing terms. Commercial licensing terms are also available. Please contact our sales team for more information at sales@wolfssl.com.

wolfSSL’s embedded SSL/TLS library has included support for TLS 1.3 since early releases of the TLS 1.3 draft. Since then, wolfSSL has remained up-to-date with the TLS 1.3 specification. In this post, the major upgrades of TLS 1.3 from TLS 1.2 are outlined below:

TLS 1.3

This protocol is defined in RFC 8446. TLS 1.3 contains improved security and speed. The major differences include:

• The list of supported symmetric algorithms has been pruned of all legacy algorithms. The remaining algorithms all use Authenticated Encryption with Associated Data (AEAD) algorithms.
• A zero-RTT (0-RTT) mode was added, saving a round-trip at connection setup for some application data at the cost of certain security properties.
• Static RSA and Diffie-Hellman cipher suites have been removed; all public-key based key exchange mechanisms now provide forward secrecy.
• All handshake messages after the ServerHello are now encrypted.
• Key derivation functions have been re-designed, with the HMAC-based Extract-and-Expand Key Derivation Function (HKDF) being used as a primitive.
• The handshake state machine has been restructured to be more consistent and remove superfluous messages.
• ECC is now in the base spec  and includes new signature algorithms. Point format negotiation has been removed in favor of single point format for each curve.
• Compression, custom DHE groups, and DSA have been removed, RSA padding now uses PSS.
• TLS 1.2 version negotiation verification mechanism was deprecated in favor of a version list in an extension.
• Session resumption with and without server-side state and the PSK-based ciphersuites of earlier versions of TLS have been replaced by a single new PSK exchange.

More information about the TLS 1.3 protocol can be found here: https://www.wolfssl.com/docs/tls13/. Additionally, please contact facts@wolfssl.com for any questions.

Resources:

If you would like to read more about SSL or TLS, here are several resources that might be helpful:

TLS – Wikipedia (http://en.wikipedia.org/wiki/Transport_Layer_Security)
SSL versus TLS – What`s the Difference? (http://luxsci.com/blog/ssl-versus-tls-whats-the-difference.html)
Cisco – SSL: Foundation for Web Security (http://www.cisco.com/web/about/ac123/ac147/archived_issues/ipj_1-1/ssl.html)

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 the extra security afforded by running wolfSSL in a secure enclave with SGX? 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
 
If you have a need for an embedded SSL/TLS library with Intel® SGX contact us today at facts@wolfssl.com.

wolfSSL would like to announce to our community that we are now partnered with Infineon. This partnership should make it easier to get wolfSSL up and running on Infineon-based projects that need to be secured!

The wolfSSL embedded SSL/TLS library is a perfect fit for securing lightweight, resource-constrained devices. wolfSSL has a footprint size of 20-100kB, offers protocol support up to TLS 1.3 and DTLS 1.2, progressive algorithm support, hardware crypto support, and more.

Infineon designs, develops, manufactures and markets a broad range of semiconductors and system solutions. The focus of its activities is on automotive electronics, industrial electronics, mobile devices and chip card-based security. Combining entrepreneurial success with responsible action, Infineon addresses some of the most critical challenges of society: Efficient use of energy, environmentally-friendly mobility and security in a connected world.

https://www.infineon.com

Recently we announced availability of TLS v1.3 in wolfSSL. There are many benefits in changing to the newest version of the TLS specification.

One significant difference you will notice is the reduced number of round-trips when performing a full handshake. 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! Additionally, the server can send application data in response to the clients first handshake message! This means network latency has less impact on the time required to establish a secure connection.

Another difference is the way session resumption works in TLS v1.3. Previous versions of TLS have the client send a session id which the server has to lookup in its cache. If there was a match then they used the same security parameters. This is a very simplistic mechanism that requires sharing of state on servers.

TLS v1.3 has made significant improvements by re-purposing the ticketing system tacked onto older versions of TLS. The server sends the client a new session ticket after the handshake is complete. This ticket, a blob of data to the client, can be a database lookup key like the old session id. Alternatively, it can be a self-encrypted and self-authenticated value that contains the data for the previous connection. This means the server can be stateless!

Finally, the specification has been evaluated by cryptographic experts in efforts to prove the security of the protocol. While no security proof is perfect, the previous attacks on renegotiation, protocol version downgrading, compression, CBC and padding have been mitigated and the protocol is generally more resistant to attack.

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

We are considering adding support for the Mongoose Web Server.  If you are interested in using CyaSSL with Mongoose please let us know at info@yassl.com.