Category: Uncategorized

wolfSSL is proud to announce release v3.15.0 of our wolfSSL embedded TLS library. Among the many additions are:

• Support for wolfCrypt FIPS on SGX
• Support for TLS 1.3 Draft versions
• Single Precision assembly code added for ARM and 64-bit ARM to enhance performance
• Improved performance for Single Precision maths on 32-bit
• Expanded OpenSSL compatibility layer

We have added Intel SGX as an operating environment for our wolfCrypt FIPS library. You can take advantage of running the wolfCrypt code in a secure enclave. For more information, contact fips@wolfssl.com.

With the finalization of TLS 1.3 on the horizon, we add incremental support for the drafts of the protocol. wolfSSL is current through draft 28 of the specification.

We are committed to supporting TLS 1.3 on embedded platforms, and we want to squeeze the most performance out of the chips for public key algorithms. After great success with the Intel assembly performance increases, we have added ARM assembly single-precision math support for RSA, ECC, and DHE.

To make porting existing projects over to wolfSSL, we have our OpenSSL compatibility layer. We are always expanding it. This release includes a large set of APIs to our support.

For more information, please contact facts@wolfssl.com. You can see the full change log in the source archive from our website at www.wolfssl.com or at our GitHub repository.

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

The performance of TLS 1.3 using wolfSSL has recently been discussed here in the blogs. While checking our performance a comparison was made with OpenSSL. An OpenSSL server using the latest TLS 1.3 implementation at the time was used with the wolfSSL client. The numbers showed that the recent Intel x86 64-bit assembly optimizations have been worth it.

Firstly, the performance of PSK without key exchange is mostly dependent on the speed of the hash algorithm. The results showed that the small block performance of SHA-256 in wolfSSL was the difference. On the platform tested, wolfSSL is about 22% faster than OpenSSL at hashing 256 bytes. The performance of wolfSSL in PSK non-KE handshakes was about 19% better than that of OpenSSL. The improved hashing performance partially helped other results.

The performance of other TLS 1.3 handshakes is dominated by the public key operations. Note that OpenSSL did not negotiate DH with TLS 1.3 in the version tested. When using PSK with a key exchange the public key operations the server performs are: ECDH key generation and secret calculation. While these operations in wolfSSL are only around 7% faster than OpenSSL on the platform the overall handshake performance was about 36% better. The overheads around performing the cryptographic operations in OpenSSL and slower hashing during the handshake made up the difference.

When using RSA certificates for server authentication, the cost of signing outweighs any other operation. On the platform RSA signing is about the same speed in wolfSSL as OpenSSL. The overall handshake speed was 10-15% better than OpenSSL due to overheads and hashing.

P-256 operations are faster in wolfSSL than OpenSSL and the overheads and hashing difference once again impacted the results. The server is performing key generation, secret generation, and signing operations. wolfSSL is 7-13% faster at performing these operations with P-256 on the platform and about 3% faster performing X25519 operations. wolfSSL was seen to be 35-40% faster than OpenSSL when using P-256 and 20-30% faster when Curve25519 is used for key exchange. When client authentication was also performed, similar improvements were seen.

Performance increases like 35-40% are real reasons to use wolfSSL rather than OpenSSL for TLS 1.3 and especially on Intel x86 64-bit.

If you would like more information about using wolfSSL in your project, email us at facts@wolfssl.com.

Some interesting results were found when comparing the throughput of TLS 1.2 and TLS 1.3 using an assembly optimized wolfSSL – some good, some bad. This is the last of the 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. There are differences in the way the data is encrypted in TLS 1.2 and 1.3. For some algorithms this makes a noticeable difference.

TLS 1.2 encrypts the plaintext of the message and generates an authentication code on the encrypted data plus additional_data which includes: a 64-bit sequence number, 1 byte content type, 2 byte version and 2 byte length. This is a total of 13 extra bytes in additional_data.

TLS 1.3 encrypts the plaintext of the message plus one byte for the real record type and generates an authentication code on the encrypted data plus the record header of 5 bytes.

For AES-GCM cipher suites the throughput was observed to be slightly increased with the Intel x86 64-bit optimized assembly code. This is due to the number of bytes passed in as additional authentication data (AAD). The AAD bytes are processed separately before encryption and decryption and it turned out processing 5 bytes was faster than 13. The extra byte on the end of the encrypted data did not have a significant impact.

For Chacha20-Poly1305 the different size of data passed in as AAD has no significant impact as the data is placed into a 16 byte block and padded before being processed. But, the extra byte at the end of the plaintext did impact the Chacha20 and Poly1305 performance. For Poly1305, the extra byte resulted in an extra 16 byte block being processed. In total this had about a 3-5% impact on throughput with the Intel x86 64-bit optimized assembly code.

TLS 1.3 has better throughput when using AES-GCM and is another reason to change. For maximum throughput consider sending one less than the maximum plaintext size, by default 16384 bytes, in an application data message. This will have a positive impact for both AES-GCM and Chacha20-Poly1305 cipher suites.

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)
Part 5 (TLS 1.3 Performance – Client-Server Authentication)

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.