wolfMQTT support for MQTT v5.0

We are working on adding MQTT v5.0 support to wolfMQTT.

Some of the new MQTT 5 features include:

  • AUTH packet type to submit authentication method/data information after connect.
  • CONNACK packets now include a reason code to better describe connect failures.
  • DISCONNECT now supports server to client.
  • Packets can include optional key/value properties.
  • New data type for UTF-8 string pairs.
  • No retry for QoS 1 and 2 packets (let assumed TCP handle retry).
  • Passwords can be provided without a username

The new specification can be found here:
http://docs.oasis-open.org/mqtt/mqtt/v5.0/mqtt-v5.0.html

Support for these new features will be release in the next few weeks as wolfMQTT v1.0.

Top 5 TLS 1.3 Advantages with wolfSSL

We’re excited that wolfSSL embedded SSL/TLS library now includes support for TLS 1.3 and think that there are many advantages to using TLS 1.3 in applications, projects and devices.  Here are the top 5 advantages to using TLS 1.3 with wolfSSL:

  1. More secure than older TLS protocol versions by eliminating risky crypto
  2. Reduces latency through fewer roundtrips in the TLS handshake
  3. The server can be stateless when resuming a session
  4. We are the first and only commercial license supplier of TLS 1.3 library for embedded devices today
  5. We are the only company to support its own TLS 1.3 stack

If you would like to talk in more detail about using TLS 1.3, contact us at info@wolfssl.com!

wolfCrypt v4.0 is on the CMVP Implementation Under-Test List

We are excited to announce that wolfCrypt v4.0 is currently in process for CMVP validation for FIPS 140-2. We are adding more algorithms to our security boundary including ECDSA, ECDHE, AES-GCM, AES-CCM, SHA-3, and RSA-PSS. Also included is FIPS 186-4 compliant key generation for RSA and ECC. We will be able to offer TLSv1.3 with FIPS validated cryptography for embedded devices. For more information, please email fips@wolfssl.com.

wolfSSL at Docker Hub

We at wolfSSL are pleased to announce that now you can use wolfSSL directly from Docker!

In a few words, Docker is a tool designed to make it easier to create, deploy, and run applications by using containers. Containers are like virtual machines, but way more lighter as the container shares some resources with the hosting machine.

We created a collection of wolfSSL containers targeting the following OSs: Debian, Ubuntu, Alpine Linux, CentOS

There are 3 different flavors of containers we have created based on each OS, they are: lib, test and examples

wolfssl/wolfssl ubuntu-examples 9198e6d82596 127MB
wolfssl/wolfssl ubuntu-test     ba5ca8ca4359 351MB
wolfssl/wolfssl ubuntu-lib      125125eea7ab 126MB
ubuntu          latest          2d696327ab2e 122MB
wolfssl/wolfssl debian-examples cd066ee3b5db 106MB
wolfssl/wolfssl debian-test     5a3edb3a2a20 356MB
wolfssl/wolfssl debian-lib      3086ef0f07b6 105MB
debian          latest          72ef1cf971d1 100MB
wolfssl/wolfssl centos-examples 37687e96d5b9 222MB
wolfssl/wolfssl centos-test     359d4195ca53 392MB
wolfssl/wolfssl centos-lib      a8c6cafd6205 221MB
centos          latest          196e0ce0c9fb 197MB
wolfssl/wolfssl alpine-examples 490120f86d61 8.74MB
wolfssl/wolfssl alpine-test     52b698631bec 228MB
wolfssl/wolfssl alpine-lib      692a0c26cda6 7.97MB
alpine          latest          76da55c8019d 3.97MB

The -lib images contains only the wolfSSL binaries, while -examples also contains the test examples and -test also contains wolfSSL’s source code.

You can find further information on how to run wolfSSL examples on a docker container in our docker hub page: https://hub.docker.com/u/wolfssl/

And here is a quick example, server in the left tab and the client in the right tab:

