Performance implication of elliptic curve TLS

Transcription

1 MSc Systems & Network Engineering Performance implication of elliptic curve TLS Maikel de Boer - maikel.deboer@os3.nl Joris Soeurt - joris.soeurt@os3.nl April 1, 2012 Abstract During our research we tested how much performance increase could be gained by changing from a traditional Ron Rivest, Adi Shamir and Leonard Adleman (RSA) based cipher suite in Transport Layer Security (TLS) to equivalent Elliptic Curve Cryptography (ECC) based cipher suites. We benchmarked Hyper Text Transport Protocol (HTTP) and three di erent TLS cipher suites (RSA ephemeral, ECC ephemeral and non ephemeral) using di erent file sizes and with and without TLS session reuse. Under specific conditions, changing from a traditional RSA cipher suite to a ECC cipher suite can yield 58% lower CPU usage on the web server, increases the throughput by 13% and lowers the latency by 73%. When using a non ephemeral ECC based cipher suite the throughput increases by 21% compared to the ECC ephemeral cipher suite. Overall we can conclude that ECC improves performance under most, but not all conditions. 1 Introduction ECC is emerging as an attractive publickey crypto system for mobile/wireless environments. Compared to traditional crypto systems like RSA, ECC o ers equivalent security with smaller key sizes, which results in faster computations, lower power consumption, as well as memory and bandwidth savings. This is especially useful for mobile devices which are typically limited in terms of their CPU, power and network connectivity. [1] For our research we tested if ECC is faster and less costly (in terms of server resources) than traditional cipher suites under specific circumstances, when used in combination with TLS. We benchmarked di erent cipher suites to measure how they perform using di erent file sizes and parameters. Data was collected based on client CPU, throughput (requests per second), latency (response time) and CPU usage on the web server. This paper does not discuss the inner working of the TLS protocol nor the working of RSA and ECC ciphers, it does however strive to give a realistic overview of the performance gain that can be achieved using di erent file sizes and concurrent users requesting a specific file. It is advisable to have prior knowledge of how TLS and di erent cipher suites work. For more information we would like to refer the reader to the following documents [2] [3]. In section 2 we will clarify the way we have chosen the cipher suites, our test setup and the performance metrics. In section 3 we show the results. In section 4 we end with a conclusion and in section 5 we do some suggestions for future research. Research Question The main research question for our research is: How much performance improvement can be gained by replacing the key exchange mechanism in TLS 1

2 from RSA to elliptic curve Di e- Hellman? 2 Approach Cipher suite selection A cipher suite defines a combination of cryptographic algorithms used in a TLS connection. It consists of four di erent parts; the key exchange algorithm, authentication algorithm used to verify the client and the server, encryption algorithm used for bulk encryption/decryption and the Message Authentication Code (MAC) algorithm to generate the message digest to ensure message integrity. Di erent cipher suites have di erent properties with respect to performance and security. The cipher suites we used for testing were selected based on the National Institute of Standards and Technology (NIST) recommendations for key management [4]. The NIST recommends to use a 3072 bit key when using RSA and a 256 bit key when using ECC for su cient security of data till even after Based on the recommendations of NIST we chose to test the following cipher suites: Code 0x00,0x33 0xC0,0x09 0xC0,0x04 Name DHE-RSA-AES128-SHA ECDHE-ECDSA-AES128-SHA ECDH-ECDSA-AES128-SHA Table 1: Selected ciphers suites For the ECC ciphers we created keys and certificates using the secp256r1 curve. For RSA we created a 3072 bit key which we used to sign a RSA certificate. The 0x00,0x33 and the 0xC0,0x09 are both ephemeral suites which achieve Perfect Forward Secrecy (PFS). No cipher suite comparable to the 0x00,0x33 RSA based cipher suite which does not achieve PFS is available. To measure the overall impact of TLS we also performed benchmarks using the same hard- and software configuration but using HTTP instead of Hyper Text Transport Protocol Secure (HTTPS). Test setup The test setup consisted of two Dell PowerEdge 2950 servers with 4GB of RAM and Intel Xeon 2.00GHz processor running Ubuntu (Oneiric) x64. The first server is configured as web server and the second server is configured to simulate web clients using Jmeter. Both servers are directly connected using a 1Gbit ethernet link. We used Apache build from source with Secure Socket Layer (SSL) enabled. The TLS module for Apache, (mod ssl) relied on OpenSSL binaries version e for it s cryptographic functions. Jmeter is a Java based web server benchmark tool from the Apache project 1.Weused Jmeter 2.6 (Java version ) for simulating actual users requesting webpages from the server. At the web server we used System Activity Reporter (SAR) which is part of the sysstat packet available from the Ubuntu repository. We used SAR to measure the client and server CPU load. During di erent tests Jmeter was configured to simulate 1, 5, 10, 100 or 200 simultaneous users (threads) requesting files of sizes 1Kb, 5Kb, 10Kb, 100Kb, 500Kb or 1000KB. The ramp up period was set to 10 seconds, which means that Jmeter takes 10 seconds to start all threads. For 10 threads this means Jmeter starts 1 thread per second, for 100 threads this means Jmeter starts 10 threads per second. Jmeter was configured not to use HTTP keep-alive, which means every simulated user opens a new Transmission Control Protocol (TCP) socket which is closed immediately after the HTTP or HTTPS response is successfully received from the server. Finally, HTTPS session reuse was disabled to force every iteration to negotiate a new TLS session key. Our test were both performed with one file per iteration as 20 files per iteration. The latter means that TLS session key is exchanged for every 20 files a thread requests. All tests were performed for both HTTP and HTTPS using all selected cipher suites, with all number of threads and all file sizes

