RECENT BLOG NEWS

OpenSSL released a security advisory on May 3rd 2016: https://www.openssl.org/news/secadv/20160503.txt. Some wolfSSL embedded TLS users are probably wondering if similar security fixes are needed in wolfSSL.  The answer to that is no.  Specifically, CVE-2016-2107 and CVE-2016-2108 are OpenSSL implementation bugs.  Since wolfSSL and CyaSSL embedded SSL libraries have a completely different code base from OpenSSL we do not share these defects.

Please contact wolfSSL by email at facts@wolfssl.com, or call us at 425 245 8247 if you have any security related questions.

wolfSSL is happy to announce that the wolfSSL embedded SSL/TLS and wolfCrypt cryptography libraries have been ported to the uTasker operating system!

uTasker is an operating system, stack, and collection of services designed for embedded devices.  It includes an OS, filesystem, device drivers, and TCP/IP stack among other features.  The uTasker package includes a device simulator, allowing developers to test and debug code faster than would be possible on physical hardware itself.  Complete details on the uTasker stack can be found on the project website: http://www.utasker.com/.

wolfSSL has added a new preprocessor define to enable the uTasker port layer called WOLFSSL_UTASKER.  The port currently includes example client and server uTasker tasks which make use of the wolfSSL I/O abstraction layer to send and receive data over a secure SSL/TLS connection using uTasker RAW sockets.  The example tasks have been tested using the uTasker device simulator contained in the “uTasker_M522XX_V1.4-6” distribution.

What this means for projects using uTasker is that network connections can now communicate securely over SSL/TLS, using the progressive and lightweight wolfSSL SSL/TLS library.  Applications can also take advantage of the underlying wolfCrypt cryptography library to access crypto operations directly (block ciphers, stream ciphers, AEAD ciphers, hash functions, public key algorithms, and certificate verification routines).

The wolfSSL uTasker example client and server task are located in the ‘wolfssl-examples’ GitHub repository, linked below.  Documentation for these examples and on using wolfSSL with uTasker can be found on the wolfSSL website:

Using wolfSSL with uTasker
wolfSSL uTasker Examples

If you are interested in using wolfSSL on a uTasker-based project, feel free to reach out to us at facts@wolfssl.com with any questions.

wolfSSL has a new C# wrapper, allowing use of the wolfSSL embedded SSL/TLS library in a C# project. This will let users take advantage of the low footprint size of wolfSSL in IoT spaces that use the .NET framework. A Visual Studio project, along with server examples can be found in the directory “/wrapper/CSharp/”.

The wolfSSL C# wrapper is included in versions of wolfSSL beginning with 3.8.0. To download wolfSSL, visit the download page. More information about the wrapper and documentation can be found at the following links:

wolfSSL C# Wrapper
wolfSSL C# Manual
wolfSSL C# API Reference

For more info about using C# with wolfSSL, contact us at facts@wolfssl.com.

The wolfSSL embedded SSL/TLS library has added the option for using ECDHE-PSK cipher suites. This opens up using the small memory size ECC keys with PSK on embedded devices.

PSK (pre shared keys) is a viable option when controlling both ends of the connection. It allows for saving memory and computation time when performing a TLS handshake. Adding ECDHE gives the cipher suite perfect forward secrecy with using an ephemeral ECC key during the TLS handshake. Previously wolfSSL had DHE-PSK cipher suites but using ECDHE-PSK cipher suites will save even more memory, beneficial in resource-constrained, IoT devices.

The ECDHE-PSK cipher suites available to users include:

ECDHE-PSK-NULL-SHA256
ECDHE-PSK-AES128-CBC-SHA256
ECDHE-PSK-CHACHA20-POLY1305

wolfSSL has laid the groundwork for a portable command line utility. We wanted our community to be aware so you have the opportunity to begin using it with the wolfSSL embedded SSL/TLS library!

wolfCLU currently has the following features:

– Autoconf for portability
– Encrypt a file and store it locally on your computer
– Decrypt that file after it has been encrypted, or send it via email to your friend, if he/she knows the password and algorithm used for encryption, they can then decrypt it on their computer
– Hash a single file (IE a zip archive) for verification
– Benchmark the currently configured Algorithms

