DEGREE PROJECT IN ELECTRICAL ENGINEERING, SECOND CYCLE, 30 CREDITS STOCKHOLM, SWEDEN 2019
TLS Library for Isolated Enclaves Optimizing the performance of TLS libraries for SGX
JIATONG LI
KTH ROYAL INSTITUTE OF TECHNOLOGY SCHOOL OF ELECTRICAL ENGINEERING AND COMPUTER SCIENCE
TLS Library for Isolated Enclaves Optimizing the performance of TLS libraries for SGX
Jiatong Li
2019-01-16
Master’s Thesis
Examiner Gerald Q. Maguire Jr.
Academic adviser Anders Västberg
Industrial adviser Nicolae Paladi, RISE SICS
KTH Royal Institute of Technology School of Information and Communication Technology (ICT) Department of Communication Systems SE-100 44 Stockholm, Sweden
Abstract | i
Abstract
Nowadays cloud computing systems handle large amounts of data and process this data across different systems. It is essential to considering data security vulnerabilities and data protection. One means of decreasing security vulnerabilities is to partition the code into distinct modules and then isolate the execution of the code together with its data. Intel’s Software Guard Extension (SGX) provides security critical code isolation in an enclave. By isolating the code’s execution from an untrusted zone (an unprotected user platform), code integrity and confidentiality are ensured. Transport Layer Security (TLS) is responsible for providing integrity and confidentiality for communication between two entities. Several TLS libraries support cryptographic functions both for an untrusted zone and an enclave. Different TLS libraries have different performance when used with Intel’s SGX. It is desirable to use the best performance TLS library for specific cryptographic functions. This thesis describes a performance evaluation several popular TLS libraries performance on Intel SGX. Using the evaluation results and combining several different TLS libraries together, the thesis proposes a new solution to improve the performance of TLS libraries on Intel SGX. The performance is best when invoking the best specific TLS library based upon the data size – as there is a crossover in performance between the two best libraries. This solution also maintains the versatility of the existing cryptographic functions.
Keywords
Intel SGX, Trusted Execution Environment, TLS libraries
Sammanfattning | iii
Sammanfattning
Numera hanterar molnberäkningssystem stora mängder data och bearbetar dessa data över olika system. Det är viktigt att ta itu med datasäkerhetsproblem och dataskydd. Ett sätt att minska säkerhetsproblem är att partitionera koden i olika moduler och sedan isolera kodens exekvering tillsammans med dess data. Intel’s Software Guard Extension (SGX) tillhandahåller säkerhetskritisk kodisolering i en enklav. Genom att isolera kodens körning från en otillförlitlig zon (en oskyddad användarplattform) säkerställs kodintegritet och sekretess. Transport Layer Security (TLS) ansvarar för att ge integritet och konfidentialitet för kommunikation mellan två enheter. Flera TLS-bibliotek stödjer kryptografiska funktioner både för en osäker zon och en enklav. Olika TLS-bibliotek har olika prestanda när de används med Intel’s SGX. Det är önskvärt att använda TLS- bibliotekets bästa prestanda för specifika kryptografiska funktioner. Denna avhandling beskriver en prestationsutvärdering av flera populära TLS- bibliotekens prestanda på Intel SGX. Genom att använda utvärderingsresultaten och kombinera flera olika TLS-bibliotek tillsammans, presenterar avhandlingen en ny design och lösning för att förbättra prestanda för TLS-bibliotek på Intel SGX. Den resulterande prestanda åberopar TLS-bibliotekets bästa prestanda inom en viss datastorlek samtidigt som krypteringsfunktionerna är mångsidiga.
Nyckelord Intel SGX, Trusted Execution Environment, TLS-bibliotek
Acknowledgments | v
Acknowledgments
I would like to express my sincere appreciation to my Master’s thesis examiner Professor Gerald Q. Maguire Jr. for his irreplaceable help and suggestion. I would like to thank my industrial supervisor from RI.SE SICS, Dr. Nicolae Paladi for giving me this interesting topic and his suggestions through the whole project. Finally, super thanks to my parents and all of my friends for supporting me throughout the whole Master’s program.
Stockholm, January 2019 Jiatong Li
Table of contents | vii
Table of contents
Abstract ...... i Sammanfattning ...... iii Acknowledgments ...... v Table of contents ...... vii List of Figures ...... ix List of Tables ...... xi List of acronyms and abbreviations ...... xiii 1 Introduction ...... 1 1.1 Background ...... 1 1.2 Problem ...... 1 1.3 Purpose ...... 1 1.4 Goals ...... 2 1.5 Hypothesis ...... 2 1.6 Research questions ...... 2 1.7 Research Methodology ...... 2 1.8 Delimitations ...... 2 1.9 Structure of the thesis ...... 3 2 Background ...... 5 2.1 Intel Software Guard Extension ...... 5 2.1.1 Memory isolation in Intel®SGX ...... 5 2.1.2 SGX2 ...... 6 2.1.3 ECALL and OCALL ...... 6 2.2 TLS ...... 7 2.2.1 Handshake protocol ...... 7 2.2.2 Record layer protocol ...... 8 2.2.3 AES-GCM ...... 9 2.2.4 ECDH ...... 9 2.2.5 Trusted TLS libraries ...... 10 2.3 Side-channel attack ...... 10 2.4 Related work ...... 11 3 Methodologies and Methods ...... 13 3.1 Research Process ...... 13 3.2 Hardware, Software and TLS Libraries chosen ...... 13 3.2.1 Hardware ...... 13 3.2.2 Software ...... 14 3.2.3 Selected TLS libraries ...... 14 3.3 Selected functions from the TLS libraries ...... 15 3.4 Measurements ...... 16 3.5 Assessing the reliability and validity of the data collected ... 17 3.5.1 Reliability ...... 17 3.5.2 Validity ...... 17 3.6 Data Analysis ...... 17
viii | Table of contents
4 Implementation design ...... 19 4.1 Untrusted model ...... 19 4.2 Trusted model ...... 20 4.2.1 Using trusted library inside the enclave ...... 20 4.2.2 Enclave configuration ...... 21 4.3 Cryptographic functions ...... 21 5 Results and Analysis ...... 23 5.1 Results of generating 2048 bits RSA key pairs ...... 23 5.1.1 Untrusted libraries performance ...... 24 5.1.2 Trusted libraries performance ...... 24 5.1.3 Comparison of trusted and untrusted libraries performance ...... 25 5.2 Results of calculating SHA256 hashes ...... 27 5.2.1 Performance when calculating hashes for 64B data ...... 27 5.2.2 Performance when calculating hashes for 1KB of data... 28 5.2.3 Performance when calculating hashes for 1MB of data .. 29 5.3 Results of AES-GCM encryption and decryption ...... 30 5.3.1 Performance for AES-GCM encrypt/decrypt 64B of data ...... 30 5.3.2 Performance of AES-GCM encrypt/decrypt 1KB of data ...... 32 5.3.3 Performance for AES-GCM encrypt/decrypt 1MB of data ...... 33 5.4 Results of ECDH process ...... 34 5.4.1 Performance for ECDH ...... 34 5.4.2 Performance for generating ECDH key pair ...... 35 5.5 Analysis of the performance of the libraries ...... 35 5.5.1 Performance ...... 35 5.5.2 Size ...... 36 5.6 Reliability Analysis ...... 37 5.7 Validity Analysis ...... 37 5.8 Discussion of the analysis for the individual libraries ...... 37 5.9 TLS library selection - a new design for implementing TLS libraries on Intel SGX ...... 38 5.10 Evaluation of proposed design ...... 39 6 Conclusions and Future work ...... 45 6.1 Conclusions ...... 45 6.2 Limitations ...... 45 6.3 Future work ...... 46 6.4 Reflections ...... 46 6.4.1 Ethical aspects ...... 47 6.4.2 Economic aspects ...... 47 References ...... 49
List of Figures | ix
List of Figures
Figure 2-1: Intel®SGX application ...... 6 Figure 2-2: TLS protocol ...... 7 Figure 2-3: Handshake protocol ...... 8 Figure 2-4: Elliptic-curve Diffie-Hellman ...... 9 Figure 3-1: Time measurement for untrusted/trusted library calls ...... 16 Figure 4-1: Untrusted model: without enclave ...... 19 Figure 4-2: Untrusted model: Using OCALL from enclave ...... 20 Figure 4-3: Trusted model: Using ECALL from an untrusted application ...... 21 Figure 4-4: Enclave configuration settings ...... 21 Figure 5-1: Generate 2048 bits RSA key pair in the untrusted zone ...... 24 Figure 5-2: Generate 2048 bits RSA key pair in the trusted zone ...... 25 Figure 5-3: Generate 2048 bits RSA key pair with mbed TLS/mbedtls- SGX ...... 26 Figure 5-4: Generate 2048 bits RSA key pair with wolfSSL/wolfSSL – SGX ...... 26 Figure 5-5: Generate 2048 bits RSA key pair with OpenSSL based libraries and Intel SGX SDK library ...... 27 Figure 5-6: Calculating SHA-256 for 64B data ...... 28 Figure 5-7: Calculate SHA-256 for 1KB of data ...... 29 Figure 5-8: Calculate SHA-256 for 1MB data ...... 30 Figure 5-9: AES-GCM encryption for 64B data ...... 31 Figure 5-10: AES-GCM decryption for 64B data ...... 31 Figure 5-11: AES-GCM encryption for 1KB data ...... 32 Figure 5-12: AES-GCM decryption for 1KB data ...... 32 Figure 5-13: AES-GCM encryption for 1MB data ...... 33 Figure 5-14: AES-GCM decryption for 1MB data ...... 33 Figure 5-15: ECDH process ...... 34 Figure 5-16: Time to generate a ECDH key pair ...... 35 Figure 5-17: A new implementation design for TLS libraries ...... 39 Figure 5-18: Performance plots ...... 42 Figure 5-19: Extra measurements for WolfSSL-SGX and Intel SGX SSL ... 43 Figure 5-20: Evaluation of controlled library performance plot ...... 44
List of Tables | xi
List of Tables
Table 3-1: Test platform ...... 13 Table 3-2: Intel SGX version ...... 14 Table 3-3: Investigation of existing TLS libraries...... 14 Table 3-4: Chosen TLS libraries version ...... 15 Table 3-5: The cryptographic functions that were selected for testing .... 16 Table 4-1: Cryptographic functions that were measured ...... 22 Table 5-1: Time to generate a 2048 bit RSA key pair from static data .... 23 Table 5-2: Execution time for 10000 AES-GCM 64B encryption ECALLs ...... 36 Table 5-4: TLS libraries’ size ...... 37 Table 5-5: Evaluation of proposed design for SHA-256 with different size of data (all timings in µs) ...... 40 Table 5-6: Extra measurements for wolfSSL-SGX and Intel SGX SSL (all timings in µs) ...... 40 Table 5-7: A new evaluation of proposed design for SHA-256 with different size of data (all timings in µs) ...... 41
Appendix A-1: Calculate SHA-256 for 64B data ...... 53 Appendix A-2: Calculate SHA-256 for 1KB data ...... 53 Appendix A-3: Calculate SHA-256 for 1MB data ...... 54 Appendix B-1: AES-GCM encrypt for 64B data ...... 55 Appendix B-2: AES-GCM decrypt for 64B data ...... 55 Appendix B-3: AES-GCM encrypt for 1KB data ...... 56 Appendix B-4: AES-GCM decrypt for 1KB data ...... 56 Appendix B-5: AES-GCM encrypt for 1MB data ...... 57 Appendix B-6: AES-GCM decrypt for 1MB data ...... 57 Appendix C-1: ECDH processing time ...... 59 Appendix C-2: ECDH generate key pair only ...... 59
List of acronyms and abbreviations | xiii
List of acronyms and abbreviations
AES Advanced Encryption Standard BIOS Basic Input/Output System CPU Central Processing Unit DRAM Dynamic Random Access Memory ECALL Call from Application to the Enclave ECDH Elliptic-curve Diffie-Hellman EPC Enclave Page Cache EPCM Enclave Page Cache Map GCM Galois/Counter Mode GMAC Galois Message Authentication Code HASP Hardware and Architectural Support for Security and Privacy MAC Message Authentication Code NIST National Institute of Standards and Technology OCALL Call from Enclave to the Application OS Operating System RSA Rivest Shamir Adleman SGX Software Guard Extension SSL Secure Sockets Layer TLS Transport Layer Security TEE Trusted Execution Environment TSC Time Stamp Counter
Introduction | 1
1 Introduction
This chapter describes the project and defines the problem, purpose, and main goals of this thesis. An outline of the structure of the thesis is given at the end of the chapter.
1.1 Background
Transport Layer Security (TLS) is a protocol providing communication security with cryptographic functions. TLS is widely used for providing virtual private networks and in conjunction with access to websites in order to provide privacy and confidentiality for the communications. Intel® Software Guard Extension (SGX) [1] is designed by Intel to provides data integrity and confidentiality. SGX only trusts the central processing unit (CPU) as an independent execution environment. The advantage of calling cryptographic functions (such as those used in TLS) from within an SGX enclave* instead of an untrusted zone† is that even if the operating system is compromised, the attacker cannot access the key since the key is protected by being isolated within an SGX enclave.
1.2 Problem
While several TLS libraries support Intel SGX, running cryptographic function benchmarks in both untrusted and trusted environments has shown differences between the performances of different TLS libraries. When calling cryptographic functions from within an SGX enclave, the user may want to implement the best performance (in terms of minimum execution time) TLS library for a specific purpose. As a result, it is important to know what is the best TLS library for a specific cryptographic function when using SGX?
1.3 Purpose
The purpose of this thesis is to examine in detail several different TLS libraries, analyze them, and then focus on their security with regard to Intel SGX. The project compares the performance of several TLS libraries that currently support Intel SGX. The differences and trade-offs were analyzed in order to improve the performance of one of these TLS libraries. The tools used for performance testing each of the TLS libraries are also described.
* An enclave is an isolated environment that SGX provides. Further details are given in Section 2.1. † An untrusted zone is an unprotected user platform.
2 | Introduction
1.4 Goals
The goals of this project were to evaluate the performance of TLS libraries when using Intel SGX and to improve this performance by analyzing trade-offs that could be made. This goal has been divided into the following three sub-goals: 1. Identify a comprehensive set of relevant tests to evaluate TLS performance when using SGX enclaves. 2. Analyze the performance evaluation of all trusted TLS libraries. 3. Analyze the performance of a specific TLS library for communication between the trusted enclave and an untrusted zone. 4. Improve the best performance TLS library on SGX.
1.5 Hypothesis
The working hypothesis was that different TLS libraries have different performance for different cryptographic functions. Moreover, when comparing the time for calling cryptographic functions in an unprotected user platform, calling the same cryptographic functions within trusted libraries would take more time.
1.6 Research questions
The observed performance differences of various cryptographic functions and the hypothesis above suggested the following research questions: What is the best performance TLS library when calling cryptographic functions in an isolated enclave? When calling trusted libraries in an enclave, is there one TLS library that provides the best performance for all cryptographic functions or do different libraries provide better performance for specific functions?
1.7 Research Methodology
This project used experimental research methods to analyze the performance of different TLS libraries when using SGX and to identify trade-offs. For example, one TLS library offers the best performance when calculating hash while another has better performance when generating key pairs. As a result, one means of improving TLS libraries’ performance on SGX would be to use the first TLS library to calculate a hash and then use the other to generate a key pair. Additional details concerning methodology are given in Chapter 3.
1.8 Delimitations
Due to platform limitation, TLS libraries and enclave application are running in one core of CPU. The process of different TLS libraries and enclave application may affect performance (Details in section 6.2). This thesis only discusses the performance when calling cryptographic functions from a single enclave. It would be interesting to see the results when calling
Introduction | 3
cryptographic functions from multiple SGX enclaves, but this remains for future work.
1.9 Structure of the thesis
Chapter 2 presents relevant background information about Intel Software Guard Extension and TLS library cryptographic functions. Chapter 3 introduces the research methodology and measurement details. Chapter 4 shows the implementation design of this project. Chapter 5 presents the result and analysis of the performance difference between TLS libraries. Chapter 6 gives a conclusion of this thesis. Appendix including specific data is available in the end.
Background | 5
2 Background
This chapter provides basic background information relevant to this thesis. Section 2.1 describes the Intel® SGX architecture. Section 2.2 describes the SSL/TLS protocol and several cryptographic functions in TLS. Section 2.3 gives an overview of a side-channel attack against SGX. Related work is presented in Section 2.4.
2.1 Intel Software Guard Extension
A Trusted Execution Environment (TEE) is used to provide data integrity and confidentiality by isolating the running environment. Intel provides a solution for creating a TEE via the Intel Software Guard Extension (SGX) [1]. Intel SGX is designed to protect code/data integrity and preserve confidentiality as an independent black box (called an enclave). The aim of Intel’s SGX design is not to identify and isolate all malicious software or code in the operating system (OS). Instead, all trusted code is encapsulated in an enclave protected by hardware. After generating an enclave, the contents of the enclave will be confidential and only code within the enclave will have access to read/write enclave data. As shown in Figure 2-1, Alice wants to run an application; however, she cannot fully trust her working environment, thus she builds an enclave to execute the core code of her application. When she starts her application, it initializes an enclave and uploads the computation and associated data to the enclave. The system will reserve memory for the enclave before enclave initialization. Subsequently, the core code of the application will be executed inside a secure container. Trusted hardware ensures that the execution is isolated so that external code and even privileged software does not have access to read or write data inside the enclave. The enclave encrypts the result and sends it back to Alice’s application to continue its normal execution.
2.1.1 Memory isolation in Intel®SGX
When creating an enclave, a range of physical memory is reserved. The code and data inside the enclave must be executed within this range of isolated memory. This area of memory is called an Enclave Page Cache (EPC). This memory contains secret code and data in units of 4KB pages. In order to control the access to each EPC page, the Enclave Page Cache Map (EPCM) is used by the processor. EPCM contains a mapping between each enclave and EPC page.
6 | Background
Figure 2-1: Intel®SGXG application
2.1.2 SGX2
SGX ensures confidentiality and integrity by isolatingn blocks of memory. However, the range of reserved memory must be committed by CPU before enclave initialization. After this memorry allocation is done, this allocation cannot changee. As a result, a developer must consider the maximum memorry required inside the enclave. However, lots of memmory will be wasted if the enclave does not fully use the allocate memory all the time. As a result, new instruction and progo ramminng models were introduced by Intel Corporation to extend SGX in order to support ddynamic memory management inside an enclave [2]. Compared with SGX1, SGX2 added 6 new leaf functions and splits memory managemeent into an Internal memory manager and an External memory manager. The internal memorry manager is used to make memory allocation change requests while the external memory manager will re-allocate memory to the enclave. With the help of the ooperating system and the external memoryr manager, an enclave gains the ability to allocate memory dynamically.
2.1.3 ECALL and OCALL
ECALL provides a means to call a trusted function in an enclave from an untrusted aapplication. Conversely, OCALL provides a function call from within an enclave to a function in the untrusted zone. After creating an enclave, the developer can define
Background | 7
inside the file enclave.edl both ECALL and OCALL functions that will be used in the project. Since both ECALL and OCALL functions must be ddefined before callinng, the developer should reduce the number of ECALL and OCALL to reduce the attacck surface.
2.2 TLS
Transport Layer Security (TLS) [3] is a prrotocol designed to provide communication confidentiality and ensure data integrity between two entity bby establishing a secure communiccation channel. The TLS protocol is suppported by a TLS handshake protocol and a TLS record layer protocol. The protocols mainlly depend on three basic algorithms: a hash function, asymmeetric encrypy tion, and symmetric encryption. As shown in Figure 2-2, asymmetric eencryption is used in the key exchange prrocess while subsequent transmissions are protected usinng symmetric encryption and the hash function. TLS libraries are designed to provide these crypptographic functions to suppp ort the TLS prootocol. The chosen cryptographhic functions are described in Section 3.3.
Figure 2-2: TLS protocol
2.2.1 Handshake protocol
The handshake protocol is designed to negotiate a security key via an exchange between a client and a server. In TLS version 1.2, as shown in Figure 2-3, the client starts the handshake process by sending a Client_Hello messaage. This Client_Hello message is sent in plain-text and includes a random number, a list of the different TLS versions supported by the client, a list of supported compression methods, and a list of suupported cipher suites. After receiving the Client_Hello message, the server generates a Server_Hello message. This message includes another random number and the selected TLS version, compression method,, and cipher suite. At the same time, the server sends its certificate to the client. Aftfter the client receives
8 | Background
a Server_Hello_Done message, but before it initiates the key exchange process, the cllient must verify the server’s certificate. The certificate’s expiiry date, domain, and trusted certificate path will be checked by the client. If the ceertificate is legitimate, then the client will initiate a keey exchange process with the server. The client tells the server that the subsequent communication will adopt the same compression method, ciipher suite, and encryption algorithm for encryypting data as were negotiated in the Server_Hello message. After the server finisshhes the keye exchange process (with the Server_Finish_Handshake message) all of the subsequent communication uses the agreed upon methods and keys.
Figure 2-3: Handshake protocol
2.2.2 Record layer protocol
The TLS record layeer protocol preserves confidentiality and ensures message integrity during communicatioon between the client and server. The record layeer protocol splits the data stream into a series of fragmments. A Message Authentication Code (MAC) algorithm is applied to the encrypted message before transmission in order to ensure that the message is not modified during the transfer.
Background | 9
2.2.3 AES-GCM
Advanced Encryption Standard (AES) - Galois/Counter Mode (GCM) is an encryption mode for symmetrric encrypttion. GCM mode is a widely used block cipher mode of operation for the AES symmetric key crypptographic algorithm. GCM mode uses a Counter mode with Galois Message AAuthentication Code (GMAC). AES-GCM has been proven to be a security symmetric encryption mode [4]. Compared with other block ciphher mode, GCM mode provides encryption confidentiality and integrity. Instead of using the current plaintext block and previous ciphertext block to encrypt a message block, GCM mode uses a counter. The counter’s value will be calculated in plaintext, then a bllock cipher is used to generate the ciphertext.
2.2.4 ECDH
Elliptic-curve Diffie–Hellman (ECDH) is a key agreement algorithm to ensure two entities exchange their shared secret while a third party cannot usurp it. The two entities generate their shared secret by using their private keey, elliptic curve, and the other entity’s public key exchanged via an insecure channel. Each entity maay use the shared secret they established to encrypt/decrrypy t messages while communicating via the insecure channel. As shown in Figure 2-4, Alice and Bob want to establish a confidential communication channel inside an insecure channel. In the first step, they choose a ttype of ellipi tic curve. Once the type of elliptic curve is settled, Alice and Bob generate their private key and generate their public keey using the curve. They exchangee their public keys and then use the other’s party’’s public key to calculate the shared secret. This shared seccret will be used to encrypt/decrypt messages sent via the insecure channel. ECDH is widelyl used as a key negotiation mechanism in conjunction with the TLS handshake protocol [3].
Figure 2-4: Elliptic-curve Diffie-Hellman
10 | Background
2.2.5 Trusted TLS libraries
Several trusted TLS libraries were selected and evaluated in this thesis project. The difference between trusted TLS libraries and normal TLS libraries is trusted libraries could only be called inside enclave and running inside enclave. In order to facilitate comparison, the TLS libraries should have a common application programming interface (API) (i.e., have the same function interfaces) and should support Intel SGX* . We conducted measurements and performed an evaluation of several trusted TLS libraries, specifically: Intel® SGX SSL [7], mbedtls-SGX[8], wolfSSL[9], and Intel® SGX SDK library. Intel SGX SSL is a cryptographic library based on the open source implementation OpenSSL [10] Intel SGX SSL provides cryptographic functions for enclave applications [7]. Mbedtls-SGX is a port from mbed TLS [11] with support for Intel SGX. Mbedtls-SGX has all the same feature as mbed TLS, including client-server TLS functions and cryptographic functions [8]. WolfSSL [9] is an open source embedded TLS library created by the company wolfSSL Inc. WolfSSL supports most cryptographic functions and different version of TLS. Intel SGX SDK library is a cryptographic library inside the Intel SGX SDK. It provides several cryptographic functions to support enclave applications [12]. LibreSSL [13] also supports enclave application but was not used in this project since we already had a cryptographic library based on the OpenSSL open source project. We present the reason why these libraries were selected in Section 3.2.
2.3 Side-channel attack
Data confidentiality and integrity are provided by SGX; however, SGX is vulnerable and unreliable against side-channel attacks [6]. A side-channel attack is a kind of attack based upon using side-channel information. The attacker takes advantage of side-channel information, such as power consumption, CPU cache modifications, or thermal energy emissions, to leak information about the key to the attacker. Such an attack is more efficient than traditional mathematical cryptography analysis attacks. Because the enclave shares the same resources with non-enclave applications, it may leak important enclave information to untrusted software or users. However, the nature of the side-channel attack makes it hard to detect and hard to defend against. For example, the attacker can make use of access to pages, cache, or Dynamic Random Access Memory (DRAM), or analyze power consumption to obtain data or code running inside the enclave. The threat from a software-based side-channel attack is obvious, thus the user should fully consider the risk of side-channel attacks on SGX before implementing an enclave to run
* Note that GnuTLS [5] does not support Intel® SGX [6].
Background | 11
secret code and store sensitive data. Note that in the case of TLS the most sensitive data is the keys that are used.
2.4 Related work
Several related works on Intel SGX, TLS libraries, and side-channel attacks are described in this section. Frank McKeen and his colleagues from Intel Corporation introduced an innovative software model for isolated execution [14]. In order to protect data confidentiality and integrity, together with some application code running inside a secret black box – they introduced an isolated environment protected by hardware attestation. In their paper, they mainly introduced the programming model. This model proved to be very valuable when we tried to implement an enclave environment. In[15], Ittai Anati and his colleagues presented a new technology allow secure attestation and execute some part of application software inside an enclave together with hardware-based attestation. Attestation includes a mechanism for the enclave to authenticate another party and a symmetric key system that provides attestation for an Inter-Platform enclave. Their paper also demonstrated how the EGETKEY function can be used to seal encrypted data. An updated version of Intel’s Software Guard Extensions was carried out by Frank McKeen and his colleagues from Intel Corporation [2]. They introduced Intel® Software Guard Extensions SGX2, a new processor architecture extension which supports dynamic memory management. They pointed out that in SGX1, the memory allocation had to be committed before the initialization of enclave. Thus when initializing the enclave, the developer must always consider the worst-case memory requirements. They also pointed out a shortcoming related to OS library support and management of access permission in SGX1. As a result, they introduced 6 new instruction leaf functions that support dynamic memory management. In this project we conducted our performance evaluation using an up to date version of SGX2, we present more details in Section 3.3. Yehuda Lindell demonstrated different kinds of side-channel attacks on SGX, specifically Page-based side channels, Cache-based channels, and Energy management attacks [16]. Page-based and Cache based side-channel attacks are well-known types of side-channel attack. Xu Y et al. [17] and Shweta Shinde et al. [18] also showed attacks on enclave execution based on the page side channel. F. Brasser et al. [19] and Schwarz M et al. [20] each showed a cache-based side- channel attack. Wenhao Wang et al. [21] showed a memory-based side-channel attack on SGX and presented 8 different attack vectors against memory management. An energy management attack is based on using energy management tools to determine power consumption. Adrian Tang, Simha Sethumadhavan, and Salvatore Stolfo from Columbia University presented a new class of side-channel
12 | Background
attack based on energy management [22]. Additionally, an attacker can inject faults in order to obtain cryptographic keys. Y. Xiao et al. revealed side-channel vulnerabilities to several open source SSL/TLS libraries running in SGX [6]. By testing different TLS libraries against Bleichenbacher’s attack and a Padding Oracle attack, they show that it is obvious that OpenSSL, GunTLS, mbed TLS, LibreSSL, and wolfSSL are all vulnerable to branch-level, cache line-level, and page-level side-channel attacks.
Methodologies and Methods | 13
3 Methodologies and Methods
The purpose of this chapter is to provide an overview of the research methodologies used in this thesis. Section 3.1 describes the research process. Section 3.2 details the project environment. Section 3.3 focuses on the cryptographic functions chosen for this research. Section 3.4 describes the measurements that were carried out. Section 3.5 explains the techniques used to evaluate the reliability and validity of the data collected. Finally, Section 3.6 describes the method used for data analysis.
3.1 Research Process
The research process started with an investigation of existing TLS libraries. The chosen TLS libraries support Intel SGX and offer APIs to be called from an application that wants to use an enclave. As shown in Section 3.3, several TLS library cryptographic functions were chosen for the measurements in this project. All of the selected cryptographic functions were measured both in trusted libraries and untrusted libraries. A performance evaluation of different TLS libraries will be done based upon these measurements. Based on the result of this evaluation, we will propose a new design which can achieve the highest performance for the TLS libraries when using Intel SGX.
3.2 Hardware, Software and TLS Libraries chosen
This section describes the hardware (Section 3.2.1), software (Section 3.2.2), and TLS libraries (Section 3.2.3) chosen for use in this thesis.
3.2.1 Hardware
Table 3-1 shows the test platform in this project. Notice that the processor must support Intel SGX. Before starting the implementation, “Enable SGX” was set in the Basic Input/Output System (BIOS). Table 3-1: Test platform
Lenovo Thinkpad T460s laptop CPU Intel®Core(TM) i7-6600U CPU @ 2.60 GHz System memory 12 GiB RAM BIOS setting Enable SGX Operating System Ubuntu 16.04.2
14 | Methodologies and Methods
3.2.2 Software
Table 3-2 shows the Intel SGX version chosen in this project. The additional software used in this project includes the Ubuntu Operating System version 16.04.2, gcc compiler version 5.4.0, R version 3.4.3, and Excel 2017. Sgx-perf [23] is a tool used for tracing enclave application execution during runtime. Sgx-perf will create an additional file during enclave application execution. By analysis of this file we could trace each ECALL’s and OCALL’s behavior with reard to the overall execution time. Table 3-2: Intel SGX version
Intel SGX Linux 2.2 Release Version name Linux 2.2 Open Source Release date 3 July 2018
3.2.3 Selected TLS libraries
Table 3-3 shows several common TLS libraries that support Intel SGX. From the result of a preliminary investigation, we selected wolfSSL and mbed TLS for the cryptographic libraries to be evaluated in this project. Furthermore, we included Intel SGX SSL as it is a cryptographic library build with open source OpenSSL. Table 3-3: Investigation of existing TLS libraries
WolfSSL Mbed TLS GnuTLS Libressl Intel SGX supporting Yes Yes No Yes
Table 3-4 shows the TLS libraries selected for evaluation in this project. Mbedtls-SGX is built with mbed TLS 2.6.0. Intel SGX SSL is built with Intel SGX Linux 2.2 Release and OpenSSL-1.1.0. The Intel SGX SDK library is a trusted library included with Intel SGX Linux 2.2 Release. The trusted libraries are static libraries that are linked with the enclave binary [24]. Since Intel SGX SSL only supports the newest version of Intel SGX, we chose the newest version 2.2 when the implementation starts (July 2018). Notice that we used OpenSSL 1.1.0 because we built the Intel SGX SSL library using OpenSSL 1.1.0 and Intel SGX SSL v2.2 was released before Intel SGX Linux 2.2 was released.
Methodologies and Methods | 15
Table 3-4: Chosen TLS libraries version
WolfSSL Mbed TLS Mbedtls-SGX Intel Intel OpenSS SGX SSL SGX L SDK library Version 3.14.0 2.9.0 mbedtls_SGX- 2.2 2.2 1.1.0 2.6.0 Release 3/02/2018 4/30/2018 11/14/2017 6/04/20 7/03/2 8/25/20 date 18 018 16 Build Self-build Self-build Mbed TLS OpenSS Intel Self- with 2.6.0 L-1.1.0 SGX build and Intel Linux SGX 2.2 Linux Release 2.2 Release Trusted Untrusted Untrusted libmbedtls_S libsgx_ts sgx_tcr Untrust library /libwolfssl GX_t.a gxssl.a ypto.a ed name .sgx.static. libsgx_ts lib gxssl_cr ypto.a
3.3 Selected functions from the TLS libraries
We selected several cryptographic functions for testing. This section describes why we select those functions for our evaluation of different TLS libraries. The selected functions were supported by all of the libraries listed in Table 3-4. The selected cryptographic functions in Table 3-5 were evaluated in both trusted libraries and untrusted libraries. Unlike SHA256, SHA1 and MD5 are both vulnerable to a collision attack [25– 27]. For this reason, in TLS 1.2 the MD5-SHA-1 combination in the message hash was replaced by SHA 256 [3]. RSA is widely used in asymmetric encryption and using it with 2048 bits is more secure than with 1024 bits. Both RSA and ECDH can be used as a key exchange solution in TLS 1.2 [33]. AES-GCM is a cipher Suites for TLS and is used as a symmetric encryption algorithm. AES-GCM provides encryption and integrity check of the message. Additionally, it can also provide an integrity check of other messages [28]. AES-
16 | Methodologies and Methods
GCM is a block ciphher mode recommended by the U.S. NNational Institute of Standards and Technology (NIST)[29]. Table 3-5: The cryptographic functions that were selected for testing
Selected cryptographic functions Generate an asymmetric key pair Generate 2048 bits RSA key pair Digit hash Calculatingn SHA-2556 digital hashes SSymmetric encryption/decryptiion AES-GCM encryption and decryption The asymmetric key exchange process ECDH process
3.4 Measurements
The execution time of each of the functions shown in Table 3-5 was measured for the untrusted application with untrusted libraries. As shownn in Figure 3-1, in the case of the trusted enclave appplication, the measurement starts from the ECALL function in the untrusted zone until the function has returned a value to the untrusted zone. The first test was to generate a 2048 bits RSA key pair whhen using each of the different TLS libraries. The time to perform this key pair generation was measured (in microseconds) for 10,000 calls of the function. For the Sha256 hash calculation, we built a plaintext geenerator annd calculated a hash for different messages in order to ensure that the result was not influenced by CPU caching.
Figure 3-1: Time measurement for untrusted/trusted library calls
Methodologies and Methods | 17
3.5 Assessing the reliability and validity of the data collected
Assessment of the data reliability and validity are described in this section.
3.5.1 Reliability
A large number of data samples were collected to support data reliability and all data is from the performance testing described in Section 3.4.
3.5.2 Validity
After calling the different cryptographic functions from within each TLS library, we checked the return value to ensure the cryptographic process is done successfully. If any cryptographic function returns an unexpected value the benchmark will print a test failed message and stop the process to alert the tester.
3.6 Data Analysis
R[30] was used to analyze the collected data. R is a programming language widely using in statistical analysis and statistical mapping. This project used R to calculate different statistical values and used both R and Excel 2017 to generate plots and graphs.
Implementation design | 19
4 Implementation design
This chapter describes the implementation of the tests used in this projeect. Section 4.1 describes the testing of the untrusted libraries and Sectiion 4.2 describes the testing of the trusted libraries.
4.1 Untrusted model
In the untrusted model, the library is unprotected as the libbrary is located in the untrusted zone. The client directly uses the API to call functions inside the TLS library or uses an OCALL in the enclave to call an untrusted function in the untrusted zone. As shown in Figure 4-1 and Figure 4-2, both types of untrusted models are vulnerable to the attacker. By attacking the untrusted library, the attacker can capture every message for Alice. The impm lementation shown in Figure 4-2 is not recommended. Moreover, this implementation may fail the enclave generation process and cause a run timeout for the enclave appplication. As described in Table 3-4, wolfSSL, mbed TLS, and OpenSSL were the selected untrusted TLS libraries used in the evaluation of this model. All functions shown in Table 3-5 are implemented in the first untrusted model, where Alice directly calls the API of each of the functions in the different TLS libraries.
Figure 4-1: Untrusted model: without enclave
20 | Implementation design
Figure 4-2: Untrusted model: Using OCALL from enclave
4.2 Trusted model
Mbedtls-SGX, Intel SGX SSL, Intel SGX SDK, and wolfSSL--SGX are the trusted libraries in our project. The invocation of these selected functions within the enclave is described in Section 4.2.1, and the configuration of the enclave is described in Section 4.2.2.
4.2.1 Using trusted library inside the enclave
As shown in Figure 4-3, the trusted libraryr is protected by the enclave. When Alice uses ECALL from untrusted zone to call the function in the enclave, the attacker cannot captture Alice’s messages by attacking TLS library since the enclave provides data confidentiality and integrrity in an independent executiion environment. All TLS functions are sealed in an ECALL function call from Alice. The core code of the cryptographhic functions is executed inside the enclave.
Implementation design | 21
Figure 4-3: Trusted model: Using ECALL from an untrusted application
4.2.2 Enclave configuration
Figure 4-4 shows the enclave configuration settings used in thhis project. The stack’s maximum size and the heap’s maximum size should be set laarge enough to avoid out of range memory accesses. These values and configuration could be found in a configuration file inside enclave application.
4.3 Cryptographic functions
This section reviews the four cryyptographic functions (listed in Table 4-1) that were immplemented in all TLS librariies and that were selected for making performance measurements. All of those functions are implemented in both the untrusted and trusted models (described earlier in Sections 4.1 and 4.2).. Each crypy tographic function was executed 10,000 times for each of the TLS libraries (and for both untrusted and trusted libraries)).
22 | Implementation design
Table 4-1: Cryptographic functions that were measured
Cryptographic function Description Generate 2048 bits RSA key pair Generate 2048 bit RSA key pairs. The key pair is stored in different libraries’ context. Calculating SHA-256 digital hashes Use SHA256 to calculate a digital hash for a message with 64B, 1KB, and 1MB of data. The message data is generated by a random string generator. AES-GCM encryption and decryption Use AES-GCM to both encrypt and decrypt 64B, 1KB, and 1MB data. The plain text is generated by a random String generator. ECDH process Finish an ECDH key exchange process. Generate two elliptic-curve private- public key pairs and calculate a common secret using both of them.
Results and Analysis | 23
5 Results and Analysis
This chapter presents the measurement results and discusses them. Section 5.1 shows the results of generating 2048-bit RSA key pairs. The results of calculating SHA-256 digital hashes are shown in Section 5.2. Section 5.3 presents the results of AES-GCM encryption and decryption. Section 5.4 gives the results of finishing the ECDH process. Section 5.5 presents the analysis of libraries in terms of both their performance and size. Sections 5.6 and 5.7 discuss the reliability and validity of the analysis. Section 5.8 summarizes the discussion of the analysis of the existing libraries. Finally, Section 5.9 presents the proposed new design based upon the dynamic selection of the library and Section 5.10 evaluates this new design. As described in Sections 4.1 and 4.2, we evaluated a set of function (as described in Table 4-1) in both untrusted libraries (mbed TLS, OpenSSL and wolfSSL) and trusted libraries (Mbedtls-SGX, Intel SGX SSL, Intel SGX SDK, and wolfSSL-SGX). Untrusted libraries are called from an untrusted zone (an unprotected user platform) while trusted libraries are called from a trusted zone (an enclave protected by hardware).
5.1 Results of generating 2048 bits RSA key pairs
The results of generating 2048-bit RSA key pairs by calling the appropriate function in the different TLS libraries are shown in Table 5-1. To ensure data reliability, we called the function to generate a 2048 bits RSA key pair 10,000 times for each cryptographic library. Table 5-1: Time to generate a 2048 bit RSA key pair from static data
Mbed Mbedtls- OpenSSL Intel SGX Intel SGX WolfSSL WolfSSL- TLS SGX (µs) SSL SDK (µs) SGX (µs) (µs) (µs) (µs) (µs)
Mean 112071 308350 81159 84098 115882 211747 286669 1st 57980 136148 41111 43961 57526 115455 151709 Quartile
Median 94919 239370 69190 71646 95481 183376 248092 3rd 148509 412599 107458 111405 153487 153487 374924 Quartile Standard 73950.1 245544.4 55067.4 56188.8 82569.9 131040.2 183422.4 deviation
Maximum 640997 2534354 502762 467807 687682 1118168 1484822
Minimum 6225 13732 3201 3487 2483 25943 25402
24 | Results and Analysis
5.1.1 Untrusted libraries performance
When generating a 2048 bit RSA key paair in an untrusted zone (as described in Section 4.1), we called the key-gen function directly from the untrusted zone. In the native expeeriment, all untrusted libraries were called from untrusted zone directly.. As shown in Figure 5-1, OpeenSSL has better performance than mbed TLS and wolfSSL. On averagee, it is 27.6% faster than mbed TLS and 61.7% faster than wolfSSL.
Figure 5-1: Generate 2048 bits RSA key pair in the untrusted zone
5.1.2 Trusted libraries performance
Figure 5-2 shows the result of generating 2048 bits RSA key pairs in the trusted zone (as described in Section 4.2). In this experiment, all of the trusted libraries were called from an isolated enclave. We compared the performance of mbedtls- SGX, wolfSSL-SGX, Intel SGX SDK cryptographic library, andd Intel SGX SSL. From Figure 5-2 and Table 5-1, we can observe that mbedtls-SGX takes more time than any other trusted library. In general, Intel SGX SSL has the best performance when generating 2048 bits RSA key pairs in the enclave (with a mmedian of 71646 µs). Compared with Intel SGX SSL, mbedtls-SGX is 266.7% sloowwer, wolfSSL-SGX is
Results and Analysis | 25
240.9% slower, and Intel SGXX SDK library is 37.8% slower.. The Intel SGX SDK library also has better performance than both mbedtls-SGX aand wolfSSL-SGX, as the time taken by the Intel SGX SDK library is 59.6% less than wolfSSL-SGX and 62.4% less than mbedtls-SGX.
Figure 5-2: Generate 2048 bits RSA key pair in the trusted zone
5.1.3 Comparison of trusted and untrusted libraries performance
In this section, we compare the difference between generatinng 2048 bits RSA keey pairs by using untrusted and trusted libraries. Mbed TLS was called from the untrusted zone while mbeedtls-SGX was called from enclave. As shown in Figure 5-3, the time taken by mbedtls-SGX is 175.1% slower than mbed TLS. WolfSSL was called from the untrusted zone while wolfSSL-SGX was called from the enclave. Comparing Figure 5-3 and Figure 5-4, we can see that the influence of the enclave is less for wolfSSL than for mbed TLS. On averagee, wolfSSL-SGX is 35.4% slower than wolfl SSL. However, wollfSSL is slower than mbed TLS as was mentioned in Section 5.1.1.
26 | Results and Analysis
Figure 5-3: Generate 2048 bits RSA key pair with mbed TLS/mbedtls-SGX
Figure 5-4: Generate 2048 bits RSA key pair with wolfSSL/wolfSSL –SGX
Results and Analysis | 27
Figure 5-5 shows the perfoormance of the Intel SGX SSL and Intel SGX SDK libraries whhen compaared againsst OpenSSL. Intel SGX SSL and Intel SGX SDK are trusted libraries and called from the enclave while OpenSSL was implemented as an untrusted library and hence is called from the untrusted zone. Intel SGX SSL is only 3.6% slower than OpenSS while the Intel SGX SDK library is 42.8% slower than OpenSSL.
Figure 5-5: Generate 2048 bits RSA key pair with OpenSSL based libraries and Intel SGX SDK library
5.2 Results of calculating SHA256 hashes
We used SHA-256 to calculate digital hashes for different message sizes: 64B (Section 5.2.1), 1KB (Section 5.2.2), and 1MB (Section 5.2.3). We tested each of the different TLS libraries 10,000 times for all three message siizes. In general, for a smmall message, wolfSSL-SGX is the best performance trusted library while OOpenSSL, Intel SGX SSL, and Intel SGX SDK all show great performance for large messages. Detailed results for different sized messages are given in Appeendix A.
5.2.1 Performance when calculating hashes for 64B data
Figure 5-6 shows the average time to calculate digital hashes for 64B messages. In general, wolfSSL is the best solution for this small message siize. Althougu h wolfSSL is slower than other untrussted libraries, wolfSSL-SGX shows much better
28 | Results and Analysis
performance compared with the other trusted libraries. Furthermore, wolfSSL shows less of a performance impact when executing within the enclave. For the untrusted libraries (mbed TLS, OpenSSL, and wolfSSL), mbed TLS has the best performance at only 1.3 µs. OpenSSL has a similar result at 1.4 µs. WolfSSL took 1.9 µs on average, only 0.6 µs behind mbed TLS. For the trusted libraries (mbedtls-SGX, Intel SGX SSL, Intel SGX SDK, and wolfSSL-SGX), wolfSSL-SGX has the best performance at only 2.4 µs, which is much faster than the other trusted libraries. Additionally, as noted earlier WolfSSL-SGX shows the smallest impact of running inside an enclave. The difference in execution time between wolfSSL and wolfSSL-SGX is extremely small (0.5 µs) when compared with the differences for other libraries. Compared with the origin untrusted library, mbed TLS and OpenSSL both show a huge performance decrease (8.9 µs for mbed TLS and 9.1 µs for OpenSSL).
Calculate SHA-256 for 64B data
14
12 10.5 10.2
10 8 Mbed TLS 8 Mbedtls-SGX
6 OpenSSL Intel SGX SSL
Microsecond Intel SGX SDK 4 1.9 2.4 WolfSSL 1.3 1.4 2 WolfSSL-SGX
0
-2
Figure 5-6: Calculating SHA-256 for 64B data
5.2.2 Performance when calculating hashes for 1KB of data
Figure 5-7 shows the results for hashes of 1KB of data. As shown in this figure, wolfSSL-SGX maintained its better performance among the trusted libraries and also shown less of an impact of running in an enclave. For the untrusted libraries, OpenSSL only took 4.8 µs on average, 31.4% faster than mbed TLS and 49.4% faster than wolfSSL.
Results and Analysis | 29
Calculate SHA-256 for 1KB data
30
24 25
20 Mbed TLS
15 Mbedtls-SGX 10.9 10.4 9.5 OpenSSL
Microsecond 7.6 Intel SGX SSL 10 7 Intel SGX SDK 4.8 WolfSSL 5 WolfSSL-SGX
0
Figure 5-7: Calculate SHA-256 for 1KB of data
5.2.3 Performance when calculating hashes for 1MB of data wolfSSL and wolfSSL-SGX is no longer the best solution for 1MB of data. Figure 5-8 shows that an OpenSSL based library is the best solution for 1MB of data. For the untrusted libraries, OpenSSL is faster than both mbed TLS and wolfSSL, while the time taken by mbed TLS is close to that of wolfSSL. When considering the trusted libraries, Intel SGX SSL and Intel SGX SDK took less time than the other two trusted libraries. Comparing the untrusted and trusted libraries, the OpenSSL based library and wolfSSL both showed less impact of running in the enclave than mbed TLS.
30 | Results and Analysis
Calculate SHA-256 for 1MB data
14000 11420 12000
10000 Mbed TLS 8000 Mbedtls-SGX 6000 4801 4891 4809 OpenSSL
Microsecond 2605 2620 Intel SGX SSL 4000 2610 Intel SGX SDK 2000 WolfSSL WolfSSL-SGX 0
Figure 5-8: Calculate SHA-256 for 1MB data
5.3 Results of AES-GCM encryption and decryption
The timing results for AES-GCM encryption and decryption are shown in this section. We used different libraries with AES-GCM to encrypt and decrypt three different sizes of data: 64B, 1KB, and 1MB. Before the start of each test 10,000 random data strings of each size were generated by a String generator. Subsequently, each of these strings was encrypted/decrypted by each of the different TLS libraries. In general, Intel SGX SSL, Intel SGX SDK, and wolfSSL-SGX all run very fast for small sized data while Intel SGX SSL is the best trusted library when handling large sized data. WolfSSL-SGX’s performance greatly decreased when the size of the plaintext increased. Details of the results for different sized messages are given in Appendix B.
5.3.1 Performance for AES-GCM encrypt/decrypt 64B of data
Figure 5-9 shows that among the untrusted libraries, both OpenSSL and mbed TLS showed great performance when encrypting a small amount of data. For the trusted libraries, wolfSSL-SGX and Intel SGX SDK take the same average time while Intel SGX SSL is only 0.5 µs behind. Compared with its untrusted library, wolfSSL-SGX maintains good performance in the enclave and is only 5.3% slower than wolfSSL. Among the untrusted libraries, mbed 64B data decryption (as shown in Figure 5-10) is 0.3 µs faster than OpenSSL on average while wolfSSL-SGX is the best
Results and Analysis | 31
trusted library at only 6.4 µs. Additionally, wolfSSL-SGX also shows the least impact of running in the enclave.
AES-GCM encrypt 64B data 14 11.8
12
10 8.4 7.9 7.9 7.5 Mbed TLS 8 Mbedtls-SGX
6 OpenSSL Intel SGX SSL
Microsecond Intel SGX SDK 4 1.9 WolfSSL 1 2 WolfSSL-SGX
0
-2
Figure 5-9: AES-GCM encryption for 64B data
AES-GCM decrypt 64B data 14 11.9
12
8.9 10 8.1 6.4 Mbed TLS 8 5.5 Mbedtls-SGX 6 OpenSSL
Microsecond Intel SGX SSL 4 Intel SGX SDK 1.9 1.6 WolfSSL 2 WolfSSL-SGX
0
Figure 5-10: AES-GCM decryption for 64B data
32 | Results and Analysis
5.3.2 Performance of AES-GCM encrypt/decrypt 1KB of data
Figure 5-11 shows the 1KB data encryption results. Among the untrusted libraries, OpenSSL took 1.3 µs while the best performance of the trusted libraries was shown by Intel SGX SSL which took 9 µs on average. Compared with the other trusted libraries, Intel SGX SDK also has an impressive performance at only 9.7 µs. Compared with other libraries, mbed TLS shows a large impact when executed in the enclave. In contrast, wolfSSL shows less impact when running in the enclave; however, wolfSSL and wolfSSL-SGX took much longer when compared with OpenSSL and the OpenSSL based library. As shown in Figure 5-12 the time for decryption of 1KB of data shows a similar result with encryption.
AES-GCM encrypt 1KB data
100 70.7 63.7 80 52.8 60 Mbed TLS Mbedtls-SGX 40 9.7 OpenSSL 6.7 1.3 9 20 Intel SGX SSL Microsecond 0 Intel SGX SDK WolfSSL -20 WolfSSL-SGX OpenSSL WolfSSL Mbed TLS Mbedtls-SGX WolfSSL-SGX Intel SGX SSL Intel SGX SDK Figure 5-11: AES-GCM encryption for 1KB data
AES-GCM decrypt 1KB data
90 69.7 80 61.1 70 52.9 60 50 Mbed TLS 40 Mbedtls-SGX 30 7 9.4 9.8 20 2.7 OpenSSL
Microsecond 10 Intel SGX SSL 0 Intel SGX SDK -10 -20 WolfSSL WolfSSL-SGX OpenSSL WolfSSL Mbed TLS Mbedtls-SGX WolfSSL-SGX Intel SGX SSL Intel SGX SDK
Figure 5-12: AES-GCM decryption for 1KB data
Results and Analysis | 33
5.3.3 Performance for AES-GCM encrypt/decrypt 1MB of data
Figure 5-13 shows that OpenSSL and the OpenSSL based library are the fastest libraries when encrypting and decrypting 1MB of data,. The difference in execution time between Intel SGX SSL and OpenSSL is only 198 µs, that means Intel SGX SSL shows little impact when running in the enclave when performing AES GCM encryption of 1MB data. Intel SGX SDK was faster than both wolfSSL-SGX and mbed TLS, and was close to the performance of Intel SGX SSL. Considering the other TLS libraries, both wolfSSL and wolfSSL-SGX took a much longer time. As shown in Figure 5-14, the decryption results are similar to the encryption results.
AES-GCM encrypt 1MB data 80000 70000 53859 57449 60000
50000 35442 Mbed TLS 40000 Mbedtls-SGX 30000 OpenSSL 20000 5460 Intel SGX SSL
Microsecond 341 698 10000 539 Intel SGX SDK WolfSSL 0 WolfSSL-SGX -10000 -20000 OpenSSL WolfSSL Mbed TLS Mbedtls-SGX WolfSSL-SGX Intel SGX SSL Intel SGX SDK Figure 5-13: AES-GCM encryption for 1MB data
AES-GCM decrypt 1MB data 80000 57456 70000 54208 60000 50000 35302 Mbed TLS Mbedtls-SGX 40000 OpenSSL 30000 Intel SGX SSL 20000 5356 331 670 Microsecond 528 Intel SGX SDK 10000 WolfSSL 0 WolfSSL-SGX -10000 -20000
Figure 5-14: AES-GCM decryption for 1MB data
34 | Results and Analysis
5.4 Results of ECDH process
This section discusses the result of timing the ECDH process. As presented in Section 2.2.4, to finish an ECDH process both Alice and Bob generate ECDH key pairs and calculate a common secret. Section 5.4.1 shows the result of ECDH process for each of the different TLS libraries while Section 5.4.2 further analyzes the ECDH process, showing the performance when generating only a single ECDH key pair. These results show that there is little influence of the key generation process on the overall delay of the whole ECDH process. As presented later in this section, OpenSSL and Intel SGX SSL are the best libraries for an ECDH key exchange process. Details of the results for the ECDH process and generation of key pairs are given in Appendix C.
5.4.1 Performance for ECDH
Figure 5-15 shows the performance of the ECDH process for the different TLS libraries. In the ECDH process, OpenSSL and Intel SGX SSL have great performance. Compared with the other untrusted libraries, OpenSSL only took 261 ms. Similarly, the OpenSSL based trusted library – Intel SGX SSL is the fastest trusted library for the ECDH process. Compared with mbedtls-SGX and wolfSSL- SGX, Intel SGX SDK was faster and took only 659 µs. For mbed TLS and mbedtls- SGX, the difference between the untrusted and enclave versions is obvious much higher (16350 µs) than for the other pairs of libraries (OpenSSL based with Intel SGX SSL: 167 µs and wolfSSL with wolfSSL-SGX: 1050 µs).
ECDH 30000
22517 25000
20000 Mbed TLS Mbedtls-SGX 15000 OpenSSL Intel SGX SSL 10000 6167
Microsecond 4754 Intel SGX SDK 3704 WolfSSL 5000 261 428 659 WolfSSL-SGX
0
-5000
Figure 5-15: ECDH process
Results and Analysis | 35
5.4.2 Performance for generating ECDH key pair
While Section 5.4.1 showed the performance of the complete ECDH process (generating an ECDH key pair and calculating a common secret), this section looks closer at the performance of the ECDH process. Comparing Figure 5-15 and Figure 5-16, we observe that the performance when generating an ECDH key pair does not completely explain the time differences between the libraries’ performance for the complete ECDH process, the difference in time must be due to the time to generate a common secrete.
Generate key pair for ECDH 14000 10994 12000
10000
8000 Mbed TLS Mbedtls-SGX 6000 OpenSSL 3137 Intel SGX SSL 4000 1788 2372 Intel SGX SDK
Microsecond WolfSSL 84 360 2000 127 WolfSSL-SGX
0
-2000
-4000 Figure 5-16: Time to generate a ECDH key pair
5.5 Analysis of the performance of the libraries
In this section, the performance of the libraries is characterized in terms of both performance and size.
5.5.1 Performance
In this section, we evaluated the execution time of the same code in the untrusted and enclave applications by splitting out the ECALL time and the time required for passing data into the enclave. By calling the same cryptographic functions from the different TLS libraries, we measured the performance difference between an untrusted library and trusted library (e.g., after extracting the ECALL duration for wolfSSL-SGX and then comparing the results with wolfSSL we measured the performance difference between the untrusted and trusted wolfSSL library).
36 | Results and Analysis
We used sgx-perf [23] to analyze the ECALL duration time. Table 5-2 shows the overall execution time for trusted libraries after 10000 AES-GCM 64B encryption ECALLs. The overall execution time for 10000 empty ECALLs when passing and storing 64 bytes data inside the enclave is 63816122 ns (~63 ms). Note that sgx-perf adds an ECALL logger before the ECALL started. From [23] we learned that the overhead of this logger is around 1366ns on average for each call (in total 13.660 ms). As a result, the overall execution time of 10000 ECALLs when passing and storing 64 bytes data inside the enclave is 50156122 ns (~50 ms). By factoring out the ECALL duration and the time required for passing data into the enclave, we can calculate the execution time for AES-GCM encryption of 64 bytes inside the enclave. For wolfSSL-SGX, combined with the overall execution time and ECALL duration time, the execution time for AES-GCM encryption inside the enclave is a ~34 ms (84 ms -50 ms) which leads to 3.4 µs per encryption. Compared with the execution time for AES-GCM encryption of 64 bytes in the untrusted zone (~7.5 µs as shown in Figure 5-9 on page 31), we can see that executing the cryptographic functions from within the trusted wolfSSL-SGX takes less time than calling the same functions in the untrusted wolfSSL library after subtracting the ECALL duration and data passing time. However, Intel SGX SSL and Mbedtls-SGX exhibit a performance decrease when running in the enclave compared with running outside the enclave. Notice that when considering the general performance of a trusted library we still need to include the ECALL duration time because that is part of the total execution time for an enclave application. This explains why we conducted our previous experiments (as described in Section 3.4) while including the ECALL execution time. Table 5-2: Execution time for 10000 AES-GCM 64B encryption ECALLs
Mbedtls-SGX WolfSSL- Intel SGX Intel SGX (ms) SGX SSL SDK (ms) (ms) (ms) Time for 155 84 107 110 10000 ECALLs
5.5.2 Size
Using small linked libraries can reduce memory consumption and save resources. Table 5-3 shows the size of different TLS cryptographic libraries. Comparing these results with the previous performance results, we can see that there is a trade-off between the libraries’ size and cryptographic performance. OpenSSL has the best performance of the untrusted cryptographic libraries; however, the OpenSSL library is much larger than wolfSSL and mbed TLS. WolfSSL-SGX is the smallest trusted cryptographic library at only 849 kB. Although Intel SGX SSL is 4 times larger than wolfSSL-SGX, Intel SGX SSL has high performance for most
Results and Analysis | 37
cryptographic functions. The trusted cryptographic library mbedtls-SGX is 1.9 MB, but the performance of cryptographic performance of mbedtls-SGX is far behind Intel SGX SSL. Table 5-3: TLS libraries’ size
WolfSSL wolfSSL- Mbed Mbedtls- OpenSSL Intel Intel SGX SGX TLS SGX SGX SSL SDK 396kB 849kB 588kB 1.9MB 5.1MB 4.7MB 18.1MB
5.6 Reliability Analysis
As described in Sections 3.5.1 and 4.3, each cryptographic function has been executed 10,000 times for each TLS library to ensure data reliability. Notice that the maximum and minimum time for generating 2048 bits RSA key pair are so far apart, instead of drawing a bar chart with an average value of the 10000 measurements we used a boxplot to show the distribution of values.
5.7 Validity Analysis
All functions called from TLS libraries return a value check; if the returned value is not the correct value, then the program will shut down and display an error message. During our testing, no error messages were output, and all the data was valid. Furthermore, in the ECDH test, we also have a common secret check after the ECDH key exchange process. We inspected the secret shared between Alice and Bob to ensure that the secret was equal and it was, hence the ECDH process is valid.
5.8 Discussion of the analysis for the individual libraries
In general, OpenSSL and Intel SGX SSL are the best solutions for Intel SGX. OpenSSL is the fastest untrusted library and can be called from an untrusted zone while Intel SGX SSL is the fastest trusted library and must be executed in an enclave. WolfSSL-SGX is good at handling small sized data. If the plaintext size is small, then wolfSSL-SGX has better performance than both Intel SGX SSL and Intel SGX SDK. Additionally, wolfSSL-SGX shows a smaller impact of execution within an enclave. Intel SGX SDK has great performance for each of the different cryptographic functions. In comparison with the other TLS libraries, Intel SGX SDK has the advantage that the user does not need to install the library – as this library is installed and configured when the user configured Intel SGX. The user can directly call the functions in this trusted library. Mbed TLS is unsuitable for enclave application. Although mbed TLS is even faster than OpenSSL in calculating 64B digital hashes and AES-GCM 64B
38 | Results and Analysis
decryption, mbedtls-SGX suffers from a large performance decrease when run in an enclave. Of all of the tested cryptographic functions, mbedtls-SGX took the longest time - although in some cases mbed TLS is very fast.
5.9 TLS library selection - a new design for implementing TLS libraries on Intel SGX
This section proposes a new design for implementing TLS libraries on Intel SGX. This new design is based on the analysis present in the previous sections. Figure 5-17 shows the proposed design with a libraries controller inside the enclave. Instead of directly calling the cryptographic functions of the TLS libraries, the request is first processed by the libraries controller. If the request is for processing of a small amount of data, then the libraries controller will call the cryptographic functions from wolfSSL-SGX. Otherwise it will call the function from Intel SGX SSL. These two implementations were chosen since both wolfSSL-SGX and Intel SGX SSL showed a small impact on their execution when running inside an enclave and they have better performance than the other TLS libraries. Although Intel SGX SSL is overall the best performance library, it only supports the most common cryptographic functions (as will be described in Section 6.2). A solution to overcome the functional limitations of Intel SGX SSL is to use wolfSSL-SGX. WolfSSL-SGX supports all functionality of wolfSSL. The libraries controller is sealed inside the enclave. This controller checks the size of the input data. The enclave ensures that an attacker cannot access the result or even know which trusted library was called. For portability, Intel SGX SSL is built with OpenSSL while wolfSSL-SGX also supports the OpenSSL API functions [31]. The OpenSSL cryptographic context is also protected inside enclave, and this context is shared between Intel SGX SSL and wolfSSL-SGX. By using the highest performance trusted TLS library for each specific cryptographic function, the highest performance will be ensured while maintaining versatility.
Results and Analysis | 39
Figure 5-17: A new implementation design for TLS libraries
5.10 Evaluation of proposed design
The proposed designn adds two overhead to the previous execution times: (1) the time required by the libraries controller and (2) the call of the actual library. Table 5-4 shows an evaluation of the proposed design when calculatiion a SHA-256 digital hash. Experiments show that for a hash of 64B of data the extra execution time due to the libraries controller is only 0.4 µss. Note that the maajjor cost of making a decision about which library too call for a given function is to determine the size of the input – which is linear with the size of the input data. FFor 1MB of data, the extra execution time due to the libraries controller is 14 µs, far less than the execution time for the cryptograaphic call from Intel SGX SSL liibrary.
40 | Results and Analysis
Table 5-4: Evaluation of proposed design for SHA-256 with different size of data (all timings in µs)
Bytes of data 64B 1KB 1MB Controlled library 2.8 8.1 2634 WolfSSL-SGX 2.4 7.6 4809 Intel SGX SSL 10.5 10.9 2620 The extra 0.4 0.5 14 execution time due to libraries controller
Plotting the data from Table 5-4 as shown in Figure 5-18 we can see that the controller library has approximately the same performance as the better of the two libraries at each point. The difference in performance is (as noted above) due to the overhead of computing the size of the input data. This cost is 10-5 µs per byte+ 0.4429 µs of overhead for the controller library and the call of the actual library. We can also see that the cross over point between the two cryptographic libraries is slightly below 4096 bytes (i.e., 4KB). By solving the two linear equation displayed in Figure 5-18, we get a cross-over point of around 3258 bytes. However, we found that for 3258 bytes data, the time cost for Intel SGX SSL is 2.5 µs faster than wolfSSL-SGX. As a result, we performed additional measurements to refine the cross-over point more precisely. To find a precise cross-over point, we performed extra measurements for both wolfSSL-SGX and Intel SGX SSL. Plotting the extra data from Table 5-5 as shown in Figure 5-19, and by solving the new linear equation, we calculate a precise cross- over point at 2984 Bytes for wolfSSL-SGX and Intel SGX SSL.
Table 5-5: Extra measurements for wolfSSL-SGX and Intel SGX SSL (all timings in µs)
Bytes of data 64B 256B 1KB 2KB 3258B 4KB 1MB WolfSSL-SGX 2.4 3.6 7.6 13.4 19.2 23.4 4809 Intel SGX SSL 10.5 10.7 10.9 16.5 16.7 19.4 2620
Results and Analysis | 41
After setting the boundary value to 2984 bytes, we re-evaluated the proposed design for different sized data. Plotting the data from Table 5-6 in Figure 5-20, we observed that at the cross-over point wolfSSL-SGX took 17.5 µs while the controlled library was using wolfSSL-SGX and was only 0.4 µs slower than Intel SGX SSL. For data larger than 2984 bytes, the controlled library used Intel SGX SSL and for 4096 bytes of data the controlled library was only 1.8 µs slower than wolfSSL-SGX. Considering large sized data (i.e., 1 MB), the controlled library will use Intel SGX SSL and the extra execution time of the controlled library is much less than the time of the origin trusted library. Table 5-6: A new evaluation of proposed design for SHA-256 with different size of data (all timings in µs)
Bytes of data 64 256 1024 2048 2984 4096 1048576 Controlled library 2.8 4.1 8.1 13.7 18.6 25.2 2634 WolfSSL-SGX 2.4 3.6 7.6 13.3 17.5 23.4 4809 Intel SGX SSL 10.5 10.7 10.9 16.5 18.2 19.4 2620 The extra execution time due to libraries controller 0.4 0.5 0.5 0.4 1.1 4.8 14
The controlled library was implemented with wolfSSL-SGX and Intel SGX SSL. The combination of the controlled library and the two trusted libraries will use more memory (in total 6.6 MB). However, it achieves high performance and realizes the desired cryptographic functionality.
Results and Analysis | 42
10000 y = 0.0046x + 2.5062 R² = 1
1000 y = 0.0025x + 9.3461 R² = 1
100
y = 1E-05x + 0.4429 R² = 1
10 Controlled library WolfsslSGX
IntelSGXSSL
1 The extra execution time due to libraries controller Linear (WolfsslSGX)
Linear (IntelSGXSSL) 0.1 1864 512 4096 32768 262144 Linear (The extra execution time due to libraries controller)
Figure 5-18: Performance plots
Results and Analysis | 43
10000 y = 0.0046x + 3.3905 R² = 1
1000 y = 0.0025x + 9.6586 R² = 1
WolfsslSGX 100 IntelSGXSSL Linear (WolfsslSGX)
Execution time in μs Execution Linear (IntelSGXSSL) 10
1 1 4 16 64 256 1024 4096 16384 65536 262144 1048576 Byte of data
Figure 5-19: Extra measurements for WolfSSL-SGX and Intel SGX SSL
44 | Results and Analysis
10000
Controlled library
1000 WolfsslSGX
IntelSGXSSL 100
Extra execution time for controlled library
10 Linear (Controlled library) Execution time in μs Execution Linear (WolfsslSGX) 1 Linear (IntelSGXSSL)
0.1 Linear (Extra execution time for controlled 1 4 16 64 256 1024 4096 16384 65536 262144 1048576 library) Byte of data
Figure 5-20: Evaluation of controlled library performance plot
Conclusions and Future work | 45
6 Conclusions and Future work
This chapter concludes this Master’s thesis. Section 6.1 describes the conclusions derived after reflecting on the results shown in Chapter 5. Section 6.2 presents some limitations of this Master’s thesis. Section 6.3 suggests future work that could build upon this project. Section 6.4 gives some reflections on this project.
6.1 Conclusions
The TLS library provides data confidentiality and integrity during communication. Additionally, Intel SGX is a popular solution for TEE. This thesis made a performance analysis of several different untrusted and trusted TLS libraries when running with Intel SGX and proposed a design for implementing TLS libraries on Intel SGX. Comparing all of the trusted libraries that support Intel SGX enclave applications, Intel SGX SSL is the fastest trusted library. Intel SGX SSL has great performance when generating 2048-bit RSA key pairs, the ECDH process, computing SHA256 digital hashes for large message, and when performing AES-GCM encryption/decryption for large amounts of data. Intel SGX SDK also had great performance when compared with the other trusted libraries. However, Intel SGX SDK is not recommended due to the limitations of its cryptography functions (as will be described in the next section). Moreover, wolfSSL-SGX is a good trusted library based upon wolfSSL, and it shows little additional delay due to running in an enclave. Additionally, wolfSSL-SGX has great performance when calculating SHA256 hashes for small sized data and AES-GCM encryption/decryption of small-sized data. The project failed to achieve one of its purposes, which was to improve the best of the libraries. Instead, the proposed solution is to dynamically invoke the best of the libraries for each specific function call. The new proposed design for implementing TLS libraries on SGX ensures both high performance and realized the full functionality of TLS libraries.
6.2 Limitations
One of the limitations of SGX is due to the CPU limitations of the platform. We implemented all projects in one CPU core. As a result, all the TLS Libraries and enclave application run in one CPU core. Hence their threads may influence each other. It would be better to implement the different TLS libraries on different CPU cores and run different security contexts’ computations on those different cores to reduce the influence between different threads. It should be noted that avoiding sharing of a CPU core reduces the risk of some side-channel attacks. The evaluation used a call to gettimeofday() on a 64-bit Linux operating system and thus the time measurements are in units of a microsecond. One drawback is the time taken for performing a given cryptographic function on small amounts of
46 | Conclusions and Future work
data could be smaller than 1 microsecond. This returns a value of zero for the test result. One means of getting higher resolution timing would be to use the Intel processor’s Time Stamp Counter (TSC) [32]. TSC was not used in the original measurements because we expected that microsecond resolution is sufficient for this project. Another limitation is that the cryptography functions provide by Intel SGX SDK library and Intel SGX SSL are quite limited. The Intel SGX SDK library only includes the cryptography functions used by other trusted libraries, such as the sgx_tservice library [12]. More specifically, it only has those cryptography functions listed in the developer reference manual for Intel SGX [12]. Intel SGX SSL only includes the most common cryptography functions, specifically those listed in the Intel SGX SSL library Linux developer guide [7]. As a result, we only tested and analyzed four cryptographic functions that are widely used in TLS 1.2. However, these functions are most of the cryptographic functions used in TLS 1.2, and they are the most frequently used functions (hence there performance will have the greatest impact on an application’s performance).
6.3 Future work
Due to platform limitations, we only implemented and called ECDH functions from a single enclave application. In the future, it would be good to have multiple clients creating enclave applications and finish the ECDH key exchange process on a different platform. One of the original proposes for this Master’s thesis was to improve the best trusted library’s performance on Intel SGX. However, this was not done. Therefore, a clear topic for future work is to optimize the best performance libraries. Although Intel SGX SSL has shown the best general performance on Intel SGX, it has limited functionality as described in Section 6.2. In the future, additional work should either transfer more cryptographic functions from OpenSSL to Intel SGX SSL or improve wolfSSL-SGX performance on Intel SGX. Due to limited competence, a security analysis of new proposed was not done. Although Intel SGX SSL is the fastest trusted library, it may not be the safest trusted library. Although trusted libraries are running inside an enclave protected by hardware, as described in Chapter 2, SGX and TLS libraries are vulnerable to side channel attacks. The different trusted TLS libraries may have different resistance against side-channel attacks and could potentially be engineered to reduce the risk of side-channel attacks. However, this type of analysis and design are far outside the scope of this Master’s thesis project.
6.4 Reflections
This section concludes the thesis with some reflections on aspects of ethics and sustainability relevant to this project.
Conclusions and Future work | 47
6.4.1 Ethical aspects
This Master’s thesis aimed to improve TLS libraries’ performance on SGX. TLS ensures user data integrity and confidentiality. Maintaining data integrity and confidentiality is important for preserving a user’s personal information and enabling them to communicate this data to only those that they choose to. Additionally, in the approach described in this thesis the data’s privacy is guaranteed by the hardware protection of both the code and data in the enclave. In theory, by storing the user’s private key(s) inside the enclave and only using them within the enclave the level of security is increased over storing and using the private key(s) outside of the enclave. However, as noted earlier in the thesis there are side-channel attacks that can be mounted against SGX and this thesis has not done any study of the actual security of storing the keys inside the enclave.
6.4.2 Economic aspects
The proposed design provides the highest performance for TLS libraries while maintaining cryptographic functionality on Intel SGX by using open source code. As a result, anyone could reproduce the results of this study, and anyone can exploit this improved performance in their applications. As TLS is very widely used for securing communication to/from websites and for VPN, the economic impact of high performance translates to costs savings (1) in time spend by users & applications and (2) reduces the amount of hardware needed to service a given number of TLS connections.
References | 49
References
[1] ‘Intel SGX Homepage | Intel® Software’. [Online]. Available: https://software.intel.com/en-us/sgx. [Accessed: 10-Apr-2018]
[2] Frank McKeen, Ilya Alexandrovich, Ittai Anati, Dror Caspi, Simon Johnson, Rebekah Leslie-Hurd, and Carlos Rozas, ‘Intel® Software Guard Extensions (Intel® SGX) Support for Dynamic Memory Management Inside an Enclave’, in Proceedings of the Hardware and Architectural Support for Security and Privacy 2016, New York, NY, USA, 2016, pp. 10:1–10:9 [Online]. DOI: 10.1145/2948618.2954331
[3] T. Dierks and E. Rescorla, The Transport Layer Security (TLS) Protocol Version 1.2. IETF, 2008, Request for Comments 5246 [Online]. Available: http://www.ietf.org/rfc/rfc5246.txt
[4] David A. McGrew and John Viega, ‘The Security and Performance of the Galois/Counter Mode (GCM) of Operation’, in Progress in Cryptology - INDOCRYPT 2004, vol. 3348, A. Canteaut and K. Viswanathan, Eds. Berlin, Heidelberg: Springer Berlin Heidelberg, 2004, pp. 343–355 [Online]. DOI: 10.1007/978-3-540-30556-9_27
[5] ‘gnutls.org’. [Online]. Available: https://www.gnutls.org/index.html. [Accessed: 10-Apr-2018]
[6] Yuan Xiao, Mengyuan Li, Sanchuan Chen, and Yinqian Zhang, ‘Stacco: Differentially Analyzing Side-Channel Traces for Detecting SSL/TLS Vulnerabilities in Secure Enclaves’, arXiv:1707.03473 [cs], pp. 859–874, 2017 [Online]. DOI: 10.1145/3133956.3134016
[7] intel-sgx-ssl: Intel® Software Guard Extensions SSL. Intel Corporation, 2018 [Online]. Available: https://github.com/intel/intel-sgx-ssl. [Accessed: 10-Apr-2018]
[8] Fan, mbedtls-SGX: a SGX-friendly TLS stack (ported from mbedtls). 2018 [Online]. Available: https://github.com/bl4ck5un/mbedtls-SGX. [Accessed: 10-Apr-2018]
[9] ‘wolfSSL Embedded SSL/TLS Library | Now Supporting TLS 1.3’, wolfSSL. [Online]. Available: https://www.wolfssl.com/. [Accessed: 10-Apr-2018]
[10] ‘OpenSSL,Cryptography and SSL/TLS Toolkit’. [Online]. Available: https://www.openssl.org/. [Accessed: 11-Jan-2019]
[11] ‘SSL Library mbed TLS / PolarSSL’. [Online]. Available: https://tls.mbed.org/. [Accessed: 11-Jan-2019]
50 | Detailed results for SHA-256 hashes
[12] ‘Intel(R) Software Guard Extensions Developer Reference for Linux* OS’, p. 119, Jul. 2018.
[13] ‘LibreSSL’. [Online]. Available: http://www.libressl.org/. [Accessed: 10- Apr-2018]
[14] Frank McKeen, Ilya Alexandrovich, Alex Berenzon, Carlos V. Rozas, Hisham Shafi, Vedvyas Shanbhogue, and Uday R. Savagaonkar, ‘Innovative Instructions and Software Model for Isolated Execution’, in Proceedings of the 2Nd International Workshop on Hardware and Architectural Support for Security and Privacy, New York, NY, USA, 2013, pp. 10:1–10:1 [Online]. DOI: 10.1145/2487726.2488368
[15] Ittai Anati, Shay Gueron, Simon P Johnson, and Vincent R Scarlata, ‘Innovative Technology for CPU Based Attestation and Sealing | Intel® Software’, in Proceedings of the Hardware and Architectural Support for Security and Privacy 2013 [Online]. Available: https://software.intel.com/en-us/articles/innovative-technology-for-cpu- based-attestation-and-sealing. [Accessed: 10-Apr-2018]
[16] Yehuda Lindell, ‘The Security of Intel SGX for Key Protection and Data Privacy Applications’, p. 13, Aug. 2018 [Online]. Available: https://cdn2.hubspot.net/hubfs/1761386/security-of-intelsgx-key- protection-data-privacy-apps.pdf
[17] Yuanzhong Xu, Weidong Cui, and Marcus Peinado, ‘Controlled-Channel Attacks: Deterministic Side Channels for Untrusted Operating Systems’, in 2015 IEEE Symposium on Security and Privacy, San Jose, CA, 2015, pp. 640–656 [Online]. DOI: 10.1109/SP.2015.45
[18] Shweta Shinde, Zheng Leong Chua, Viswesh Narayanan, and Prateek Saxena, ‘Preventing Page Faults from Telling Your Secrets’, in Proceedings of the 11th ACM on Asia Conference on Computer and Communications Security - ASIA CCS ’16, Xi’an, China, 2016, pp. 317–328 [Online]. DOI: 10.1145/2897845.2897885
[19] Ferdinand Brasser, Urs Müller, Alexandra Dmitrienko, Kari Kostiainen, Srdjan Capkun, and Ahmad-Reza Sadeghi, ‘Software Grand Exposure: SGX Cache Attacks Are Practical’, in 11th USENIX Workshop on Offensive Technologies (WOOT 17), Vancouver, BC, 2017 [Online]. Available: https://www.usenix.org/conference/woot17/workshop- program/presentation/brasser
[20] Michael Schwarz, Samuel Weiser, Daniel Gruss, Clémentine Maurice, and Stefan Mangard, ‘Malware Guard Extension: Using SGX to Conceal Cache
Detailed results for SHA-256 hashes | References51
Attacks’, in Detection of Intrusions and Malware, and Vulnerability Assessment, vol. 10327, M. Polychronakis and M. Meier, Eds. Cham: Springer International Publishing, 2017, pp. 3–24 [Online]. DOI: 10.1007/978-3-319-60876-1_1
[21] Wenhao Wang, Guoxing Chen, Xiaorui Pan, Yinqian Zhang, XiaoFeng Wang, Vincent Bindschaedler, Haixu Tang, and Carl A. Gunter, ‘Leaky Cauldron on the Dark Land: Understanding Memory Side-Channel Hazards in SGX’, in Proceedings of the 2017 ACM SIGSAC Conference on Computer and Communications Security - CCS ’17, Dallas, Texas, USA, 2017, pp. 2421–2434 [Online]. DOI: 10.1145/3133956.3134038
[22] Adrian Tang, Simha Sethumadhavan, and Salvatore Stolfo, ‘CLKSCREW: Exposing the Perils of Security-Oblivious Energy Management’, in 26th USENIX Security Symposium (USENIX Security 17), Vancouver, BC, 2017, pp. 1057–1074 [Online]. Available: https://www.usenix.org/conference/usenixsecurity17/technical- sessions/presentation/tang
[23] Nico Weichbrodt, Pierre-Louis Aublin, and Rüdiger Kapitza, ‘Sgx-perf: A Performance Analysis Tool for Intel SGX Enclaves’, in Proceedings of the 19th International Middleware Conference, New York, NY, USA, 2018, pp. 201–213 [Online]. DOI: 10.1145/3274808.3274824
[24] Intel, ‘Trusted Libraries’, Intel® Software Guard Extensions SDK, 07:00:00 UTC. [Online]. Available: https://software.intel.com/en-us/sgx-sdk-dev- reference-trusted-libraries. [Accessed: 26-Sep-2018]
[25] Gaoli Wang, ‘Collision Attack for the Hash Function Extended MD4’, in Information and Communications Security, vol. 7043, S. Qing, W. Susilo, G. Wang, and D. Liu, Eds. Berlin, Heidelberg: Springer Berlin Heidelberg, 2011, pp. 228–241 [Online]. DOI: 10.1007/978-3-642-25243-3_19
[26] Xiaoyun Wang, Yiqun Lisa Yin, and Hongbo Yu, ‘Finding Collisions in the Full SHA-1’, in Advances in Cryptology – CRYPTO 2005, vol. 3621, V. Shoup, Ed. Berlin, Heidelberg: Springer Berlin Heidelberg, 2005, pp. 17–36 [Online]. DOI: 10.1007/11535218_2
[27] Xiaoyun Wang and Hongbo Yu, ‘How to Break MD5 and Other Hash Functions’, in Advances in Cryptology – EUROCRYPT 2005, vol. 3494, R. Cramer, Ed. Berlin, Heidelberg: Springer Berlin Heidelberg, 2005, pp. 19– 35 [Online]. DOI: 10.1007/11426639_2
52 | Detailed results for SHA-256 hashes
[28] Joseph A. Salowey, David McGrew, and Abhijit Choudhury, AES Galois Counter Mode (GCM) Cipher Suites for TLS. RFC Editor, 2008, Request for Comments 5288 [Online]. DOI: 10.17487/RFC5288
[29] Morris J. Dworkin, ‘SP 800-38D. Recommendation for Block Cipher Modes of Operation: Galois/Counter Mode (GCM) and GMAC’, National Institute of Standards & Technology, Gaithersburg, MD, United States, 2007.
[30] ‘R: The R Project for Statistical Computing’. [Online]. Available: https://www.r-project.org/. [Accessed: 16-Oct-2018]
[31] ‘wolfSSL User Manual | Chapter 13: OpenSSL Compatibility Layer | Docs’. [Online]. Available: https://www.wolfssl.com/docs/wolfssl-manual/ch13/. [Accessed: 20-Dec-2018]
[32] Gabriele Paoloni, ‘Code Execution Times: IA-32/IA-64 Instruction Set Architecture’, Intel, Sep-2010. [Online]. Available: https://www.intel.com/content/www/us/en/embedded/training/ia-32-ia- 64-benchmark-code-execution-paper.html. [Accessed: 20-Dec-2018]
Detailed results for SHA-256 hashes | 53
Appendix A. Detailed results for SHA-256 hashes
Appendix A-1: Calculate SHA-256 for 64B data
Mbed Mbedtls- OpenSSL Intel SGX Intel SGX WolfSSL WolfSSL- Dynamic TLS SGX (µs) SSL SDK (µs) SGX Switch (µs) (µs) (µs) (µs) (µs) library (µs)
Mean 1.3 10.2 1.4 10.5 8.0 1.9 2.4 2.8
Min 0 7 0 6 6 0 1 1
1stqu 1.0 9.0 1.0 8.0 7.0 1.0 2.0 2
Median 1.0 10.0 1.0 9.0 8.0 1.0 2.0 3
3stqu 2.0 10.0 1.0 9.0 9.0 2.0 3.0 3
Max 53 149 135 356 62 355 89 33
Standard 0.9608 3.1813 2.1386 7.5574 1.8273 4.1026 1.1789 1.2429 deviatio n
Appendix A-2: Calculate SHA-256 for 1KB data
Mbed Mbedtls- OpenSSL Intel SGX Intel SGX WolfSSL WolfSSL- Dynamic TLS SGX (µs) SSL SDK (µs) SGX Switch (µs) (µs) (µs) (µs) (µs) library (µs)
Mean 7.0 24.0 4.8 10.9 10.4 9.5 7.6 8.1
Min 5 18 2 9 8 5 6 6
1stqu 6.0 19.0 3.0 9.0 9.0 5.0 7.0 6
Median 6.0 21.0 5.0 10.0 10.0 6.0 7.0 7
3stqu 7.0 27.0 6.0 12.0 12.0 9.0 7.0 10
Max 89 350 148 277 84 101 41 70
Standard 3.6392 6.8675 2.6226 4.1874 2.5872 8.6467 1.8057 2.5273 deviatio n
54 | Detailed results for SHA-256 hashes
Appendix A-3: Calculate SHA-256 for 1MB data
Mbed Mbedtls- OpenSSL Intel SGX Intel SGX WolfSSL WolfSSL- Dynamic TLS SGX (µs) SSL SDK (µs) SGX Switch (µs) (µs) (µs) (µs) (µs) library (µs)
Mean 4801 11420 2605 2620 2610 4891 4809 2634
Min 4591 10523 2351 2375 2367 4544 4518 2368
1stqu 4646 10932 2506 2502 2496 4750 4655 2503
Median 4703 11115 2532 2544 2536 4810 4711 2546
3stqu 4813 11778 2601 2637 2616 4912 4832 2642
Max 15994 22874 12130 7533 5552 12446 10076 9040
Standard 269.9887 812.3230 254.0156 248.1780 242.3059 302.7528 293.6304 291.1948 deviation
Detailed results for AES-GCM encryption and decryption | 55
Appendix B. Detailed results for AES-GCM encryption and decryption
Appendix B-1: AES-GCM encrypt for 64B data
Mbed Mbedtls- OpenSSL Intel SGX Intel SGX WolfSSL WolfSSL- TLS SGX (µs) SSL SDK (µs) SGX (µs) (µs) (µs) (µs) (µs)
Mean 1.9 11.8 1.0 8.4 7.9 7.5 7.9
Min 0 9 0 6 6 4 5
1stqu 1.0 11.0 1.0 8.0 7.0 6.0 7.0
Median 1.0 12.0 1.0 8.0 8.0 6.0 8.0
3stqu 2.0 12.0 1.0 9.0 8.0 7.0 9.0
Max 112 388 135 345 345 206 98
Standard 2.6960 5.0554 1.7927 3.9183 3.9169 6.3418 1.9497 deviation
Appendix B-2: AES-GCM decrypt for 64B data
Mbed Mbedtls- OpenSSL Intel SGX Intel SGX WolfSSL WolfSSL- TLS SGX (µs) SSL SDK (µs) SGX (µs) (µs) (µs) (µs) (µs)
Mean 1.6 11.9 1.9 8.9 8.1 5.5 6.4
Min 0 9 0 7 6 3 4
1stqu 1.0 11.0 1.0 8.0 7.0 4.0 6.0
Median 1.0 12.0 1.0 9.0 8.0 5.0 6.0
3stqu 2.0 13.0 2.0 9.0 8.0 5.0 7.0
Max 56 53 64 114 57 72 69
Standard 1.6713 1.8844 2.5565 2.5950 1.7994 4.2634 1.6325 deviation
56 | Detailed results for AES-GCM encryption and decryption
Appendix B-3: AES-GCM encrypt for 1KB data
Mbed Mbedtls- OpenSSL Intel SGX Intel SGX WolfSSL WolfSSL- TLS SGX (µs) SSL SDK (µs) SGX (µs) (µs) (µs) (µs) (µs)
Mean 6.7 52.8 1.3 9.0 9.7 63.7 70.7
Min 5.0 42 0 7 7 53 61
1stqu 6.0 45.0 1.0 8.0 8.0 59.0 64.0
Median 6.0 50.0 1.0 8.0 9.0 62.0 68.0
3stqu 8.0 57.0 1.0 10.0 10.0 65.0 74.0
Max 139 342 150 154 707 567 169
Standard 2.4678 11.1786 1.9248 2.6989 8.2923 11.5635 9.1009 deviation
Appendix B-4: AES-GCM decrypt for 1KB data
Mbed Mbedtls- OpenSSL Intel SGX Intel SGX WolfSSL WolfSSL- TLS SGX (µs) SSL SDK (µs) SGX (µs) (µs) (µs) (µs) (µs)
Mean 7.0 52.9 2.7 9.4 9.8 61.1 69.7
Min 5 42 0 7 7 52 60
1stqu 6.0 45.0 1.0 9.0 9.0 56.0 63.0
Median 7.0 51.0 2.0 9.0 9.0 58.0 67.0
3stqu 7.0 57.0 2.0 10.0 10.0 61.0 73.0
Max 287 275 2128 77 435 477 177
Standard 3.2380 10.9536 26.1541 2.2046 5.7434 18.6056 8.9989 deviation
Detailed results for AES-GCM encryption and decryption | 57
Appendix B-5: AES-GCM encrypt for 1MB data
Mbed Mbedtls- OpenSSL Intel SGX Intel SGX WolfSSL WolfSSL- TLS SGX (µs) SSL SDK (µs) SGX (µs) (µs) (µs) (µs) (µs)
Mean 5460 35442 341 539 698 53859 57449
Min 4879 33624 223 251 562 52616 52031
1stqu 5249 34892 251 374 643 53429 53676
Median 5348 35386 276 529 667 53608 56968
3stqu 5536 35714 433 648 713 53953 59772
Max 10111 72726 1319 10253 2612 71630 104282
Standard 391.6289 1172.542 126.4111 207.8673 111.9373 1103.880 4424.225 deviation
Appendix B-6: AES-GCM decrypt for 1MB data
Mbed Mbedtls- OpenSSL Intel SGX Intel SGX WolfSSL WolfSSL- TLS SGX (µs) SSL SDK (µs) SGX (µs) (µs) (µs) (µs) (µs)
Mean 5356 35302 331 528 670 54208 57456
Min 514 33542 209 249 514 52511 52042
1stqu 5179 34730 246 388 594 53879 54072
Median 5244 35282 269 475 614 54139 56809
3stqu 5422 35630 426 599 667 54341 59368
Max 9843 62769 2700 1888 2224 75922 100356
Standard 330.7196 1096.459 119.0178 198.9380 146.0055 969.9992 4170.685 deviation
Detailed results for ECDH process | 59
Appendix C. Detailed results for ECDH process
Appendix C-1: ECDH processing time
Mbed Mbedtls- OpenSSL Intel SGX Intel SGX WolfSSL WolfSSL- TLS SGX (µs) SSL SDK (µs) SGX (µs) (µs) (µs) (µs) (µs)
Mean 6167 22517 261 428 659 3704 4754
Min 5390 20773 223 328 581 3265 4309
1stqu 5762 21969 238 359 607 3459 4584
Median 5915 22337 247 384 634 3531 4663
3stqu 6369 22614 261 430 681 3785 4847
Max 29540 35910 12020 2763 1252 19789 7371
Standard 732.8461 1212.170 131.3483 120.6385 79.8549 466.5047 263.6425 deviation
Appendix C-2: ECDH generate key pair only
Mbed Mbedtls- OpenSSL Intel SGX Intel SGX WolfSSL WolfSSL- TLS SGX (µs) SSL SDK (µs) SGX (µs) (µs) (µs) (µs) (µs)
Mean 3137 10994 84 127 360 1788 2372
Min 2710 10214 64 108 293 1634 2173
1stqu 2823 10458 70 117 341 1680 2219
Median 2905 10719 74 119 354 1716 2259
3stqu 3224 11189 92 130 376 1793 2412
Max 9184 17847 1096 817 1027 5690 4465
Standard 585.4588 899.7750 35.8356 18.7498 34.7828 201.5419 250.7841 deviation
TRITA TRITA-EECS-EX-2019:3
www.kth.se