Month: May 2018

TLS 1.3 has some significant changes from TLS 1.2 in the ordering of handshake messages and this impacts performance. This is the fifth 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 the changes to certificate based client-server authentication in TLS 1.3 adversely affects performance.

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

A TLS 1.3 full handshake (without HelloRetryRequest) performing client and server authentication with certificates is given 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 improves performance on high latency networks but there is a downside. What is clear in the diagram is when messages are sent but not how and when handshake messages are processed.

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

The server produces a KeyShare, sends the ServerHello, and then quickly sends the EncryptedExtensions, CertificateRequest and Certificate messages. The CertificateVerify takes a while to produce and the Finished message is quick. The client takes a while to process the KeyShare, quickly process the EncryptedExtensions and CertificateRequest messages, and spends a long time performing certificate chain verification. The CertificateVerify will typically arrive during the chain verification and then the client processes the rest of the messages synchronously. As a result, there is little overlap.

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 2 x Verify. For ECDSA, where Verify is slower than Key Gen plus Sign: 1 x Secret Gen and 3 x Verify.

The table below restates 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 using RSA certificates is dependent on: 2 x Key Gen, 1 x Sercret Gen, 2 x Sign. Therefore a Secret Gen and 2 x Verify in TLS 1.2 are replaced with a Sign. Using ECDSA a handshake is dependent on: 2 x Key Gen, 1 x Sercret Gen and 4 x Verify. Therefore, a Secret Gen and Sign in TLS 1.2 is replaced by 2 x Verify.

This means that for low latency networks TLS 1.3 can be slightly slower or about as fast as TLS 1.2. The only practical mitigation for ECC certificates is to minimize the amount of work performed in chain verification. Having the server certificate stored on the client and/or the client certificate stored on the server will improve TLS 1.3 performance but at the risk of lower security.

The next blog will be the final one in this series and will discuss difference in throughput between TLS 1.2 and 1.3.

Part 1 (TLS 1.3 Performance – Resumption)
Part 2 (TLS 1.3 Performance – Full Handshake)
Part 3 (TLS 1.3 Performance – Pre-Shared Key (PSK))
Part 4 (TLS 1.3 Performance – Server Pre-Generation)

One of the services that wolfSSL provides is the wolfSSL Competitive Upgrade Program. With this program, wolfSSL offer competitive upgrade pricing for those who wish move from an outdated or expensive SSL/TLS library to wolfSSL with low cost and minimal disturbance to their code base.

Here’s an outline of the Competitive Upgrade Program:

1. You need to currently be using a commercial competitor to wolfSSL.
2. You will receive up to two weeks of on-site consulting to switch out your old SSL/TLS library with wolfSSL.  Travel expenses are not included.
3. Normally, two weeks is the right amount of time for us to make the replacement in your code and do initial testing.  Additional consulting on a replacement is available as needed.
4. You will receive the standard wolfSSL royalty free license to ship with your product.
5. The price is $10,000.

The purpose of this program is to enable users who are currently spending too much on their embedded SSL/TLS implementation to move to wolfSSL with ease.  If you are interested in learning more, or interested in how wolfSSL compares to what you are currently using, then please contact us at facts@wolfssl.com.

TLS 1.3 has some significant changes from TLS 1.2 that are targeted at performance. This is the fourth 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 server generating a key pair before the handshake starts.

As mentioned in the first blog in this series there is a way to mitigate some of the key exchange cost in TLS 1.3. If the server knows which key exchange algorithm will be used, it can preemptively generate a key pair after accepting a TCP/IP connection by calling wolfSSL_UseKeyShare(). In an architecture where both end-points are controlled by the same entity, a choice of security parameters, like the key exchange algorithm, is made upfront and can be relied on.

When directly connecting to a server, typically, a client only starts creating the ClientHello once a TCP/IP connection has been made. The server accepts the connection and waits for the client to generate a key share and send a ClientHello message. In this time, the server can also generate a key pair.

When using DH for key exchange this provides a significant saving as key generation is expensive. For example when using RSA for server authentication and running both client and server on the same computer, the connection is about 20% faster and with session reuse or PSK for server authentication, the connection is about 30% faster. For connections using ECDH with ECDSA for server authentication, the connection is only about 4% faster and with session reuse or PSK for server authentication, the connection is about 7% faster. EC key generation is very fast in optimised implementations and the impact of hiding its cost is therefore less.

Servers currently reuse the ephemeral key pair across multiple connections. It is common to regenerate the key pair once an hour up to once a day. This mechanism can be used instead of server pre-generation but at the cost of perfect forward security for the server.

If your architecture allows for it, the server should be implemented to generate the key pair after accepting a connection. For DH, it is well worth it. But even for ECDH the small performance improvement will result in more connections per second.

The next blog will discuss the performance issues with handshakes performing client-server authentication.

Part 1 (TLS 1.3 Performance – Resumption)
Part 2 (TLS 1.3 Performance – Full Handshake)
Part 3 (TLS 1.3 Performance – Pre-Shared Key (PSK))

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!