Job Posting: Embedded Systems Software Engineer

wolfSSL is a growing company looking to add a top notch embedded systems software engineer to our organization. wolfSSL develops, markets and sells the leading Open Source embedded SSL/TLS protocol implementation, wolfSSL. Our users are primarily building devices or applications that need security. Other products include wolfCrypt embedded cryptography engine, wolfMQTT client library, and wolfSSH.

Job Description:

Currently, we are seeking to add a senior level C software engineer with 5-10 years experience interested in a fun company with tremendous upside. Backgrounds that are useful to our team include networking, security, and hardware optimizations. Assembly experience is a plus. Experience with encryption software is a plus. RTOS experience is a plus.  Experience with hardware-based cryptography is a plus.

Operating environments of particular interest to us include Linux, Windows, Embedded Linux and RTOS varieties (VxWorks, QNX, ThreadX, uC/OS, MQX, FreeRTOS, etc). Experience with mobile environments such as Android and iOS is also a plus, but not required.

Location is flexible. For the right candidate, we’re open to this individual working from virtually any location.

How To Apply

To apply or discuss, please send your resume and cover letter to info@wolfssl.com.

wolfSSL Signal Protocol C Library Support

Signal Protocol Logo

wolfSSL now supports Open Whisper Systems Signal Protocol C Library!  This means that you can now develop Signal applications using wolfCrypt as the underlying cryptography provider.

For those unfamiliar with the Signal Protocol, it is described on their GitHub page as “A ratcheting forward secrecy protocol that works in synchronous and asynchronous messaging environments.”

wolfCrypt Signal Protocol Integration

By design, the Signal Protocol C Library does not depend on any SSL/TLS or cryptography library.  Instead, Signal allows the application to register a crypto provider at runtime.  We recently ported the wolfCrypt cryptography library into the “libsignal-protocol-c” test code and added a CMake configuration to build the libsignal-protocol-c test programs using cryptography from wolfSSL.

With this build option and wolfCrypt integration, Signal application developers can choose to use cryptography from wolfSSL instead of OpenSSL.  Thanks to wolfSSL’s small footprint size, low memory usage, and broad platform support, application developers can more easily use the Signal Protocol C Library on small resource-constrained platforms and embedded systems.

For more information on using wolfCrypt with Signal, contact us at info@wolfssl.com!

Securing MySQL (#mysql) with wolfSSL SSL/TLS

MySQL logo             wolfSSL logo

MySQL (#mysql) currently comes bundled with yaSSL to provide an option for SSL/TLS connections when using a database. A patch for securing MySQL with the wolfSSL embedded SSL/TLS library is available for MySQL version 8.0.0 here https://github.com/wolfSSL/mysql-patch.

Along with an increased level of security comes the potential to use progressive features offered by wolfSSL – such as TLS 1.3 and ChaCha20 / Poly1305 AEAD cipher suites (ex: ECDHE-RSA-CHACHA20-POLY1305). Another great feature is that wolfSSL cryptography is FIPS 140-2 validated! The change from yaSSL to wolfSSL will fit nicely into both Open Source and commercial applications, as it is dual licensed under both GPLv2 and standard commercial license terms.

For more information about the port, or to provide us feedback, contact us at info@wolfssl.com!

wolfSSL is Expanding Our OpenSSL Compatibility Layer

Tired of using OpenSSL? Recently wolfSSL has been expanding our compatibility layer, which means that it soon will be even easier to replace OpenSSL with wolfSSL in existing projects. In some cases the replacement can be as easy as including <wolfssl/options.h> and linking to a wolfSSL library that has been compiled with –enable-opensslextra.

For more information about the wolfSSL or the compatibility layer contact us at info@wolfssl.com.

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 wolfSSL embedded 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: https://www.linkedin.com/company/wolfssl/

Facebook: www.facebook.com/wolfssl

Posts navigation

1 2