Category: Uncategorized

TLS 1.3 has a different handshake flow when using pre-shared keys and this impacts performance. This is the third part of six blogs discussing the performance differences observed between TLS 1.2 and TLS 1.3 in wolfSSL and how to make the most of them in your applications. This blog discusses how and why PSK handshakes are only similar in speed generally but faster when using DH style key exchange.

For TLS 1.2, handshakes using PSK are defined in a separate document (RFC 4279). In order to fit in with the existing flow, a full handshake is performed. In TLS 1.3, PSK handshakes are the same as resumption handshakes. Therefore there is one less round-trip required for TLS 1.3.

This change in flow has a significant impact on the performance of TLS 1.3. The amount of hashing and encryption/decryption has increased but losing a round-trip means that using PSK without a DH style key exchange is only slightly slower. On higher latency networks, the difference is trivial and the savings great.

In TLS 1.3 using DH or ECDH with PSK results in the following handshake operations.

So, the secret is calculated on the server after the ServerHello is sent. This means that the processing of the ServerHello and secret calculation on the client is happening at the same time relative to the server calculating the secret. The parallel secret generation resulted in, with client and server running on the same computer, TLS 1.3 being about 25% faster than TLS 1.2 when using DH. Using ECDH with P-256, TLS 1.3 is about 15% faster.

It is clear that using pre-shared keys in a secure way, with DH style key exchange, is faster with TLS 1.3 in wolfSSL. The next blog will discuss use cases that result in the removal of a key generation from the list of expensive cryptographic operations in TLS 1.3.

Part 1 (TLS 1.3 Performance – Resumption)
Part 2 (TLS 1.3 Performance – Full Handshake)

For more information regarding wolfSSL performance or usage of PSK, please contact facts@wolfssl.com.

Significant changes from TLS 1.2 have been made in TLS 1.3 that are targeted at performance. This is the second part of six blogs discussing the performance differences observed between TLS 1.2 and TLS 1.3 in wolfSSL and how to make the most of them in your applications. This blog discusses the performance differences with regard to full handshake with server authentication using certificates.

Let’s start with a look at the TLS 1.2 full handshake performing server-only authentication with certificates below.

A TLS 1.3 full handshake (without HelloRetryRequest) performing server-only authentication with certificates is below.

Notice that there is one less round trip until Application Data can be sent in TLS 1.3 as compared to TLS 1.2. This significantly improves performance especially on high latency networks. But, there is another source of performance improvement arising from the ordering of the handshake messages and when lengthy cryptographic operations are performed.

In the TLS handshake, the server waits on the ClientHello and then sends handshake messages as it produces them in separate packets. When packets are sent is dependent on the amount of processing required to produce the data. For example, to copy a chain of certificates into the Certificate messages is quick, while generating a TLS 1.2 ServerKeyExchange message is slow as it requires multiple public key operations.

The client receives the messages at various time deltas and also requires differing amounts of processing. For example, the Certificate message is likely to require at least one signature verification operation on the leaf certificate. This asymmetric processing of messages means that some handshake messages will be processed on arrival and some will have to wait for processing of previous messages to be completed.

The table below restates the TLS 1.2 handshake but includes processing of messages and the major cryptographic operations that are performed. Operations are on the same line if the they are performed at the same time relative to network latency.

From this we can see that for RSA, where Verify is very fast relative to Sign, a TLS 1.2 handshake is dependent on: 2 x Key Gen, 2 x Secret Gen, 1 x Sign and 1 x Verify. For ECDSA, where Verify is slower than Key Gen plus Sign: 1 x Key Gen, 2 x Secret Gen and 2 x Verify.

The table below is a restating of the TLS 1.3 handshake including processing of message and the major cryptographic operations.

From this we can see that a TLS 1.3 handshake with RSA, where Verify is a lot faster than Sign, is dependent on: 2 x Key Gen, 1 x Secret Gen, 1 x Sign. Therefore, a Secret Gen and Verify in TLS 1.2 are saved. For ECDSA, where Verify is a lot slower than Sign, the TLS 1.3 handshake is dependent on: 2 x Key Gen, 1 x Secret Gen, 2 x Verify. Therefore, a Secret Gen in TLS 1.2 is traded for a faster Key Gen.

Running both the client and server on the same computer results in about a 15% improvement in the performance of ephemeral DH with RSA handshakes – mostly due to the parallel operations. With ephemeral ECDH and RSA there is about a 6% improvement, and with ECDHE and ECDSA there is about a 7% improvement – mostly due to the saving in round-trips.

These improvements come for free when using TLS 1.3 without the HelloRetryRequest. The next blog will discuss handshakes using pre-shared keys.

For more information regarding wolfSSL and the TLS 1.3 full handshake, please contact facts@wolfssl.com.