3 This resulted in 192 di erent tests. Every test ran for 180 seconds, between every test we scheduled a cooling down period of also 180 seconds. Performance metrics During the experiments we measured the following performance metrics a) throughput (total amount of requests divided by the time the experiment took to complete) b) average latency (average time it took before a requests is received by the client after issuing a request to the server) c) CPU load (load of the CPU for user processes and kernel processes) 3 Results The results shown in the graphs are based on the measurement data of the test performed with 100 concurrent threads. We choose to use only graphs of one thread size because the shape of the graphs were identical at all different number of threads. This means using di erent number of concurrent threads doesn t lead to di erent results (relative between the ciphers). The 100 threads graphs were selected because these showed the optimal peak in absolute performance. 3.1 CPU usage Figure 1 shows that 0xC0,0x09 is less CPU intensive than 0x00,0x33 for TLS handshakes, even up to 58% for 1KB file sizes. When file sizes increase the di erence becomes smaller because less handshakes have to be performed. For 1000KB the CPU is 19% less stressed. In Figure 4 we see the e ect reuse has on CPU performance. When reusing the TLS session key the CPU load decreases because less asymmetric encryption handelings are done. The 0xC0,0x09 suite is still 36% less CPU intensive for 1KB files. The peak in Figure 4 shown when reusing session keys, at file size 100KB for the 0xC0,0x09 cipher is strange and we don t have a feasible explanation for this behavior. The same holds for the (minimal) drop at file size 5KB for 0x00,0x Throughput When looking at Figure 2 we observe that the throughput is higher when using the 0xC0,0x09 cipher suite instead of the 0x00,0x33 suite for all file sizes. This is expected behavior since the ECC encryption techniques should demand less resources from the server. The client throughput is higher when using the 0xC0,0x09 cipher suite up to the 500KB file size with at max 13%. At this point the 0xC0,0x09 has a better throughput than the 0x00,0x33 suite with a small percentage. When reusing the TLS session key, the overall throughput increases by at max 922% at 1KB file sizes, see Figure 5. An unexpected observation is the fact that the throughput of 0x00,0x33 is higher than the 0xC0,0x09 throughput at all file sizes with a di erence between 1.4 and 4.3% till 1000KB file sizes. 3.3 Latency In Figure 3 we see that the latency for the 0x00,0x33 is higher than the latency for the 0xC0,0x09 suite for file sizes up of 500KB. Starting at files of 500KB and larger the 0x00,0x33 suite has less latency. In Figure 6 we show the results with session reuse enabled. When reusing the TLS session key, the latency of 0x00,0x33 decreases up to 90% and the latency of 0xC0,0x09 with 89% at 1KB file size. For file sizes up to 1000KB the latency for the 0x00,0x33 cipher is less than for 0xC0,0x09 which we don t have a feasible explanation for. 3.4 Ephemeral and non-ephemeral To show the cost (in terms of performance and resources) of achieving PFS we also performed our tests with a non-ephemeral ECC based cipher suite and created graphs for comparison of the ephemeral ECC based cipher suite. In Figure 7 and Figure 10 we see for both with and without TLS session reuse, the non ephemeral cipher suite uses less CPU than the 3

