TLS 1.3 Performance Part 1 – Resumption
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 at Internet of Things World 2018
Please join the wolfSSL team at the Internet of Things World this week in Santa Clara! Come talk to our IoT security experts at booth 746 and learn why TLS 1.3, hardware encryption and secure elements are critical for secure, high quality IoT designs. Also, ask us about wolfCrypt FIPS validated cryptography for IoT. Need another reason to visit? Then ask us about the most comprehensively tested and supported cryptography available, with 6 different fuzz testers running against every build, which is why 4 of the world’s top 5 auto vendors, all of the top IIoT companies, and everybody who needs top notch support uses wolfSSL!
FIPS 140-2 Validations in a Secure Enclave
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 Intel SGX + FIPS 140-2!
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!
wolfSSL repository for FreeRTOS classic and Amazon FreeRTOS
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.
wolfSSL ARMv8 Support
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!
MQTT Secure Firmware Update Example
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.
wolfSSL at ICMC18
wolfSSL will be exhibiting and speaking at the 2018 International Cryptographic Module Conference in Ottawa, Ontario. This event will be held at the Shaw Centre in Ottawa, Ontario, Canada May 8th – 11th, 2018.
We will be giving a session on May 9th, focusing on doing FIPS 140-2 validations inside a secure enclave, such as Intel SGX. Complete details are below:
FIPS 140-2 VALIDATIONS IN A SECURE ENCLAVE (archived)
May 9th, 2018
4:15 – 4:45 EDT
Room: G13B
Speaker: Chris Conlon
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.
If you are attending or planning on attending please stop by our table or schedule an appointment by contacting us at facts@wolfssl.com. We will be talking about TLS 1.3, TPM 2.0, Intel SGX, wolfCrypt FIPS operating environment updates, embedded TLS, and more!
For more information about ICMC, or to purchase tickets, you may register at: https://icmconference.org/
We look forward to seeing you there!
wolfSSL FAQ page
IoT Podcast with Stacey Higginbotham
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/