TLS 1.3 is the latest version of the SSL/TLS specification. There are significant changes to messages and the message flow. These changes are targeted at security and performance. This series of blogs will discuss the performance differences observed between TLS 1.2 and TLS 1.3 in wolfSSL and how to make the most of them in your applications. This is the first part of six blogs.

The first performance difference to note is a degradation. In TLS 1.2 performing a resumption handshake is very quick. This comes at a security cost though. Each time a client resumes a session, the same session ID is used and the same master secret is used. Therefore, if the master secret is compromised then all resumed sessions are revealed. Also, TLS 1.2 resumption is stateful and can have performance issues in a multi-server architecture.

TLS 1.3 only uses session tickets to resume a session. This mechanism has the client send an opaque session ticket to the server that contains a server encrypted version of all the information required to resume the session. Once again the same master secret is used across handshakes but the default behavior is to perform a key exchange. A unique, shared secret is generated and combined with the master secret when calculating keys and IVs. This mechanism then provides forward secrecy.

The performance trade-off here is that using a session ticket requires decryption of the session ticket. Also, TLS 1.3 performs more encryption/decryption and hashing operations in the handshake anyway. Therefore, when running a client and server on the same computer, a TLS 1.3 handshake is more than 20% slower. On a high latency network, these will not be noticeable as symmetric cipher and digest algorithms are the fastest of operations.

But also consider the default behaviour that results in a key exchange. DH key and secret generation are some of the most expensive operations and the handshake, again running both client and server on the same computer, using 2048-bit DH parameters can take 13 times as long as TLS 1.2 resumption. ECDH can be used instead and is at least twice as slow when using a highly optimised implementation.

There is no way in TLS 1.3 to avoid this performance degradation and resumption has the fastest handshake performance. Using optimised ECDH will give you the best performance and better security. There is a way to improve the resumption performance, in some cases, which will be discussed in a future blog in this series.

The next blog will discuss performance improvements in full handshakes performing server-only authentication.  Stay tuned!

For more information about wolfSSL and TLS 1.3 session ticket resumption, please contact facts@wolfssl.com.

