Sensors Expo 2017

You are invited to join wolfSSL at the 2017 Sensors Expo. The only event 100% dedicated to sensors and sensing technologies, taking place June 27-29 at the McEnery Convention Center in San Jose, California. Visit the link below www.sensorsexpo.com/ for more information.

If you would like to schedule a time in advance to meet with Rich Kelm or David Garske at the show, please contact rich@wolfssl.com or david@wolfssl.com, or stop by our booth #534. We will be talking about securing sensor data and projects with wolfSSL, wolfCrypt, wolfMQTT, and wolfSSH!

We look forward to seeing you at the show!

Transport-Level Security Tradeoffs using MQTT

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 (wolfSSHwolfCrypt), contact us at info@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

Announcing wolfSSH v1.1.0!

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.

Differences between TLS 1.2 and TLS 1.3

With the release of TLS 1.3, there are promises of enhanced security and speed. But how exactly do the changes from TLS 1.2 to TLS 1.3 cause these improvements? The following is a list of differences between TLS 1.2 and 1.3 that shows how the improvements are achieved.
 
wolfSSL is among one of the first libraries to support TLS 1.3. Below are the major differences between TLS 1.2 and TLS 1.3

TLS 1.3

This protocol was defined in an Internet Draft in April of 2017. 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.

• 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.
 
Internet Draft: https://tools.ietf.org/html/draft-ietf-tls-tls13-20
 
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 Announces Partnership with Infineon

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

wolfSSL with Intel SGX on Linux

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

The TLS v1.3 Advantage

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