Diff to HTML by rtfpessoa

 

  \begin{frontmatter}

 

 

 

  \author[cracs]{André Brandão}

  \ead{[email protected]}

  \author[cracs]{Rolando Martins}

  \ead{[email protected]}

 

 

  \begin{abstract}

 

  Given that porting an application to a new environment is usually hard, not much work has been done to attempt running day-to-day server software on Intel SGX. Focus has mainly been on tools that separate code automatically~\cite{lind2017glamdring} or running unmodified applications inside an enclave~\cite{scone, haven, graphenesgx, sgxlkl}. The main issue associated with these approaches is that they do not consider each application's specificity leading to incompatibilities or/and significant performance loss.

 

 

  \subsection{Contributions} \label{Objectives}

 

 

  With the evolution of the architecture and the introduction of hypervisors, deeper levels of privilege were introduced. One example of this is the hypervisor mode, also known as ring -1, capable of preempting and isolating kernel code. Ring -2 refers to the system management mode (SMM), which can seize the hypervisor code and has nearly unrestricted access to the system~\cite{domas2015memory}. It is also in charge of controlling power management, system hardware and run proprietary code from Intel and the motherboard manufacturer.

 

 

  \subsection{Trusted Execution Environment}

  Trusted Execution Environment (TEE) is often referred to as a secure, integrity-protected programmable environment with memory and sometimes storage capabilities~\cite{sabt2015trusted}.

 

 

  \subsection{Running legacy application on Intel SGX}

 

  \begin{figure}[ht]

  \centering

 

  Figure \ref{fig:securecontainers}a shows a design that places a Library OS and a shielding mechanism inside the enclave. The library OS allows the enclave to drastically reduce the number of system calls made to the kernel, thus decreasing the performance penalty associated with leaving and entering the enclave. The shielding layer protects a security-sensitive set of system calls, by, for example, encrypting and decrypting I/O operations. The disadvantage of this type of design is that by integrating the library OS inside the enclave, we are significantly increased the size of TCB.

  %isto não devia aparecer noutro lado? \ref{fig:securecontainers}b?

 

  To our knowledge, no current implementation follows this extreme approach as they typically implement some shielding layer. This solution would also imply a significant increase in the number of transitions to and from the enclave, decreasing the application's overall performance.

 

 

  Graphene-SGX~\cite{graphenesgx} handles Intel SGX as just one more environment on which the applications may run. To run unmodified applications under Intel SGX, a port of the PAL was made to Intel SGX. This allows, similarly to Haven, a mutual distrust from the host and the guest. It is one of the few, if not the only solution, that allows the creation of forks of existing processes. When a process is forked, a new clean process is created. Then the two enclaves, via an inter-enclave remote process communication stream, exchange an encryption key, validates the CPU-generated attestation of each other, and migrates the parent process snapshot. The current solution leaves for future work the protection of the network and file system.

 

 

  \subsection{SGX Native Applications}

  In this Section, we overview some solutions that utilize Intel SGX in order to widen its threat model to have stronger guarantees that the desired data is kept confidential from even the operating system itself.

  To guarantee that the user is in fact, speaking with a genuine Intel SGX enclave, remote attestation is performed through the same efficient remote attestation protocol as proposed by the SafeKeeper.

 

  \subsubsection{tpmsgx}

 

  Dave Tian et al.~\cite{tian2019practical} propose a system so that applications can leverage Intel SGX in a cloud-like environment for multiple users through the use of an emulated TPM and LXC containers.

 

 

  The implementation specifies that, if remote attestation is enabled, communication between the server and the client is encrypted by an AES128 shared secret that is established between them. The publication does not specify if or how the client authenticates communicating with a genuine Intel SGX enclave.

 

  \subsubsection{SGX-Kernel}

  Although Intel SGX is limited to running code in user mode, Lars Richter et al.~\cite{richter2016isolating} propose a solution that allows the kernel to delegate some of the work to an enclave, in order to isolate kernel with Intel SGX.

 

 

  A proof of concept is demonstrated by creating a file system managed by the enclave, which is responsible not only for its storage but encryption as well, guaranteeing, that the encryption key is never exposed to other applications or other kernel mode code.

 

 

  \subsubsection{Mitigating Memory Corruption Vulnerabilities in SGX Enclaves}

  \label{mitigate_memory_subsection}

 

  Any function within the enclave that accepts a pointer without safety checks and is exposed to untrusted code could be a potential read/write primitive for an attacker.

 

 

  To mitigate this attack, the enclave must perform safety checks on the passing points. In our solution, we chose to create a hash map for each type of structure used and exported to untrusted code. This allowed for constant-time access to the saved pointers regardless of the number of existing pointers.

 

 

  If the cryptography library is inside an Intel SGX enclave, the application may still register the callback to functions outside the enclave, but when the enclave tries to execute that function, a segmentation fault will occur. This is because enclaves are not allowed to execute instructions outside its memory range without first issuing a special \textit{ocall} instruction to leave the enclave.

 

 

  \subsubsection*{Additional Getters/Setters}

  Even though OpenSSL 1.1 removed many of its structures from the public header files so that they become opaque and force the usage of accessor functions~\cite{openssl11changes}, not everything got the same treatment. Structures such as the \textit{GENERAL\_NAME} are not opaque and still rely on the application to directly access the data in the pointer returned by OpenSSL.

  Secondly, Intel SGX enclaves when running in release mode do not allow access from untrusted code. This means, similarly to the first issue, trying to access the data it points to will cause an access violation. Because of the latter issue, we believe that TaLoS~\cite{aublin2017talos}, even though it claims support for Apache's HTTP server, it does not handle these cases within the LibreSSL library. This means it will only work in pre-production mode, allowing access to the enclave's memory from any code. Attempting to use the library in production, i.e., enclave compiled in release mode, would cause segmentation faults when accessing data that resides in the enclave.

 

  \subsubsection*{Sealed Key Detection}

  For convenience and help users identify what kind of key they have in storage, we append the suffix '.sealed' to the end of the file's name.

 

  \subsubsection{Limitations}

 

  \subsection{OpenSSL Engine Integration} \label{custom_engine}

  %This Section will describe our implementation of a key store that uses Intel SGX to keep its contents secrets and its integration with an OpenSSL engine.

 

  The solution described in this Subsection is open source and available in a public repository on GitHub~\cite{sgx_keystore_openssl_engine}.

 

 

  \renewcommand{\arraystretch}{1.2}

  \begin{table*}[t]

  \renewcommand{\arraystretch}{1}

 

 

 

  The Engine registers a callback on OpenSSL for the event that loads a key. When this callback is called, it attempts to load the key. If the key is successfully loaded from the key store, custom methods are set for the encryption and decryption of data when using the key. These methods, when called, will forward the request to the enclave.

 

 

 

  \subsubsection{Cryptography Library}

 

  \subsubsection{Configuring OpenSSL}

 

 

 

  \subsubsection{Required Modifications to Applications}

 

  \subsubsection*{Adding support to Apache's HTTP server}

 

  \subsubsection{Security Analysis}

 

 

  \subsubsection*{Access to Encryption Keys}

  Unlike the solution presented in Section~\ref{http_implementation} this implementation does not protect the symmetric keys during a TLS connection. It works very similarly to a hardware security module (HSM) or, more precisely softHSM~\cite{softhsm}, which emulates an HSM in software. As our solution only implemented support for RSA keys, it only guarantees the secrecy of these keys. Meaning if the key store is utilized for TLS, the agreed symmetric key would be exposed to untrusted code.

 

  \subsubsection*{Key Usage}

 

 

  \section{Results}\label{chap_results}

 

 

 

 

 

  \section{Conclusion and Future Work} \label{chap_conclusion}

  In this Section, we overview our work and results accomplished throughout this work. We start by making a brief overview of the research and development made throughout our work, commenting on the goals achieved and complexity of each project. We then talk about the results obtained, their effectiveness and viability. Lastly, we hint on possible future directions of this work, as an ongoing effort to minimize the impact on performance by secure enclaves.

 

 

  \subsection{Research and Development}

  Despite our efforts, we struggled to find applications that utilized Intel SGX. Instead, we found many solutions that either automatically porting applications~\cite{lind2017glamdring} or ran unmodified applications inside Intel SGX~\cite{haven,scone,sgxlkl,graphenesgx}. As seen by the results obtained in Chapter \ref{chap_results}, some of these solutions introduce limitations that only allow certain types of applications to run inside SGX.

 

  Given this state-of-affairs, we decided to port some applications to utilize Intel SGX through the SGX SDK and compare how these would perform relatively to their original counterparts running without any form of support from Intel SGX.

 

  The Apache's web server can secure connections via TLS through a separate module called \textit{mod\_ssl}. Porting this module was harder than expected, taking a considerable portion of the time spent on this work. We encountered several issues, ranging from finding a compatible library with it and Intel SGX, to modifying the cryptography library to use it from untrusted code and through its OpenSSL compatibility layer.

 

  Developing the Keystore for Intel SGX took significantly less effort than porting \textit{mod\_ssl}, with the harder task being modification of the OpenSSL Engine with proper documentation available.

 

  Additionally, in Section~\ref{http_implementation}, we also identified some issues with Intel's SGX cryptography library, TaLoS, and explained why it would not be suitable for our purposes.

 

  We successfully integrated the \textit{mod\_ssl} with WolfSSL and Intel SGX so that the termination of the TLS connection is made within a secure enclave to protect both the private key and the generated symmetric key during the handshake. However, this protection comes with a great performance penalty compared to both the original code of the module and Graphene-SGX, decreasing the performance as much as 90\% and 70\%, respectively.

 

  Our second approach was aimed to guarantee secrecy of the private keys and involved implementing a Keystore in Intel SGX and integrating with an OpenSSL engine so that applications could use it transparently. Applying this solution to the Apache webserver resulted in no measurable overhead when compared to the unmodified version while performing significantly better than Graphene-SGX. This solution's caveat is that it does not protect the symmetric key agreed upon during the TLS handshake. Table \ref{table:rsa_speed} shows that there is, in fact, some overhead in our solution, but it was not significant enough to affect the web server.

 

  We were limited to a single Intel SGX capable machine to test our solutions and the others. Additionally, we could not compile a Linux kernel with KVM supporting Intel SGX for guest virtual machines to analyze how Intel SGX would perform in a cloud-like scenario, limiting us to only being able to utilize docker.

 

  Given our second approach versatility and performance, it is harder to recommend the first implementation, which has an inferior performance and may make it harder to port future updates made to the original \textit{mod\_ssl}. While the first solution does protect the TLS connection inside the secure enclave, an attacker still has access to the web server's code and memory, meaning the encrypted and decrypted data can be read on the read and write callbacks of the web server, which means the protection is not that much greater when compared to the implemented OpenSSL Engine.

 

  \subsection{Future Work}

  Although we achieved our goals and utilized Intel SGX to increase key secrecy in real-world scenarios, our solution is not without limitations, pointed throughout this paper. In the future, we would like to address these limitations.

 

  \subsubsection*{Asynchronous Calls}

 

  \subsubsection*{Public-key Cryptography Support}

  Due to time constraints, the solution presented in Section \ref{custom_engine} only implemented support for RSA public-key cryptography. Consequently, applications utilizing our engine are limited to RSA public-key cryptography. Future work of this solution should be able to support other public-key cryptography algorithms such as Elliptic-curve cryptography.

 

  \subsection*{Acknowledgment}

 

  \appendix

  \section{Read and Write Primitives within Intel SGX} % Main appendix title

  &BIO_meth_set_read_callback_handler);

  }

  \end{verbatim}

 

  \subsection{OpenSSL Engine Configuration}

  \label{openssl_engine_config}