On the wolfCLU to-do-list:

– X509 Certificate generation
– X509 Certificate pem-to-der/der-to-pem
– FIPS certified build option
– Integration into wolfSSL distribution

Location:
https://github.com/wolfSSL/wolfssl-examples/tree/master/wolfCLU

Please head on over and check out the README!
https://github.com/wolfSSL/wolfssl-examples/blob/master/wolfCLU/README.md

wolfSSL has partnered with Atmel to provide users of the wolfSSL embedded SSL/TLS library the ability to take advantage of the Atmel ATECC508A crypto element. From the Atmel page:

“Due to lack of better alternatives, TLS implementations have historically stored private keys and authentication credentials in software where they are more vulnerable to attack. In addition, the mathematics used for authentication and asymmetric key agreement were also done in software which is less feasible in small IoT devices that have limited code space and processing power.

The Atmel Hardware-TLS platform provides an interface between software TLS packages and the ATECC508A cryptographic co-processor. wolfSSL and OpenSSL implementations can now utilize hardware-based secure storage for private keys and authentication data and also allow resource-constrained IoT nodes to implement full elliptic curve authentication and Diffie-Hellman key agreement and session key derivation. With Atmel HW-TLS, TLS communications links can have hardened security even out to the smallest IoT edge node.”

Full details can be found on the Atmel website:
http://www.atmel.com/tools/Atmel-HW-TLS.aspx

Contact us at facts@wolfssl.com with any questions or to inquire about using wolfSSL on the Atmel ATECC508A.

A new release of wolfSSL is now available. Version 3.9.0 of the industry leading embedded SSL/TLS library has a number of additions, updates, and fixes. With the addition of ports to both Arduino boards and to the Nordic nRF51 board wolfSSL is adding to its ever increasing IoT use. This release version also has an update to the progressive ChaCha20-Poly1305 cipher suites, allowing for use with PSK and increased interoperability.

There is no high level, urgent, fixes but we always suggest keeping up to date with the most current version of wolfSSL. By default FP_ECC is turned off, but users who have manually enabled this feature should update to wolfSSL 3.9.0 for the fix of a zero hash bug.

– Add new leantls configuration
– Add RSA OAEP padding at wolfCrypt level
– Add Arduino port and example client
– Add fixed point DH operation
– Add CUSTOM_RAND_GENRATE_SEED_OS and CUSTOM_RAND_GENERATE_BLOCK
– Add ECDHE-PSK cipher suites
– Add PSK ChaCha20-Poly1305 cipher suites
– Add option for fail on no peer cert except PSK suites
– Add port for Nordic nRF51
– Add additional ECC NIST test vectors for 256, 384 and 521
– Add more granular ECC, Ed25519/Curve25519 and AES configs
– Update to ChaCha20-Poly1305
– Update support for Freescale KSDK 1.3.0
– Update DER buffer handling code, refactoring and reducing memory
– Fix to AESNI 192 bit key expansion
– Fix to C# wrapper character encoding
– Fix sequence number issue with DTLS epoch 0 messages
– Fix RNGA with K64 build
– Fix ASN.1 X509 V3 certificate policy extension parsing
– Fix potential free of uninitialized RSA key in asn.c
– Fix potential underflow when using ECC build with FP_ECC
– Fixes for warnings in Visual Studio 2015 build

For more information about wolfSSL contact us at facts@wolfssl.com

The recently-announced DROWN attack allows attackers to decrypt TLS sessions by taking advantage of servers that support SSLv2 and EXPORT cipher suites. SSL 2.0 was the first version of the SSL/TLS protocol standard released, and has been known to be insecure for many years now.

wolfSSL has never supported SSL 2.0 and has never had support for EXPORT grade cipher suites. As such, users of wolfSSL (formerly CyaSSL) are safe from DROWN.

Please contact us at facts@wolfssl.com if you have further concerns or questions.

References:
DROWN Attack
CVE-2016-0800

Hi! Please email us if you want to join our Free Early Warning list. We will put you on our list of people to tell when there is a breach or vulnerability. Email us at facts@wolfssl.com with the subject Free Early Warning in the subject, and we’ll add you to the list.

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.

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