HackMDPerformance Measurement Of SSL/TLS Using Trusted Platform Module
About The Speed of Cipher Algorithms
Situation Specification
We already know that we can use this github project's engine to change the role of performing the encryption and decryption algorithms for SSL/TLS communication from the CPU to the TPM. Now we want to go a step further and measure the performance change after changing it to TPM.
Task Specification
The openssl project provides a useful function to measure the performance of each algorithms it can use, that is openssl speed. I planed to use openssl speed to test the performance difference between CPU and TPM in performing these encryption and decryption algorithms.
We can simply type:
openssl speed [algorithms]
to test the performance of a algorithms. Here is the algorithms list it supported:
bf-cbc des-cbc dsa2048 idea md5 rc2-cbc rmd160 rsa2048 sha1
blowfish des-ede3 dsa512 idea-cbc mdc2 rc4 rsa rsa4096
des dsa1024 hmac md2 rc2 rc5-cbc rsa1024 rsa512
For testing, for instance, rsa 2048 with TPM we can use:
openssl speed -elapsed -engine tpm2tss rsa2048
As for testing with CPU, we can use:
openssl speed -elapsed rsa2048
Action Specification
We performed a CPU speed benchmark of all the algorithms supported by TLS1.2, and then tested them in TPM engine mode to compare the efficiency difference between them.
That is:
- RSA
- ECDH
- ECDSA
- AEC GCM
The paltform will be AMD R5 3600, AMD ftpm on Gigabyte A520m aorus elite motherboard, ubuntu linux 20.04 LTS.
Result
https://hackmd.io/@nemoz/SkjzS7Ghq
We can surprisingly find that the performance of TPM is worse than CPU for almost any algorithm by the results. In some cases the difference is even tens of times more, like:
| RSA2048 with CPU | RSA2048 with TPM | |
|---|---|---|
| sign speed(sign/s) | 1969.0 | 178.3 |
| 256 bits ecdh with CPU (brainpoolP256r1) | 256 bits ecdh with TPM (brainpoolP256r1) | |
| op/s | 2947.3 | 27.8 |
About The Speed of SSL Connection
Task Specification
We are going to test the speed difference of SSL connection from CPU to TPM. For doing so, we can take a look to a very useful function of OPENSSL, that is s_server and s_time.
The s_server function can build a simple SSL server with -WWW argument, we can easily use:
openssl s_server -cert rsa.crt -key rsa.tss -keyform engine -engine tpm2tss -accept 8443 -WWW
to construct a https server with root directory of current dir. For testing, let's write a simple html file:
<!DOCTYPE html>
<html>
<body>
<h1>My First Heading</h1>
<p>My first paragraph.</p>
</body>
</html>
Then use the command above to open a https server. Then open our web broswer then type in https://localhost:8443/test.html. The result is:
Because the certificate is signed by ourself, the broswer will marked it as unsafe(Need to pay to get a CA to sign for you to remove the unsafe label, what a scam).
As for the another part, s_time, is to measure the performance of a HTTPS server by requesting a file or a page. The usage is:
openssl s_time -connect nemo.org:8443 -cipher ECDHE-RSA-AES128-GCM-SHA256 -www /test.html
The result will be:
Collecting connection statistics for 30 seconds
****************************************
40 connections in 0.04s; 1000.00 connections/user sec, bytes read 5800
40 connections in 31 real seconds, 145 bytes read per connection
Now timing with session id reuse.
starting
rrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrr
257 connections in 0.18s; 1427.78 connections/user sec, bytes read 37265
257 connections in 31 real seconds, 145 bytes read per connection
So, combining s_server and s_time, we can easily test the performance of our https server.
Action Specification
We create a 100MB size file for our experiment. Starting a https server that hosting this file, then with the command below:
openssl s_server -cert rsa.crt -key rsa.tss -keyform engine -engine tpm2tss -accept 8443 -WWW
to host a https server with TPM, and with:
openssl s_server -cert cpu.crt -key cpu.key -accept 8443 -WWW
to host a https server with CPU.
But there's multiple factors that may can affect the speed, such like:
- The symmetric algorithm we take
- The asymmetric key size
- Internet speed
For proper testing, that is ignore the affect by internet speed, we make client and server be at a same machine. Then we set the cipher algorithm to ECDHE-RSA-AES256-GCM-SHA384 which is what TLS v1.3 current using.
For more realistic, we also set up two machines connected via switch with 100M cable to test the performance.
So, we can use:
openssl s_time -connect nemo.org:8443 -cipher ECDHE-RSA-AES256-GCM-SHA384 -www /100MB.bin
to requesting the file, then get the total number of connections in 30 seconed.
Result
Server: AMD ryzen r5 3600 12-threads CPU, 16 GB RAM, ubnutu 20.04 LTS, AMD fTPM 3.77.
client(for seperate): APPLE MACBOOK AIR 2020.
In a same machine (server/client)
For 100MB file
| CPU | TPM | |
|---|---|---|
| # of connections | 436 | 37 |
| cpu time | 16.14s | 1.51s |
| connections/cpu time | 27.0 | 24.5 |
| connections/real time | 14.53 | 1.23 |
| # of connections with http id reuse | 437 | 158 |
| cpu time with http id reuse | 16.16s | 6.06s |
| connections/user sec with http id reuse | 27.03 | 26.03 |
| connections/real time with http id reuse | 14.57 | 5.27 |
For 1GB file
| CPU | TPM | |
|---|---|---|
| # of connections | 46 | 21 |
| cpu time | 15.91s | 7.34s |
| connections/user sec | 2.89 | 2.86 |
| connections/real time | 1.53 | 0.7 |
| # of connections with http id reuse | 46 | 39 |
| cpu time with http id reuse | 16.14s | 13.63s |
| connections/user sec with http id reuse | 2.85 | 2.86 |
| connections/real time with http id reuse | 1.53 | 1.3 |
In seperate machines (through 100M cable)
For 100MB file
| CPU | TPM | |
|---|---|---|
| # of connections | 4 | 4 |
| cpu time | 0.45s | 0.44s |
| connections/user sec | 8.71 | 8.97 |
| connections/real time | 0.13 | 0.13 |
| # of connections with http id reuse | 4 | 4 |
| cpu time with http id reuse | 0.54s | 0.53s |
| connections/user sec with http id reuse | 7.28 | 7.51 |
| connections/real time with http id reuse | 0.13 | 0.13 |
For test.html(101 bytes)
| CPU | TPM | |
|---|---|---|
| # of connections | 2646 | 45 |
| cpu time | 3.83s | 0.10s |
| connections/user sec | 690.4 | 419.75 |
| connections/real time | 88.2 | 1.5 |
| # of connections with http id reuse | 13733 | 544 |
| cpu time with http id reuse | 1.88s | 0.28s |
| connections/user sec with http id reuse | 7295.66 | 1932.6 |
| connections/real time with http id reuse | 457.77 | 18.13 |
Conclusion
We can find that the CPU processing speed of SSL connection is much faster than TPM in all four cases, except for the file size of 100MB with cable, and since the case is sent through the network cable, the bottleneck is in the bandwidth, so the number of connections per unit time is not too much different. Especially when sending small files (e.g. web page files), the CPU can process SSL connections 20 to 50 times faster than TPM.
However, when we enable https session id reuse, we can find that the speed difference between TPM and CPU processing SSL connection is reduced, probably because we don't need to do a TLS handshake for each connection for key exchange when https session id reuse is enabled, so we can also infer that TLS handshake should be a bigger burden to TPM. This can also be seen in the case of sending 1GB files, because the main work when sending larger size files is symmetric encryption and decryption algorithms rather than TLS handshake, so this part of TPM performance is almost the same as CPU.
On the other hand, we can also find that the CPU user time consumed when using TPM to process SSL connections is less than when using CPU alone, and this is even more obvious when dealing with situations where bandwidth is not a bottleneck, such as when sending 100MB of data from the same machine and web page files from separate machines, the CPU time used by TPM is less than 10% of that used when using CPU alone.
According to the above experiment we can know that the speed of cipher algorithm using TPM is much less than modern CPU, so TPM can't help to accelerate SSL connection. However, using TPM for this type of algorithm can help to reduce the CPU usage in SSL connections.
