RECENT BLOG NEWS

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 (wolfSSH, wolfCrypt), contact us at facts@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

1. You want TLS 1.3 support for connections.
2. You want to avoid the steady stream of security updates required by using OpenSSL.
3. You are concerned about the effect of quantum computers on security and want to use quantum safe crypto.
4. You are performance driven, and want to leverage the latest performance enhancements and hardware crypto support.
5. You want direct support for the crypto you use in MySQL or MariaDB.
6. You need FIPS 140-2 support for your MySQL install.

You can check out the patch here. If you have questions or need support, then give us a call at +1 425 245 8247 or email us at facts@wolfssl.com.

wolfSSL 3.13.0 is now available for download! wolfSSL 3.13.0 includes bug fixes and new features, including support for TLS 1.3 Draft 21, performance and footprint optimizations, build fixes, updated examples and project files, and one vulnerability fix.

Continue reading below for a summary of the features and fixes included in this release!

Protocol Changes:

* Fixes for TLS 1.3, support for Draft 21
* TLS 1.0 disabled by default, addition of “–enable-tls10” configure option

Performance and Size Optimizations:

* New option to reduce SHA-256 code size at expense of performance (USE_SLOW_SHA256)
* New option for memory reduced build (–enable-lowresource)
* AES-GCM performance improvements on AVX1 (IvyBridge) and AVX2
* SHA-256 and SHA-512 performance improvements using AVX1/2 ASM
* SHA-3 size and performance optimizations
* Fixes for Intel AVX2 builds on Mac/OSX
* Intel assembly for Curve25519, and Ed25519 performance optimizations
* Allow adjusting static I/O buffer size with WOLFMEM_IO_SZ

Build Option Updates:

* New option to force 32-bit mode with “–enable-32bit”
* New option to disable all inline assembly with “–disable-asm”
* Ability to override maximum signature algorithms using WOLFSSL_MAX_SIGALGO
* Removes 3DES and SHA1 dependencies from PKCS#7
* Adds ability to disable PKCS#7 EncryptedData type (NO_PKCS7_ENCRYPTED_DATA)

Feature Additions:

* Add ability to get client-side SNI
* Expanded OpenSSL compatibility layer
* Adds static memory support to the wolfSSL example client
* Adds option to wolfCrypt benchmark to benchmark individual algorithms
* Adds option to wolfCrypt benchmark to display benchmarks in powers of 10 (-base10)

Updated Project Files:

* Updated Visual Studio for ARM builds (for ECC supported curves and SHA-384)
* Updated Texas Instruments TI-RTOS build
* Updated STM32 CubeMX build with fixes for SHA
* Updated IAR EWARM project files
* Updated Apple Xcode projects with the addition of a benchmark example project

Build and Feature Fixes:

* Fixes for handling of unsupported TLS extensions.
* Fixes for compiling AES-GCM code with GCC 4.8.*
* Fixes for building without a filesystem
* Fix for logging file names with OpenSSL compatibility layer enabled, with
WOLFSSL_MAX_ERROR_SZ user-overridable
* Fixes for sniffer to use TLS 1.2 client method

Vulnerability Fix:

This release of wolfSSL fixes 1 security vulnerability.

wolfSSL is cited in the recent ROBOT Attack by Böck, Somorovsky, and Young. The paper notes that wolfSSL only gives a weak oracle without a practical attack but this is still a flaw. This release contains a fix for this report. Please note that wolfSSL has static RSA cipher suites disabled by default as of version 3.6.6 because of the lack of perfect forward secrecy. Only users who have explicitly enabled static RSA cipher suites with WOLFSSL_STATIC_RSA and use those suites on a host are affected. More information will be available on our website at:

https://wolfssl.com/wolfSSL/security/vulnerabilities.php

For additional documentation, please visit our Docs page, or contact us at facts@wolfssl.com.

wolfSSL now supports Xilinx SoCs and FPGAs. The wolfSSL embedded SSL/TLS library can be used with FPGAs which use the MicroBlaze CPU and/or Zynq and Zynq UltraScale+ SoCs. Improved performance speeds with using the hardware crpyto can be seen. Increasing AES-GCM, RSA, and SHA3 operations performance. In addition to the performance gained a user also gets the additional security the hardware provides while executing the algorithms.

For more information contact facts@wolfssl.com

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

wolfSSL is cited in the recent ROBOT Attack by Böck, Somorovsky, and Young.  The paper notes that wolfSSL only gives a weak oracle without a practical attack but this is still a flaw.  We’ve posted a fix for this and a general release will be available next week.  Please note that wolfSSL has disabled static RSA cipher suites by default as of version 3.6.6 because of the lack of perfect forward secrecy.  Only users who have explicitly enabled static RSA cipher suites with WOLFSSL_STATIC_RSA and use those suites on a host are affected.

Contact support@wolfssl.com if you have any questions or concerns.

We decided to benchmark our wolfCrypt/wolfSSL libraries on Apple’s new A11 processor in their latest iPhone 8 / 8 Plus and iPhone X. This processor features six ARMv8 CPU cores (2 high-performance 2.53GHz and 4 high-efficiency 1.42GHz). The benchmarks use wolfSSL’s latest speedups for ARMv8 crypto extensions and single precision math to demonstrate our exceptional performance.

For symmetric AES and SHA using our ARMv8 crypto assembly speedups we see:

AES-128 CBC Encrypt: 912.347 MB/s (36.58X)
AES-128 CBC Decrypt: 6,084.83 MB/s (256.15X)
AES-128 GCM Encrypt: 1,242.28 MB/s (193.65X)
AES-128 GCM Decrypt: 575.83 MB/s (90.26X)
SHA-256: 1,717.28 MB/s (56.11X)

This feature is enabled using `./configure –enable-armasm` or the `WOLFSSL_ARMASM` define.

For asymmetric RSA, DH and ECC using our single precision math speedups we see:

RSA 2048 public: 1,211.27 ops/sec (1.50X)
RSA 2048 private: 32.59 ops/sec (1.18X)
DH 2048 key gen: 77.44 ops/sec (1.24X)
DH 2048 key agree: 77.45 ops/sec (1.29X)
ECC 256 key gen: 1670.65 ops/sec (8.67X)
ECDHE 256 agree: 396.88 ops/sec (2.05X)
ECDSA 256 sign: 1,212.33 ops/sec (6.42X)
ECDSA 256 verify: 331.02 ops/sec (2.38X)

This feature is enabled using `./configure –enable-sp` or the `WOLFSSL_HAVE_SP_RSA`, `WOLFSSL_HAVE_SP_DH` and `WOLFSSL_HAVE_SP_ECC` defines.

For TLS v1.2 we see the following performance benchmarks by cipher suite:

DHE-RSA-AES128-SHA256: CPS 22.5, Read 388 MB/s, Write 106 MB/s
ECDHE-RSA-AES128-GCM-SHA256: CPS 26.2, Read 598 MB/s RX, Write 125 MB/s
ECDHE-ECDSA-AES128-GCM-SHA256: CPS 83.4, Read 504.8 MB/s, Write 92.2 MB/s

Benchmarks done on iPhone X using a single thread and our wolfCrypt and wolfSSL benchmark tools.
`X`= performance increase as compared to our default software based implementation.
`CPS` = Connections per second

You can download the raw benchmark numbers here:
https://www.wolfssl.com/files/benchmarks/iOSiPhoneXA11Benchmarks.pdf

You can find the Xcode iOS benchmark project used here:
https://github.com/wolfSSL/wolfssl/pull/1257
Or in the wolfSSL repository in `IDE/XCODE/Benchmarks`

For questions please email us at facts@wolfssl.com.

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

wolfMQTT v0.14 has been released (11/22/17) and includes fixes for non-blocking operation, improved error handling with TLS, fixes for GCC 7 warnings and updates to the Visual Studio projects.

wolfSSL will be at the IoT Tech Expo (Nov 29-30, 2017) in Santa Clara at the convention center. If you are attending please visit our booth #196 and say hello. Our MQTT expert David Garske will be available to answer questions.

wolfMQTT v0.14 Release Notes:

• Fixed non-blocking connect to check for `EINPROGRESS` for all platforms (not just Harmony).
• Fixed buffer overflow position check on read/write.
• Fixed typo on internal packet function `MqttDecode_ConnectAck`.
• Fixed the socket close for Harmony to use `closesocket`.
• Fixed non-blocking connect where `WOLFMQTT_NO_STDIO` is defined.
• Fixed GCC 7’s new fall-through check.
• Added check for EAGAIN in non-blocking mode (was only EWOULDBLOCK).
• Added non-blocking support for write operations when `WOLFMQTT_NONBLOCK` is defined.
• Added support for DH and setting the default minimum key bits.
• Added support for keep-alive ping when using non-blocking mode.
• Improvements to example TLS callback handling of return code failures.
• Improvements and fixes to Visual Studio projects.
• Enhancement to adjust wolfSSL options.h include based on `WOLFSSL_USER_SETTINGS`.

You can download the latest release here: https://www.wolfssl.com/download/

wolfMQTT Product Page

For questions please email us at facts@wolfssl.com

The TLS v1.3 specification has been evolving over the year and is close to being finalized. Recently the code changes required to support Draft 21 were added to wolfSSL.

Most browsers and servers on the Internet are stuck on Draft 18. This maximizes interoperability and allows for collection of error rate statistics. wolfSSL is able to be compiled to support TLS v1.3 Draft 18 but also the latest draft version. The Draft 21 changes were quite minor but introduced one wire protocol change: a per-ticket nonce.

Resumption in TLS v1.3 is performed with session tickets. The ticket contains enough information to indicate to the server which session is being resumed. Most often the ticket contains self-encrypted session information. Alternatively, the ticket can be a reference into a session database that identifies the client.

Note that in previous drafts, on resumption, the Resumption Master Secret (RMS) from the original connection is used as the Pre-Shared Key (PSK). The PSK is used to derive the secrets for the new handshake. Therefore all handshakes resumed from the same ticket will have the same secrets unless (EC)DH is used.

Draft 21 adds a nonce to the NewSessionTicket message that is used, with the RMS, to securely derive a unique PSK for a resumption handshake. Multiple single-use resumption tickets can now be sent with the same database reference but a different nonce and be deleted on use. Each resumption ticket produces unique secrets and provides forward-secrecy protection if a PSK is compromised.

As noted above, there are not many other implementations of Draft 21 out there. Client and server interoperability testing with OpenSSL though was performed to ensure compatibility.

Most handshakes performed will be by resumption where possible as they are faster than a full handshake. Improving resumption security therefore is a big plus and makes using the latest updates of wolfSSL a must.

If you have any questions or issues with wolfSSL’s TLS 1.3 implementation, please email us at facts@wolfssl.com, or our support team at support@wolfssl.com.