A framework for application partitioning using trusted execution environments

Ahmad Atamli-Reineh, Andrew Paverd, Giuseppe Petracca, Andrew Martin
2017 Concurrency and Computation  
The size and complexity of modern applications are the underlying causes of numerous security vulnerabilities. In order to mitigate the risks arising from such vulnerabilities, various techniques have been proposed to isolate the execution of sensitive code from the rest of the application and from other software on the platform (such as the operating system). New technologies, notably Intel's Software Guard Extensions (SGX), are becoming available to enhance the security of partitioned
more » ... ions. SGX provides a trusted execution environment (TEE), called an enclave, that protects the integrity of the code and the confidentiality of the data inside it from other software, including the operating system. However, even with these partitioning techniques, it is not immediately clear exactly how they can and should be used to partition applications. How should a particular application be partitioned? How many TEEs should be used? What granularity of partitioning should be applied? To some extent, this is dependent on the capabilities and performance of the partitioning technology in use. However, as partitioning becomes increasingly common, there is a need for systematization in the design of partitioning schemes. To address this need, we present a novel framework consisting of four overarching types of partitioning schemes through which applications can make use of TEEs. These schemes range from coarse-grained partitioning, in which the whole application is included in a single TEE, through to ultra-fine partitioning, in which each piece of security-sensitive code and data is protected in an individual TEE. Although partitioning schemes themselves are application-specific, we establish application-independent relationships between the types we have defined. Since these relationships have an impact on both the security and performance of the partitioning scheme, we envisage that our framework can be used by software architects to guide the design of application partitioning schemes. To demonstrate the applicability of our framework, we have carried out case studies on two widely-used software packages, the Apache web server and the OpenSSL library. In each case study, we provide four high level partitioning schemes -one for each of the types in our framework. We also systematically review the related work on hardware-enforced partitioning by categorising previous research efforts according to our framework. 2 A FRAMEWORK FOR APPLICATION PARTITIONING code [1, 2] . An example that demonstrates this was the HeartBleed bug in the OpenSSL library where an attacker was able to obtain sensitive information including user names and passwords, credentials, and sensitive keys from remote servers [3] . Each discipline has its own type of sensitive data. In the financial sector, software needs to protect credit card details, account numbers, bank account numbers and client financial information. In the personal health sector, the types of sensitive data include insurance information, medical information, social security numbers, addresses and other personal information. In the military and government sectors, software controls may apply to operation information, high profile individuals information, weapons location, and public services access information. In the business sector, sensitive data includes trade secrets, research and business intelligence data, management reports, customer information, and sales data. Despite differing emphasese, all sectors have sensitive data that must be protected. Much research has considered the design of systems based on well-known operating systems and hardware components to protect sensitive code. Many of these systems leverage virtualisation and trusted computing to isolate the execution of the entire application [4] [5] [6] [7] [8] [9] [10] [11] [12] . However, many applications have thousands or millions of lines of code, which makes it hard to gain assurance that no vulnerability exists in the code itself. Moreover, when virtualisation is used to provide isolation between different executions, there are many trust assumptions that make these systems limited in their security properties. For example, the Virtual Machine Monitor (VMM) or the code providing isolation needs to be trusted, loading the Trusted Computing Base (TCB) with thousands of lines of code. The TCB is includes the code that is trusted to enforce the security policy of the system. This code usually runs inside the same environment as sensitive code and data. The isolation of a software partition protects the data and the execution from external code (e.g. the OS) and applications running in the same system. It follows that software partitioning of the application into several trusted and untrusted partitions is expected to produce smaller partitions of code in comparison to the whole application as one partition. When partitioning into smaller chunks is feasible, this improves security because it is easier to audit or even formally verify individual partitions, which are isolated from external code and vulnerabilities, including vulnerabilities in other partitions of the same application. An isolated environment shares no data unless explicitly designed by the programmer to do so. The aforementioned method of accessing the data through a defined interface prevents unintended privilege sharing. The burden of identifying the data to share lies on the programmer, who also needs to define the method through which the data is shared. An example that demonstrate this is the session handling code of the users in the Apache web services. The session handling code makes use of over 500 memory objects, scattered throughout the process space. Moreover, the usual OS primitives of dividing the execution of the program through forking another process, exec to replace the contents of the currently running process, and IPC (Inter Process Communication) between processes to share intended memory objects are by no mean the best method in the aforementioned case. This operation is heavily used by software and suffers from many performance issues. Other systems [13] [14] [15] [16] [17] [18] [19] [20] provide isolation for the execution of a sensitive code block without defining the portion of the application running on the trusted space, the granularity of these approaches to port sensitive code, or the feasibility of porting small code, such as only few methods of an existing library. For instance, the TrustVisor [14] authors appreciate the complexity of porting security sensitive code into a trusted environment. Porting security sensitive code is straightforward if the program is privilege-separated and modular. However, it is a greater challenge in complex applications such as Apache + OpenSSL [14] . To overcome the above mentioned shortcomings, processor extensions have been proposed in several pieces of research [21, 22] to protect software execution and reduce the TCB. Protecting the code execution of the TCB is achieved with a Trusted Execution Environment (TEE) in hardware, which prevents external software from tampering with the execution, or modifying an existing code/data. Intel has also proposed security extensions to the Intel Architecture called Intel Software Guard Extensions (Intel SGX) [23, 24] , that enable provisioning of sensitive data within applications. These extensions allow an application to instantiate a protected container to ensure † Thus in the rare case of a very simple application with only a single piece of security-sensitive code or data, it does not make sense to define type 3 schemes since they would be indistinguishable from type 2 schemes.
doi:10.1002/cpe.4130 fatcat:ojcrwrl5hnavpmb6g7xbnnqumy