wolfSSL recently gave a presentation on FIPS 140-2 validating wolfCrypt inside a secure enclave at ICMC18 (#CryptoModConf).  Thanks to all those who attended!  For reference, we have put our slide deck up on Slideshare for our users to flip through or reference.

Session Abstract:

“Secure enclaves are becoming a popular way to separate and protect sensitive code and data from other processes running on a system. A FIPS 140-2 validated cryptographic software module is currently required to run power-on self tests when loaded, but security of the module can be taken one step further by validating the module inside a secure enclave, such as Intel SGX.

wolfSSL has been working on FIPS 140-2 validating the wolfCrypt library running inside an Intel SGX enclave. This session will discuss the advantages, challenges, and process of FIPS 140-2 validating a cryptographic software module inside Intel SGX and how the same process could be applied to other secure enclave environments.”

Contact us at facts@wolfssl.com if you have any questions about doing a FIPS validation inside a TEE or secure enclave!

wolfSSL is pleased to announce the following addition to the wolfSSL FIPS certificate!

Debian 8.7.0	Intel ® Xeon® E3 Family with SGX support	Intel®x64 Server System R1304SP
Windows 10 Pro	Intel ® Core TM i5 with SGX support	Dell LatitudeTM 7480

The wolfCrypt FIPS validated cryptographic module has been validated while running inside an Intel SGX enclave and examples have been setup for both Linux and Windows environments.

Intel ® SGX (Software Guard Extensions) can be thought of as a black-box where no other application running on the same device can see inside regardless of privilege. From a security standpoint this means that even if a malicious actor were to gain complete control of a system including root privileges, that actor, no matter what they tried, would not be able to access data inside of this “black-box”.

An Intel enclave is a form of user-level Trusted Execution Environment (TEE) which can provide both storage and execution. Meaning one can store sensitive information inside and also move sensitive portions of a program or an entire application inside.

While testing, wolfSSL has placed both individual functions and entire applications inside the enclave. One of the wolfSSL examples shows a client inside the enclave with the only entry/exit points being “start_client”, “read”, and “write”. The client is pre-programmed with a peer to connect with and specific functionality. When “start_client” is invoked it connects to the peer using SSL/TLS and executes the pre-programmed tasks where the only data entering and leaving the enclave is the info being sent to and received from the peer. Other examples show placing a single cryptographic operation inside the enclave, passing in plain-text data and receiving back encrypted data masking execution of the cryptographic operations.

If you are working with SGX and need FIPS validated crypto running in an enclave contact us at fips@wolfssl.com or support@wolfssl.com with any questions. We would love the opportunity to field your questions and hear about your project!

Resources:
https://software.intel.com/en-us/blogs/2016/12/20/overview-of-an-intel-software-guard-extensions-enclave-life-cycle

We have created a new repository for hosting the FreeRTOS classic and Amazon FreeRTOS support for wolfSSL located here:
https://github.com/wolfSSL/wolfssl-freertos

There are two pull requests with support for wolfSSL including demos:

FreeRTOS Classic v10.0.1 with wolfSSL/wolfMQTT demos:
https://github.com/wolfSSL/wolfssl-freertos/pull/1

• Added a wolfMQTT FreeRTOS TCP demo. This demo connects to the iot.eclipse.org MQTT broker with TLS on port 8883. It sends a counter publish message every second.
• Updated wolfSSL demo:
• Project built and tested against latest v3.14.4 release.
• Switched to using user_settings.h (WOLFSSL_USER_SETTINGS).
• Updated the certs (expired Jan 31, 2018).
• Stop tracking the .filter project file.
• Add submodule for wolfMQTT v1.0 plus FreeRTOS TCP support.
• Replace wolfSSL sources with submodule wolfSSL v3.14.4 plus some Win VS fixes.
• Initial FreeRTOS v10.0.1

Amazon FreeRTOS v1.2.3 port to use wolfSSL:
https://github.com/wolfSSL/wolfssl-freertos/pull/2

• Port of the Amazon FreeRTOS v1.2.3 to use wolfSSL.
• Added a new solution and project for demo at FreeRTOS-AWS/demos/pc/windows/visual_studio/aws_demo_wolf.sln.
• Added wolfssl as submodule.

Did you know that the wolfSSL embedded SSL/TLS library supports ARMv8 as well as the Cryptography Extensions that it provides?  wolfSSL is more than 10 times faster with AES and SHA256 operations the ARMv8 board we have been testing on (HiKey LeMaker) when using hardware acceleration versus software crypto!

 

ARMv8 Benchmark Data comparing Software and Hardware Cryptography

Algorithm	Software Cryptography	Hardware Cryptography
RNG	16.761 MB/s	82.599 MB/s
AES-128-CBC-enc	26.491 MB/s	649.179 MB/s
AES-128-CBC-dec	26.915 MB/s	607.407 MB/s
AES-192-CBC-enc	22.796 MB/s	566.717 MB/s
AES-192-CBC-dec	23.130 MB/s	553.092 MB/s
AES-256-CBC-enc	20.004 MB/s	504.143 MB/s
AES-256-CBC-dec	20.207 MB/s	491.374 MB/s
AES-128-GCM-enc	6.224 MB/s	393.407 MB/s
AES-128-GCM-dec	6.226 MB/s	182.279 MB/s
AES-192-GCM-enc	5.895 MB/s	361.801 MB/s
AES-192-GCM-dec	5.895 MB/s	175.676 MB/s
AES-256-GCM-enc	5.609 MB/s	333.911 MB/s
AES-256-GCM-dec	5.610 MB/s	169.085 MB/s
CHACHA	60.510 MB/s	60.017 MB/s
CHA-POLY	41.805 MB/s	41.410 MB/s
MD5	156.310 MB/s	154.421 MB/s
POLY1305	144.464 MB/s	143.058 MB/s
SHA	89.874 MB/s	89.154 MB/s
SHA-256	38.805 MB/s	533.139 MB/s
HMAC-MD5	156.301 MB/s	154.083 MB/s
HMAC-SHA	89.859 MB/s	89.045 MB/s
HMAC-SHA256	38.814 MB/s	532.316 MB/s
RSA, 2048, public	171.995 Ops/s	171.355 Ops/s
RSA, 2048, private	13.716 Ops/s	13.686 Ops/s
DH, 2048, key generation	50.831 Ops/s	50.575 Ops/s
DH, 2048, agree	41.826 Ops/s	41.596 Ops/s

If you are interested in using wolfSSL on an ARMv8 platform and want some tips on getting started for optimal performance, contact us at facts@wolfssl.com!  wolfSSL now includes support for TLS 1.3 as well!

Our wolfMQTT project includes an example for secure firmware update. This example uses the wolfSSL embedded SSL/TLS library to hash/sign the binary image and send it over MQTT. The example has two applications. One is called fwpush, which hashes, signs and publishes the firmware image over TLS to an MQTT broker. The second is called fwclient, which subscribes to the example firmware update topic, receives the firmware image and validates the signature of it. This example is located in examples/firmware.

The latest wolfMQTT releases can be downloaded at:
https://wolfssl.com/download

Documentation for wolfMQTT can be found here:
https://www.wolfssl.com/docs/wolfmqtt-manual/

The latest source code can be found on our GitHub repo at:
https://github.com/wolfSSL/wolfMQTT

For questions please contact support at support@wolfssl.com.

At wolfSSL our favorite way to stay up-to-date on everything IoT is by subscribing to Stacey Higginbotham’s weekly newsletter that explains the latest in IoT. You can sign up for the newsletter at https://staceyoniot.com/newsletter/. If you like podcasts, check out her podcast at IoTPodcast.com.

We’ve advertised in the newsletter a couple of times and it’s a good way to reach an audience of people making connected products and services. You can learn more about advertising at https://staceyoniot.com/advertise/