4 ephemeral cipher suite in most cases. The nonephemeral suite however performs better at 500 KB for both graphs and also at 1000 KB when session reuse is enabled. When we look at Figure 8 and Figure 11 we can see that the throughput for the non ephemeral suite is higher then the ephemeral version for both with and without TLS session reuse enabled. This clearly shows PFS comes at a cost and without TLS session reuse leads to 21% throughput decrease for the smallest file size up to 7% for the largest file size. In Figure 9 we can see that without TLS session key reuse, the ephemeral cipher suite also increases the latency. When reusing the TLS session keys (Figure 12) the di erence becomes much smaller and we observe almost no di erence between the 0xC0,0x04 and 0xC0,0x09 suite. The latency of the non ephemeral cipher suite is however higher at 1000 KB when reusing the session key, which we don t have a feasible explanation for. 3.5 HTTP To put the TLS performance and resource usage in perspective we also benchmarked plain HTTP performance. Because of enormous difference in scale we chose to display the results in separate graphs. We should however note that the TLS performance was measured on basis of a key length that su ces even after At that time server hardware would be that dramatically di erent from current hardware that the comparison would probably be di erent. When we compare HTTPS to HTTP performance, our benchmarks show that for the smallest file size (1 KB), server CPU drops by 53% (Figure 13) while increasing throughput by as much as 6220% (Figure 14) while latency drops by 99% (Figure 15). For the largest file size (100 KB), CPU even drops by 95% while throughput still increases by 92% and latency drops by 46%. 4 Conclusion Our benchmarks have shown that under specific circumstances (1KB file size, no session key reuse) changing from the 0x00,0x33 to the 0xC0,0x09 cipher can yield a 58% lower CPU usage on the web server. It also increases client throughput by 13% while lowering client latency by 73%. The results are however not consistent for all conditions. For example some file sizes lead to less performance with the ECC cipher and when enabling session reuse, the 0x00,0x33 cipher suite performs better for all file sizes. (These deviations from the expected results are similiar in all tests with all number of threads and results are reproducible.) We observed that the di erence in performance is much smaller when TLS session reuse is enabled. In real life scenarios the number of files transferred per session key will probably be larger than the 20 we used for our benchmarks which decreases the di erence in performance between the ciphers even more. For TLS to work we need a Certificate Authority (CA) that supports signing the web server certificate with an ECC private key (all the way up to the root), unfortunately not all CAs support ECC at this point in time. Also not all client and server software has support for ECC (for example the versions available in software repositories like in Debian or Ubuntu). As expected, using an ephemeral ECC cipher leads to less client throughput in comparison to a non ephemeral ECC cipher. Although substantial, and observable with all file sizes, it isn t really an option to use an non ephemeral cipher suite if you take security serious. Overall we can conclude that ECC improves performance under most circumstances. Offering the possibility to negotiate ECC between clients and server will reduce the load on servers where large installations could benefit from. 4

5 5 Future work During our research we used static files and used one specific file size per test. Our tests did not simulate the tra c of a real site, it only shows under which controlled conditions the ECC based cipher suite performance better than a RSA based cipher suite. Since every website is di erent it is di cult to calculate a generic measurement on how much performance improvement can be obtained. Therefore it would be interesting to see how ECC performs using real life tra c patterns (for example in a large production website) compared to RSA cipher suites. Note that when browsing three popular, large scale websites for 5 minutes each, we measured 77 percent of all downloaded files were less than 10 KB and only 6 percent of the files was larger than 100 KB in size. This makes the smallest three filesizes in our tests most representable for real life perfomance. A second thing which which would be interesting is measure how ECC impacts performs using other secure protocols like DNSsec, IMAPs, SSH etc. Graphs References [1] Oracle, Securing the Web with Elliptic Curve Cryptography. oracle.com/projects/crypto/. [2] S. Blake-Wilson, Elliptic Curve Cryptography (ECC) Cipher Suites for Transport Layer Security (TLS), May http: // [3] T. Dierks et al., The TLS Protocol Version 1.0, January org/rfc/rfc4492.txt. [4] NIST, Recommendation for Key Management, Special Publication Part 1 Rev. 3, May toolkit/key_management.html. Figure 1: Average CPU usage on server, per file size. Figure 2: Throughput on client, per file size. Figure 3: Average request latency on client, per file size. 5

6 Figure 4: Average CPU usage on server, per file size. Session key reuse enabled. Figure 7: Average CPU usage on server, per file size. Figure 5: Throughput on client, per file size. Session key reuse enabled. Figure 8: Throughput on client, per file size. Figure 6: Average request latency on client, per file size. Session key reuse enabled. Figure 9: Average request latency on client, per file size. 6

7 Figure 10: Average CPU usage on server, per file size. Session key reuse enabled. Figure 13: HTTP average CPU usage on server, per file size. Figure 11: Throughput on client, per file size. Session key reuse enabled. Figure 14: HTTP throughput on client, per file size. Figure 12: Average request latency on client, per file size. Session key reuse enabled. Figure 15: HTTP average request latency on client, per file size. 7