Moat: Verifying Confidentiality of Enclave Programs
Rohit Sinha Sriram Rajamani UC Berkeley Microsoft Research [email protected] [email protected] Sanjit A. Seshia Kapil Vaswani UC Berkeley Microsoft Research [email protected] [email protected]
ABSTRACT 1. INTRODUCTION Security-critical applications constantly face threats from Building applications that do not leak secrets, i.e., pro- exploits in lower computing layers such as the operating vide confidentiality guarantees, is a non-trivial task. There system, virtual machine monitors, or even attacks from ma- are at least three kinds of attacks a developer must guard licious administrators. To help protect application secrets against. The first kind of attack, which we call protocol at- from such attacks, there is increasing interest in hardware tack, is relevant for distributed applications involving client implementations of primitives for trusted computing, such nodes and cloud-based services, and can arise from vulnera- as Intel’s Software Guard Extensions (SGX) instructions. bilities in the cryptographic protocol used to establish trust These primitives enable hardware protection of memory re- between various distributed components. Examples of pro- gions containing code and data, and provide a root of trust tocol attacks include man-in-the-middle or replay attacks. for measurement, remote attestation, and cryptographic seal- The second kind of attack, which we call application attack, ing. However, vulnerabilities in the application itself, such is due to errors or vulnerabilities in the application code it- as the incorrect use of SGX instructions or memory safety self which can be exploited to leak confidential information errors, can be exploited to divulge secrets. In this paper, we from the application (e.g., the Heartbleed bug [18]). The introduce a new approach to formally model these primitives third kind of attack, which we call infrastructure attack, is and formally verify properties of so-called enclave programs due to exploits in the software stack (e.g. operating system that use them. More specifically, we create formal models (OS), hypervisor) that the application relies upon, where of relevant aspects of SGX, develop several adversary mod- the privileged malware has full control of the CPU, mem- els, and present a sound verification methodology (based on ory, I/O devices, etc. Infrastructure attacks can result in an automated theorem proving and information flow analysis) attacker gaining control of any application’s memory and for proving that an enclave program running on SGX does reading secrets at will. not contain a vulnerability that causes it to reveal secrets Several mitigation strategies have been proposed for each to the adversary. We introduce Moat, a tool which formally of these kinds of attacks. In order to guard against proto- verifies confidentiality properties of applications running on col attacks, we can use protocol verifiers (e.g., ProVerif [11], SGX. We evaluate Moat on several applications, including a CryptoVerif [12]) to check for protocol errors. In order to one time password scheme, off-the-record messaging, notary guard against application attacks, the application can be service, and secure query processing. developed in a memory-safe language with information flow control, such as Jif [28]. Infrastructure attacks are the hard- Categories and Subject Descriptors est to protect against, since the attack can happen even if the application is error free (i.e., without application vulner- D.4.6 [Operating Systems]: Security and Protection — abilities or protocol vulnerabilities). While some efforts are Information flow controls, Verification; D.2.4 [Software En- under way to build a fully verified software stack ground-up gineering]: Software/Program Verification — Formal meth- (e.g. [21, 25]), this approach is unlikely to scale to real-world ods, Model checking OS and system software. An alternative approach to guarding against infrastruc- Keywords ture attack is by hardware features that enable a user-level application to be protected from privileged malware. For Enclave Programs; Secure Computation; Confidentiality; For- instance, Intel SGX [23, 24] is an extension to the x86 in- mal Verification struction set architecture, which provides any application Permission to make digital or hard copies of all or part of this work for personal or the ability to create protected execution contexts called en- classroom use is granted without fee provided that copies are not made or distributed claves containing code and data. SGX features include 1) for profit or commercial advantage and that copies bear this notice and the full citation hardware-assisted isolation from privileged malware for en- on the first page. Copyrights for components of this work owned by others than the clave code and data, 2) measurement and attestation prim- author(s) must be honored. Abstracting with credit is permitted. To copy otherwise, or itives for detecting attacks on the enclave during creation, republish, to post on servers or to redistribute to lists, requires prior specific permission and 3) sealing primitives for storing secrets onto untrusted and/or a fee. Request permissions from [email protected]. CCS’15, October 12–16, 2015, Denver, Colorado, USA. persistent storage. Using these extensions it is possible to Copyright is held by the owner/author(s). Publication rights licensed to ACM. write applications with a small trusted computing base, which ACM 978-1-4503-3832-5/15/10 ...$15.00. includes only the enclave code and the SGX processor. All DOI: http://dx.doi.org/10.1145/2810103.2813608 . other layers in the software stack including the operating malware attacks. Furthermore, extending traditional type system and the hypervisor can be excluded from the trusted systems to enclave programs is non-trivial because the anal- computing base. However, establishing such a guarantee ysis must faithfully model the semantics of SGX instruc- requires precise understanding of the contract between the tions and infer information flows to individual addresses hardware and software. In particular, it requires specify- within enclave memory. Therefore, we develop a static ver- ing a formal API-level semantics of SGX instructions, an ifier called Moat that analyzes the instruction-level behav- adversary model, and a verification methodology (with tool ior of the enclave binary program. Moat employs a flow- support) to detect insecure use of SGX instructions. Our and path-sensitive type checking algorithm (based on auto- work addresses each of these aspects, as we describe below. mated theorem proving using satisfiability modulo theories solving [8]) for automatically verifying whether an enclave Semantics of SGX instructions. SGX provides instruc- program (in the presence of an active adversary) provides tions which enable applications to create enclaves, transfer confidentiality guarantees. For ill-typed programs, Moat re- control to and from enclaves, perform remote attestation, turns an exploit demonstrating a potential leak of secret to and seal and unseal secrets so that they can persist on the non-enclave memory. By analyzing the binary, we remove platform. We give a formal semantic model of the interface the compiler from our trusted computing base, and relax between the programmer and the implementation of SGX, several memory safety assumptions that are common in tra- with an eye towards automatic formal verification of the en- ditional information flow type systems. clave code’s security. Our approach is similar in spirit to Although we do not focus on protocol attacks in this previous work on finding API-level exploits [20] using the paper, we briefly describe how one can compose protocol- UCLID modeling and verification system [15]. level analysis (performed by a verifier such as ProVerif [11]) Adversary model. We consider a powerful adversary who with Moat to achieve end-to-end confidentiality guarantees can compromise the infrastructure code (OS, hypervisor, against infrastructure, application, and protocol attacks. etc.) and perform both passive and active attacks by access- ing any non-enclave memory (i.e. memory not protected by In summary, the goal of this paper is to explore the con- SGX), modifying page tables, generating interrupts, control- tract between the SGX hardware and the enclave developer ling I/O interaction, etc. It is non-trivial to reason about and provide a methodology and tool support for the pro- enclave behaviors (and potential vulnerabilities) in the pres- grammer to write secure enclaves. We make the following ence of such an adversary. As a first step, using our formal specific contributions: ISA-level semantics of the SGX instructions, we prove that • We develop the first semantic API model of the SGX plat- (if the application follows certain guidelines during enclave form and its new instruction set, working from publicly- creation) any combination of the above adversarial actions available documentation [24]. can be simply modeled as an arbitrary update of non-enclave memory. This simplifies our reasoning of enclave execution • We formally study active and passive adversaries for SGX in the presence of privileged adversaries. In particular, we enclaves, and show that a havocing adversary who observes show that a so-called havocing adversary who symbolically and havocs non-enclave memory after every instruction in modifies all of the non-enclave memory after every instruc- the enclave is both powerful enough to model all such ad- tion of the enclave code, and is able to observe all non- versaries, and amenable to be used in automated symbolic enclave memory, is powerful enough to model all passive and verification tools. active adversaries. We consider this to be one of the key con- tributions of this paper. It greatly simplifies the construc- • We develop Moat, a system for statically verifying confi- tion of automated verifiers for checking security properties dentiality properties of an enclave program in the face of of enclave code, and potentially even programming and rea- application and infrastructure attacks. soning about enclaves. Though we study these issues in the context of Intel SGX, Verification methodology and tool support. Even similar issues arise in other architectures based on trusted though SGX offers protection from infrastructure attacks, hardware such as ARM TrustZone [4] and Sancus [29], and the developer must take necessary steps to defend against our approach is potentially applicable to them as well. The protocol and application attacks by using SGX instructions theory we develop with regard to attacker models and our correctly, using safe cryptographic protocols, avoiding tra- verifier is mostly independent of the specifics of SGX, and ditional bugs due to memory safety violations, etc. For our use of the term “enclave” is also intended in the more instance, the enclave may suffer from exploits like Heart- general sense. bleed [18] by using vulnerable SSL implementations, and these exploits have been shown to leak secret cryptographic keys from memory. To that end, our next step is to prove 2. BACKGROUND that enclaves satisfy confidentiality i.e. there is no execu- tion that leaks a secret to the adversary-visible, non-enclave 2.1 SGX memory. Proving confidentiality involves tracking the flow The SGX instructions allow a user-level host application of secrets within the application’s memory, and proving that to instantiate a protected execution context, called an en- the adversary does not observe values that depend on se- clave, containing code and data. An enclave’s memory re- crets. While past research has produced several type sys- sides within the untrusted host application’s virtual address tems that verify information flows (e.g. Jif [28], Volpano space, but is protected from accesses by that host applica- et al. [34], Balliu et al. [5]), they make a fundamental as- tion or any privileged software — only the enclave code is sumption that the infrastructure (OS/VMM, etc.) on which allowed to access enclave memory. Furthermore, to protect the code runs is safe, which is unrealistic due to privileged against certain hardware attacks, the cache lines belonging to enclave memory are encrypted and integrity protected by ware implementations have been attempted, they are often the CPU prior to being written to off-chip memory. prone to infrastructure attacks from malware, making them The host application creates an enclave using a combina- untrustworthy. tion of instructions: ecreate, eadd, eextend, and einit. The necessary primitives for implementing this protocol The application invokes ecreate to reserve protected mem- securely are (1) ability to perform the cryptographic op- ory for enclave use. To populate the enclave with code erations (or any trusted computation) without interference and data, the host application uses a sequence of eadd and from the adversary, (2) protected memory for computing eextend instructions. eadd loads code and data pages from and storing secrets, and (3) root of trust for measurement non-enclave memory to enclave’s reserved memory. eextend and attestation. Intel SGX processors provide these primi- extends the current enclave measurement with the measure- tives. Hoekstra et al. [23] propose the following OTP scheme ment of the newly added page. Finally, einit terminates the based on SGX, which we implement (Figure 1) and verify initialization phase, which prevents any further modification using Moat. In this protocol, a bank OTP server provisions to the enclave state (and measurement) from non-enclave the pre-shared secret to a client, which is running on a po- code. The host application transfers control to the enclave tentially infected machine with SGX hardware. by invoking eenter, which targets a programmer defined en- 0. The host application on the client sets up an enclave that try point inside the enclave (via a callgate-like mechanism). contains trusted code for the client side of the protocol. The enclave executes until one of the following events occur: (1) enclave code invokes eexit to transfer control to the 1. The server sends the client an attestation challenge nonce. host application, (2) enclave code incurs a fault or excep- Consequent messages in the protocol use the nonce to tion (e.g. page fault, divide by 0 exception, etc.), and (3) guarantee freshness. the CPU receives a hardware interrupt and transfers con- trol to a privileged interrupt handler. In the case of faults, 2. The client and OTP server engage in an authenticated exceptions, and interrupts, the CPU saves state (registers, Diffie-Hellman key exchange in order to establish a sym- etc.) in State Save Area (SSA) pages in enclave memory, metric session_key. The client uses ereport instruction and can resume the enclave in the same state once the OS / to send a report containing a signature over the Diffie- VMM handles the event. Although a compromised OS may Hellman public key dh_pubkey and the enclave’s mea- launch denial of service attacks, we show that an enclave surement. The signature guarantees that the report was can still guarantee properties such as data confidentiality. generated by an enclave on an Intel SGX CPU, while the The reader may have observed that before enclave initial- measurement guarantees that the reporting enclave was ization, code and data is open to eavesdropping and tamper- not tampered during initialization. After verifying the ing by adversaries. For instance, an adversary may modify a signatures, both the client and OTP server compute the OTP enclave’s binary (on user’s machine) so that it leaks a symmetric session_key. user’s login credentials. SGX provides an attestation prim- 3. The OTP server sends the pre-shared OTP secret to the itive called ereport to defend against this class of attacks. client by first encrypting it with the session_key, and The enclave participates in attestation by invoking ereport, then signing the encrypted content with the bank’s pri- which generates a hardware-signed report of the enclave’s vate TLS key. The client verifies the signature and de- measurement, and then sending the report to the verifying crypts the message to retrieve the pre-shared otp_secret. party. The enclave can also use ereport to bind data to its measurement, thereby adding authenticity to that data. 4. For future use, the client requests for sealing_key (us- The enclave can use egetkey to attain a hardware-generated ing egetkey instruction), encrypts otp_secret using seal- sealing key, and store sealed secrets to untrusted storage. ing_key, and writes the sealed_secret to disk. A typical application (such as our OTP client) uses en- 2.2 Example clave code to implement trusted computation such as the We demonstrate the use of SGX by an example of a one- cryptographic operations, stores secrets in the enclave heap, time password (OTP) service, although the exposition ex- and uses non-enclave code (host application, OS, VMM, tends naturally to any secret provisioning protocol. OTP is etc.) for untrusted computation. In fact, SGX prevents typically used in two factor authentication as an additional the enclave code from invoking any privileged instructions step to traditional knowledge based authentication via user- such as system calls, thus forcing the enclave to rely on non- name and passphrase. A user demonstrates ownership of a enclave code to issue system calls, perform I/O, etc. For pre-shared secret by providing a fresh, one-time password instance, to send the Diffie-Hellman public key to the server, that is derived deterministically from that secret. For in- the enclave (1) invokes ereport with enclave_state.dh_pubkey, stance, RSA SecurID R is a hardware-based OTP solution, (2) copies the report to non-enclave memory app_heap, (3) where possession of a tamper-resistant hardware token is invokes eexit to transfer control to the untrusted app, and required during login. In this scheme, a pre-shared secret (4) waits for app to invoke the socket system calls to send is established between the OTP service and the hardware the report to the bank server. Over their lifetimes, app and token. From then on, they compute a fresh one-time pass- enclave perform several eenter and eexit while alternating word as a function of the pre-shared secret and time dura- between trusted and untrusted computation. To facilitate tion since the secret was provisioned to the token. The user the interaction between an enclave and non-enclave code, must provide the one-time password displayed on the to- SGX allows the enclave to access the entire address space of ken during authentication, in addition to her username and the host application. passphrase. This OTP scheme is both expensive and in- While SGX implements the necessary primitives for doing convenient because it requires distributing tamper-resistant trusted computation, we need a methodology for writing se- hardware tokens physically to the users. Although pure soft- cure enclave programs. Confidentiality requires protecting Figure 1: Running OTP Example. The enclave performs trusted cryptographic operations, and the host application performs untrusted tasks such as UI handling and network communications with the OTP server. secrets, which requires understanding of the contract be- untrusted. For the application to be secure, we need (1) se- tween the enclave developer and the SGX hardware. First, cure cryptographic protocols between the components (to the enclave developer must follow the enclave creation guide- protect from protocol attack), and (2) secure implementa- lines (see § 3.1) so that the hardware protects the enclave tion in each component to protect from application attack from an attacker that has gained privileged access to the sys- and infrastructure attack. Our goal is to prove that, even tem. Even then, the enclave developers needs to ensure that in the presence of such attacks, the enclave does not leak their code does not leak secrets via application attacks and its secrets to the adversary. Moat defends against applica- protocol attacks. For instance, they should encrypt secrets tion and infrastructure attacks. Furthermore, we combine before writing them to non-enclave memory. They should Moat with off-the-shelf protocol verifiers to defend against account for adversary modifying non-enclave memory at any protocol attacks as well. time, which could result in time-of-check-to-time-of-use at- tacks. For example, the enclave code in Figure 1 has such a 3.1 Protecting from Infrastructure Attacks vulnerability. The enclave code here copies encrypted data An infrastructure attack can generate interrupts, modify from enclave memory to non-enclave memory, but the size of page tables, modify any non-enclave memory, invoke any x86 the data copied is determined by a variable size_field, which and SGX instruction — § 4.3 formalizes the threat model. resides in non-enclave memory. Thus, by manipulating the We mandate that the enclave be created with the following value of this variable the adversary can trick the enclave code sequence that measures all pages in memenc, which denotes into leaking secrets to non-enclave memory. Avoiding such memory reserved for the enclave. We do not find this to be attacks is non-trivial. In this paper, we present a methodol- a restriction in practice. ogy and tool support for detecting such errors, and proving that enclaves are secure. ecreate(size(memenc)); The rest of this paper is structured as follows. We provide foreach page ∈ memenc : {eadd(page); eextend(page)}; an overview of our approach in § 3. § 4 describes how Moat einit (1) constructs a formal model of the enclave program (including its use of x86 and SGX instructions), and also formalizes an If some component of enclave state is not measured, then active and a passive adversary. § 5 introduces the havocing the adversary may havoc that component of state during adversary, and shows how it can be used to model the en- initialization without being detected. This precondition on clave’s execution in the presence of an active adversary. The the initialization sequence lets us prove that the SGX hard- results presented in § 5 allow us soundly verify any safety ware provides some very useful guarantees. For instance, property of enclave programs. Next, we focus our attention we prove Theorem 1 in § 5 which guarantees that an en- on proving confidentiality by first formalizing it in § 6, and clave initialized using this sequence is protected from each then developing a verification algorithm in § 7. § 8 describes adversarial operation in our threat model — we formally several case studies where we apply Moat. model each SGX instruction (see § 4.2) to perform this proof. Specifically, we prove a non-interference property [16] that the enclave’s execution (i.e. its set of reachable states) is 3. OVERVIEW OF MOAT independent of the adversarial operations, with the caveat We are interested in building secure distributed applica- that the enclave may read non-enclave memory for inputs. tions, which have components running in trusted and un- However, we do not consider this to be an attack because the trusted environments, where all communication channels are enclave must read non-enclave memory for inputs, which are untrusted by design. The utility of this proof is that all in- ure 2 omits all updates to flags as they are irrelevant to this frastructure attacks can now be modeled by a so-called hav- code snippet. For reasons explained later, Moat does not ocing adversary that is only allowed to update non-enclave model the implementation of cryptographic routines (such memory, and this simplifies our reasoning of enclave exe- as AES_GCM_encrypt in Figure 2). It replaces all calls to cution in the presence of privileged adversaries. We call the cryptographic library with their specifications. In the this havocing adversary H (defined in § 5), and we allow case of AES_GCM_encrypt, the specification ensures mem- H to update all addresses in non-enclave memory between ory safety: only the output ciphertext buffer and memory any consecutive instructions executed by the enclave. Go- allocated to the library can be modified by this call. ing forward, we focus primarily on application attacks, and Since penc executes in the presence of an active adver- model H’s operations only for the purpose of reads from sary, we must model the effects of adversarial operations non-enclave memory. on penc’s execution. Section 3.1 introduces an active adver- sary H (formalized in5), which can perform the operation 3.2 Protecting from Application Attacks “havoc mem¬epc” once between consecutive instructions along In this section, we give an overview of Moat’s approach any execution of penc. Here, memepc denotes memory re- for proving confidentiality properties of enclave code (de- served by the SGX processor for enclave use, and mem¬epc tailed exposition in § 4 through § 7). Moat accepts an en- is all of untrusted, non-enclave memory; havoc mem¬epc up- clave program in x86 Assembly, containing SGX instruc- dates each address in mem¬epc with a non-deterministically tions ereport, egetkey, and eexit. Moat is also given a chosen value. We define H this way because a privileged set of annotations, called Secrets, indicating 1) program software adversary can interrupt penc at any point, perform points where secrets values are generated (e.g. after decryp- havoc mem¬epc, and then resume penc. We model the effect of tion), and 2) memory locations where those secret values are H on penc’s behavior by instrumenting havoc mem¬epc in penc stored. In the OTP example, the Secrets include otp_secret, (see Figure 3). The instrumented program is called penc−H. session_key, and sealing_key. Moat proves that a privileged software adversary running on the same machine does not observe a value that depends on Secrets, regardless of any 1 havoc mem¬epc; mem := egetkey(mem, ebx, ecx); operations performed by that adversary. We demonstrate 2 havoc mem¬epc; mem := store(mem, add(esp,8), 8080AC); Moat’s proof methodology on a snippet of OTP enclave code 3 havoc mem¬epc; eax := sub(ebp, 6e0); containing lines 22-26 from Figure 1, which is first com- 4 havoc mem¬epc; mem := store(mem, add(esp,4), eax); piled to x86+SGX Assembly in Figure 2. Here, the enclave 5 havoc mem¬epc; eax := sub(ebp, 720); invokes egetkey to retrieve a 128-bit sealing key, which is 6 havoc mem¬epc; mem := store(mem, esp, eax); stored in the byte array sealing_key. Next, the enclave en- 7 havoc mem¬epc; mem := AES_GCM_encrypt(mem, esp); crypts otp_secret (using AES-GCM-128 encryption library 8 havoc mem¬epc; eax := load(mem, 700048); function called encrypt) to compute the sealed_secret. Fi- 9 havoc mem¬epc; mem := store(mem, add(esp,8), eax); nally, the enclave copies sealed_secret to untrusted memory 10 havoc mem¬epc; eax := sub(ebp, 720); app_heap (to be written to disk). Observe that the size argu- 11 havoc mem¬epc; mem := store(mem, add(esp,4), eax); ment to memcpy (line 26 in Figure 1) is a variable size_field 12 havoc mem¬epc; mem := store(mem, esp, 701000); which resides in non-enclave memory. This buffer overrun 13 havoc mem¬epc; mem := memcpy(mem, esp); vulnerability can be exploited by the adversary, causing the enclave to leak secrets from its stack. Figure 3: penc−H constructed from OTP penc egetkey mem := egetkey(mem, ebx, ecx); As mentioned before, the OTP enclave implementation is movl $0x8080AC,0x8(%esp) mem := store(mem,add(esp,8),8080AC); vulnerable. The size argument to memcpy (line 26 in Fig- lea -0x6e0(%ebp),%eax eax := sub(ebp, 6e0); mov %eax,0x4(%esp) mem := store(mem,add(esp,4),eax); ure 1) is a field within a data structure in non-enclave mem- lea -0x720(%ebp),%eax eax := sub(ebp, 720); ory. This vulnerability manifests as a load (line 8 of Fig- mov %eax,(%esp) mem := store(mem, esp, eax); ure 3), which reads a value from non-enclave memory and call
1 function xor(x: bv32, y: bv32) { return x ⊕ y; } 4.2 Formal Model of x86 and SGX instruc- 2 function load(mem:[bv32]bv8, va:bv32) tions 3 { 4 var check : bool; //EPCM security checks succeed? While formal models of x86 instructions using BoogiePL 5 var pa : bv32; //translated physical address has been done before (see for instance [35]), we are the first 6 var ea : bool; //enclave access to enclave memory? to model SGX instructions. In section 4.1, we lifted x86 to a 7 pa := pagetable[va]; 8 ea := CR_ENCLAVE_MODE && enc(va); microarchitectural instruction sequence, and modeled each 9 check := epc(pa) && microarchitectural instruction as an uninterpreted function 10 EPCM_VALID(epcm[pa]) && (e.g. xor, load, ereport). In this section, we add axioms to 11 EPCM_PT(epcm[pa]) == PT_REG && 12 EPCM_ENCLAVESECS(epcm[pa]) == CR_ACTIVE_SECS && these uninterpreted functions in order to model the effect of 13 EPCM_ENCLAVEADDRESS(epcm[pa]) == va; instructions on machine state. 14 assert (ea => check); //EPCM security checks A state σ is a valuation of all Vars, which consists of mem, 15 assert ...; //read bit set and pagetable has valid mapping 16 if (!ea && epc(pa)) {return 0xff;} else {return mem[pa];} regs, and epcm. As their names suggest, physical memory 17 } σ.mem is modeled as an unbounded array, with index type of 18 function eexit(mem:[bv32]bv8, ebx:bv32) 32 bits and element type of 8 bits. mem is partitioned by the 19 { 20 var mem’ := mem; var regs’ := regs; platform into two disjoint regions: protected memory for en- 21 regs’[rip] := 0bv32 ++ ebx; clave use (memepc), and unprotected memory (mem¬epc). For 22 regs’[CR_ENCLAVE_MODE] := false; any physical address a, epc(a) is true iff a is an address in 23 mem’[CR_TCS_PA] := 0x00; 24 return (mem’,regs’); memepc. Furthermore, memenc is a subset of memepc that is re- 25 } served for use by penc — memenc is virtually addressed and it belongs to the host application’s virtual address space. For any virtual address a, enc(a) is true iff a is within memenc. Figure 6: Axioms for xor, load, and eexit instruc- The epcm is a finite sized array of hardware-managed struc- tions tures, where each structure stores security critical metadata 4.3 Adversary Model delete, modify and replay all communication with the exter- In this section, we formalize a passive and active adver- nal world — these attacks can be modeled using the above sary, which is general enough to model an adversarial host 5 transitions. Side-channels are out of scope, where typical application and also privileged malware running in the OS- side channels may include memory access patterns, timing /VMM layer. penc’s execution is interleaved with the host leaks, and I/O traffic patterns. application — host application transfers control to penc via We define an active and passive adversary: eenter or eresume, and p returns control back to the enc 1. General Active Adversary G. Between host application via eexit. Control may also transfer from Definition any consecutive statements along an execution of p , G p to the OS (i.e. privileged malware) in the event of an enc enc may execute an unbounded number of transitions of type interrupt, exception, or fault. For example, the adversary havoc , havoc , , or , thereby may generate interrupts or control the page tables so that mem¬epc regs interrupt call sgx modifying a component σ| of machine state σ. Following any enclave memory access results in a page fault, which is G each microarchitectural instruction in p , G observes a pro- handled by the OS/VMM. The adversary may also force a enc . jection σ| of machine state σ. Here, σ| = (σ.mem ), hardware interrupt at any time. Once control transfers to .obs obs ¬epc and σ| = (σ.mem , σ.regs, σ.epcm ). adversary, it may execute any number of arbitrary x86+SGX G ¬enc ¬enc instructions before transferring control back to the enclave. Definition 2. Passive Adversary P. The passive ad- Therefore, our model of an active adversary performs an un- versary P observes a projection σ|obs of machine state σ after bounded number of following adversarial transitions between . each microarchitectural instruction in penc. Here, σ|obs = any consecutive microarchitectural instructions executed by (σ.mem¬epc) includes the non-enclave memory. P does not penc: modify any state.
1. Havoc all non-enclave memory (denoted by havoc mem¬epc): While the CPU protects the epc region, a privileged Note that we omit σ.regs from σ|obs because they cannot software adversary can write to any memory location be accessed by the adversary while the CPU operates in en- in mem¬epc region. havoc mem¬epc is encoded in BoogiePL clave mode — asynchronous exits clear their values, while as: eexit removes the CPU from enclave mode. Enclave ex- ecution may result in exceptions (such as divide by 0 and assume ∀a. epc(a) → memnew[a] == mem[a]; page fault exception) or faults (such as general protection mem := mem ; new fault), in which case the exception codes are conveyed to
where memnew is an unconstrained symbolic value that the adversarial OS. We omit exception codes from σ|obs for is type-equivalent to mem. Observe that the adversary verification ease, and terminate the enclave (at runtime) on modifies an unbounded number of memory locations. an exception, with the caveat of page fault exceptions which are allowed. Since G can havoc page tables, it can cause 2. Havoc page tables: A privileged adversary can modify page fault exceptions at runtime. However, a page fault the page tables to any value. Since page tables reside in only reveals memory access patterns (at the page granular- mem¬epc, havoc mem¬epc models havoc on page tables. ity), which we consider to be a side-channel observation. 3. Havoc CPU registers (denoted by havoc regs). regs are modified only during adversary execution, and re- 5. COMPOSING ENCLAVEWITH THE AD- trieve their original values once the enclave resumes. havoc regs is encoded in BoogiePL as: VERSARY Moat reasons about penc’s execution in the presence of regs := regsnew; an adversary (P or G) by composing their state transition where each register (e.g. eax ∈ regs) is set to an uncon- systems. An execution of penc is a sequence of statements strained symbolic value. [l1 : s1, l2 : s2,..., ln : sn], where each si is a load, store, register assignment x := e, user-mode SGX instruc- 4. Generate interrupt (denoted by interrupt): The adver- tion (ereport, egetkey, or eexit), or a conditional state- sary can generate interrupts at any point, causing the ment. Since penc is made to be loop-free (by sound loop un- CPU jump to the adversarial interrupt handler. rolling), each statement si has a distinct label li that relates to the program counter. We assume that each microarchi- 5. Invoke any SGX instruction with any operands (denoted tectural instruction (not the x86 instruction) executes atom- by call sgx): The attacker may invoke ecreate, eadd, ically, although the atomicity assumption is architecture de- eextend, einit, eenter, and eresume to launch any pendent. number of new enclaves with code and data of attacker’s choosing. Composing enclave penc with passive adversary P. Any x86+SGX instruction that an active adversary in- In the presence of P, penc undergoes a deterministic se- vokes can be approximated by some finite-length combina- quence of state transitions starting from initial state σ0. P tion of the above 5 transitions. Our adversary model is cannot update V ars, therefore P affects penc’s execution sound because it allows the active adversary to invoke an only via the initial state σ0. We denote this sequence of unbounded number of these transitions. Furthermore, the states as trace t = [σ0, σ1, . . . , σn], where (σi, σi+1) ∈ R(si) active adversary is quite powerful in this model. It may for each i ∈ 0, . . . , n − 1. We also write this as hpenc, σ0i ⇓ t. control the entire software stack, from the host application upto the OS/VMM layers, thereby modeling attacks from Composing enclave penc with active adversary G. malicious administrators and privileged malware. The ad- G can affect penc at any step of execution by executing an versary controls all hardware peripherals, and may insert, unbounded number of adversarial transitions. Therefore, to model penc’s behaviour in the presence of G, we consider the 1. penc invokes load(mem, a), where a is an address in mem¬epc. following composition of penc and G. For each penc state- G havocs mem¬epc and penc reads mem¬epc for inputs, so ment l : s, we transform it to: this counter-example is not surprising.
adv1; ... ; advk; l : s (2) 2. penc invokes load(mem, a), where a is an address within This instrumentation (where k is unbounded) guarantees SSA pages. G can force an interrupt, causing the CPU to that between any consecutive statements along an execution save enclave state in SSA pages. If the enclave resumes of penc, G can execute an unbounded sequence of adversar- and reads from SSA pages, then the value read depends ial transitions adv1; ... ; advk, where each statement advi is on the enclave state at the time of last interrupt. an adversarial transition of type havoc mem¬epc, havoc regs, interrupt, or call sgx. This composed model, hereby If we prevent penc from reading mem¬epc or the SSA pages, called penc−G , encodes all possible behaviours of penc in the we successfully prove property (3). From hereon, we con- presence of G. An execution of penc−G is described by a se- strain penc to not read from SSA pages; we do not find this quence of states i.e. trace t = [α0, σ0, α1, σ1, ... , αn, σn], to be limiting in our case studies. Note that this restric- where each αi ∈ t denotes the state after the last adver- tion does not prevent the use of eresume instruction, which sary transition advk (right before execution resumes in the causes the CPU to access the SSA pages directly. However, enclave). We coalesce the effect of all adversary transitions the former constraint (not reading mem¬epc) is too restrictive into a single state αi for cleaner notation. Following advk, in practice because penc must read mem¬epc to receive inputs. the composed model penc−G executes an enclave statement Therefore, we must explore alternative adversary models. l : s, taking the system from a state αi to state σi. Instead of replacing G with P, we attempt replacing G with Given a trace t = [α0, σ0, α1, σ1, . . . , αn, σn], we define H defined below. . t| = [σ | , σ | , . . . , σ | ] obs 0 obs 1 obs n obs Definition 3. Havocing Active Adversary H. denoting the adversary-observable projection of trace t, ig- Between any consecutive statements along an execution of noring the adversary controlled α states. Correspondingly, penc, H may execute a single havoc mem¬epc operation, thereby we define . modifying a component σ|H of machine state σ. Follow- t|G = [α0|G , α1|G , . . . , αn|G ] ing each microarchitectural instruction in p , H observes a enc . capturing the adversary’s effects within a trace t. We define projection σ|obs of machine state σ. Here, σ|obs = (σ.mem¬epc), the enclave projection of σ to be . and σ|H = (σ.mem¬epc). . σ|enc = (σ.memenc, σ.regs, σ.epcmenc) This is the component of machine state σ that is accessible Composing enclave penc with active adversary H. only by penc. Correspondingly, we define To construct p , we transform each p statement . enc−H enc t|enc = [σ0|enc, σ1|enc, . . . , σn|enc] l : s to:
The transformation in (2) allows the adversary to perform havoc mem¬epc; l : s (4) an unbounded number of operations adv , . . . , adv , where 1 k Figure 3 shows a sample transformation from p to p . k is any natural number. Since we cannot verify unbounded enc enc−H Similar to our previous exercise with P, we prove that it is length programs using verification-condition generation, we sound to replace G with H while reasoning about enclave consider the following alternatives: execution. • Bound the number of operations (k) that the adversary is Theorem 1. Given an enclave program penc, let penc−G allowed to perform. Although this approach bounds the be the composition of penc and G via the transformation in length of penc−G , it unsoundly limits the G’s capabilities. (2) and penc−H be the composition of penc and H via the transformation in (4). Then,
• Use alternative adversary models in lieu of G with the ∗ ∀σ ∈ Σ. ∀t1 ∈ Σ . hpenc−G , σi ⇓ t1 ⇒ hope of making the composed model both bounded and ∗ sound. ∃t2 ∈ Σ . hpenc−H, σi ⇓ t2 ∧ ∀i. t1|enc[i] = t2|enc[i] Validity of this theorem implies that we can replace G with We explore the latter option in Moat. Our initial idea was to try substituting P for G. This would be the equivalent H while proving any safety property or k-safety hyperprop- of making k equal 0, and thus penc−G bounded in length. erty of enclave behaviour [16]. We prove theorem1 with the However, for this to be sound, we must prove that G’s op- use of lemma1 and lemma2, described next. erations can be removed without affecting penc’s execution, The transformation in (2) composed penc with G by in- as required by the following property. strumenting an unbounded number of adversary operations ∗ adv1; ... ; advk before each statement in penc. Let us further ∀σ ∈ Σ. ∀ti, tj ∈ Σ . hpenc−G , σi ⇓ ti ∧ hpenc, σi ⇓ tj ⇒ instrument havoc mem¬epc after each advi ∈ {adv1; ... ; advk} ∀i. ti|enc[i] = tj |enc[i] (3) — this is sound because a havoc on mem¬epc does not restrict the allowed values of mem¬epc. The resulting instrumentation If property (3) holds, then we can substitute P for G while for each statement l : s is: proving any safety (or k-safety [16]) property of p . While enc adv ; havoc mem ; ... ; adv ; havoc mem ; l : s (5) attempting to prove this property in the Boogie verifier [6], 1 ¬epc k ¬epc we quite expectedly discovered counter-examples that illus- Lemma1 proves that the effect of advi ∈ {adv1; ... ; advk} trate the different ways in which G affects penc’s execution: on penc can be simulated by a sequence of havocs to mem¬epc. In order to define lemma1, we introduce the following trans- properties of enclave programs, and (2) H gives a conve- formation on each statement l : s of penc: nient mental model of an active adversary’s effects on en- clave execution. While we focus on proving confidentiality havoc mem¬epc; ... ; havoc mem¬epc; l : s (6) from hereon, we note that theorem1 is valuable for soundly proving any safety property of enclave programs. Lemma 1. Given an enclave program penc, let penc−G∗ be the composition of penc and adversary via the transformation in (5) and penc−H∗ be the composition of penc and adversary 6. FORMALIZING CONFIDENTIALITY via the transformation in (6). Then, Moat’s definition of confidentiality is inspired by standard non-interference definition [27], but adapted to the instruction- ∗ ∀σ ∈ Σ. ∀t1 ∈ Σ . hpenc−G∗, σi ⇓ t1 ⇒ level modeling of the enclave programs. Confidentiality can ∗ ∃t2 ∈ Σ . hpenc−H∗, σi ⇓ t2 ∧ ∀i. t1|enc[i] = t2|enc[i] be trivially achieved with the definition that H cannot dis- tinguish between penc and an enclave that executes skip in Proof : The intuition is that (if the enclave makes progress) each step. However, such definition prevents penc from writ- the other adversarial transitions do not affect p in any enc ing to mem¬epc, which it must write in order to return outputs way that is not already simulated by havoc mem¬epc. For ex- or send messages to remote parties. To that end, we weaken ample, an interrupt causes the enclave to resume in the state prior to the interrupt. In addition, the CPU detects mod- this definition to allow for writes to mem¬epc, but constraining ifications to the page tables that affect the enclave pages, the values to be independent of the secrets. An input to Moat and prevents the enclave from progressing. Other enclaves is a policy that defines Secrets = {(l, v) | l ∈ L, v ∈ Vars}, on the machine may affect execution, but only by sending where a tuple (l, v) denotes that variable v holds a secret messages via non-enclave memory, which is simulated by value at program location l. In practice, since secrets typi- havoc mem¬epc. We prove lemma1 by induction as follows, cally occupy several bytes in memory, v is a range of sym- and also machine-check the proof in Boogie [6] (proof avail- able at [2]). The inductive proof makes use of our modeling bolic addresses in the enclave heap. We define the following of SGX instructions, and is setup as follows. This property transformation from penc−H to penc−H−sec for formalizing in Lemma1 is a predicate over a pair of traces, making it a confidentiality. For each (l, v) ∈ Secrets, we transform the 2-safety hyperproperty [16]. A counter-example to this prop- statement l : s to: erty is a pair of traces ti, tj where G has caused ti to diverge from tj . We rewrite the property as a 2-safety property and l : s; havoc v; (9) prove it via 1-step induction over the length of the trace, as follows. For any pair of states (σi,σj ) that is indistinguish- havoc v assigns an unconstrained symbolic value to variable able to the enclave, we prove that after one transition, the v. With this transformation, we define confidentiality as 0 0 new pair of states (σi,σj ) is also indistinguishable. Here, follows: 0 0 (σi, σi) ∈ R(si) and (σj , σj ) ∈ R(sj ), where si is executed Definition 4. Confidentiality For any pair of traces of by penc−G∗ and sj is executed by penc−H∗. The state pred- penc−H−sec that potentially differ in the values of the Secret icate Init represents an enclave state after invoking einit variables, if H’s operations along the two traces are equiv- in the prescribed initialization sequence in (1). Property7 alent, then H’s observations along the two traces must also is the base case and property8 is the inductive step in the be equivalent. proof by induction of lemma1. ∗ ∀σ ∈ Σ, t1, t2 ∈ Σ .(hpenc−H−sec, σi ⇓ t1 ∧ hpenc−H−sec, σi ⇓ t2 ∧ ∀σi, σj .Init(σi) ∧ Init(σj ) ⇒ σi|enc = σj |enc (7) ∀i.t1|H[i] = t2|H[i]) ⇒ (∀i.t1|obs[i] = t2|obs[i]) (10) ∀σ , σ , σ0, σ0 , s , s . i j i j i j The havoc on Secrets cause the secret variables to take 0 0 σi|enc = σj |enc ∧ (σi, σi) ∈ R(si) ∧ (σj , σj ) ∈ R(sj ) ∧ p(si, sj ) potentially differing symbolic values in t1 and t2. Prop- 0 0 ⇒ σi|enc = σj |enc (8) erty (10) requires t1|obs and t2|obs to be equivalent, which is achieved only if the enclave does not leak secrets to H- where observable state. While closer to the desired definition, it still prevents penc si ∈ {egetkey, ereport, eexit, load, store} ∧ sj = si . from communicating declassified outputs that depend on se- p(si, sj ) = si = s; havoc mem¬epc ∧ sj = havoc mem¬epc crets. For instance, recall that the OTP enclave outputs the where s ∈ {havoc mem¬epc,..., interrupt, call sgx} encrypted secret to be stored to disk. In this case, since different values of secret produce different values of cipher- Lemma 2. A sequential composition of unbounded num- text, penc violates property (10). This is a false alarm if the encryption uses a secret key to produce the ciphertext. To ber of havoc mem¬epc statements can be simulated by a single remove such false alarms, we take the standard approach of havoc mem¬epc statement. extending the policy with Declassified = {(l, v) | l ∈ L, v ∈ Proof : Lemma2 requires a straightforward proof as it fol- Vars}, where a tuple (l, v) denotes that variable v at loca- lows naturally from the semantics of havoc. tion l contains a declassified value. In practice, since out- Combining lemma1 and lemma2, we prove that the ef- puts typically occupy several bytes in memory, v is a range fect of adv1; havoc mem¬epc; ... ; advk; havoc mem¬epc (or adv1; of symbolic addresses in the enclave heap. We can safely adv2;... ; advn) on enclave’s execution can be simulated by eliminate declassified outputs from information leaks as the havoc mem¬epc. By theorem1, it is sound to prove any safety protocol verifier has already proven them to be safe outputs (or k-safety) property on penc−H because penc−H allows all (see Section 3.2). When declassification is necessary, we use traces allowed by penc−G . The benefits of composing with the following property for checking confidentiality. H are (1) penc−H is bounded in size, which allows using Definition 5. Confidentiality with Declassification standard verification techniques to prove safety (or k-safety) For any pair of traces of penc−H−sec that potentially differ in the values of the Secret variables, if H’s operations along ψ is satisfied. An expression of the form op(v1, . . . , vn) the two traces are equivalent, then H’s observations (ignor- (where op is a relation or function) has type τ if all vari- ing Declassified outputs) along the two traces must also be ables {v1, . . . , vn} have type τ or lower. That is, an expres- equivalent. sion may have type ⊥ iff its value is independent of Secrets. ∗ ∀σ ∈ Σ, t1, t2 ∈ Σ .(hpenc−H−sec, σi ⇓ t1 ∧ hpenc−H−sec, σi ⇓ t2 For a statement s to have type τ, every assignment in s must update a state variable whose security class is τ or ∧ ∀i.t1|H[i] = t2|H[i]) ⇒ higher. We write this typing judgment as [τ] ` s ⇒ hψ, Fi, (∀i, j. ¬epc(j) ⇒ ((i, mem[j]) ∈ Declassified where ψ is a first-order (SMT) formula and F is a set of ∨ t1|obs[i].mem[j] = t2|obs[i].mem[j])) (11) first-order (SMT) formulae. Each satisfiable interpretation of ψ corresponds to a feasible execution of s. F contains a 7. PROVING CONFIDENTIALITY SMT formula for each instruction in s, such that the formula is valid iff that instruction does not leak secrets. We present Moat automatically checks if p satisfies confidential- enc−H our typing rules in Figure 7, which assume that p is ity (property 11). Since confidentiality is a 2-safety hyper- enc−H first converted to single static assignment form. s has type property (property over pairs of traces), we cannot use black τ if we derive [τ] ` s ⇒ hψ, Fi using the typing rules, and box program verification techniques, which are tailored to- prove that all formulae in F are valid. If s has type >, then wards safety properties. Hence, we create a security type s does not update H-visible state, and thus cannot contain system in which type safety implies that p satisfies enc−H information leaks. Having type > also allows s to execute in confidentiality. We avoid a self-composition approach be- a context where a secret value is implicitly known through cause of complications in encoding equivalence assumptions the guard of a conditional statement. On the other hand, over adversary operations in the two traces of p enc−H−sec type ⊥ implies that s either does not update H-observable (property 11). As in many type-based systems [34, 28], the state or the update is independent of Secrets. typing rules prevent programs that have explicit and implicit By Theorem 1, p models all potential runtime be- information leaks. Explicit leaks occur via assignments of enc−H haviours of p in the presence of an active adversary, and secret values to H-observable state i.e. σ| . For instance, enc obs hence Moat feeds p to the type checking algorithm. We mem := store(mem,a,d) is ill-typed if d’s value depends on a enc−H now explain some of our typing rules from Figure 7. For each secret and enc(a) is false i.e. it writes a secret to non-enclave variable v ∈ Vars within p , our typing rules introduce memory. An implicit leak occurs when a conditional state- enc−H a ghost variable C that is true iff v has security type >. For ment has a secret-dependent guard, but updates H-visible v a scalar register v, C is a boolean; for an array variable v, C state in either branch. For instance, if (d == 42) {mem := v v (e.g. C ) is an array and C [i] denotes the security type store(mem, a, 1)} else {skip} is ill-typed if d’s value depends mem v for each location i. exp1 rule allows inferring the type of on a secret and enc(a) is false. In both examples above, H any expression e as >. exp2 rule allows inferring an expres- learns the secret value d by reading mem at address a. In sion type e as ⊥ if we derive C to be false for all variables addition to the store instruction, explicit and implicit leaks v v in the expression e. storeL rule marks the memory loca- may also be caused by unsafe use of SGX instructions. For tion as secret if the stored data is secret. In case of secret instance, egetkey returns a secret sealing key, which must data, we assert that the updated location is within mem ; not be leaked from the enclave. Similarly, ereport generates ¬enc we also assert that the address is public to prevent implicit a signed report containing public values (e.g. measurement) leaks. Since storeH rule types store instructions as >, it un- and potentially secret values (enclave code may bind upto conditionally marks the memory location as secret. This is 64 bytes of data, which may be secret). Our type system necessary because the store may execute in a context where models these details of SGX accurately, and accepts p enc−H a secret is implicitly known through the guard of a condi- only if it has no implicit or explicit leaks. tional statement. load marks the updated register as secret A security type is either > (secret) or ⊥ (public). At each if the memory location contains a secret value. ereportL rule program location, each memory location and CPU register types the updated memory locations as per SGX semantics. has a security type based on the x86+SGX instructions ex- ereport takes 64 bytes of data (that the programmer intends ecuted until that label. The security types are needed at to bind to the measurement) at address in ecx, and copies each program location because variables (especially regs) them to memory starting at address edx + 320; the rest of may alternate between holding secret and public values. the report has public data such as the MAC, measurement, As explained later in this section, Moat uses the security etc. Hence, C retains the secrecy level for the 64 bytes types in order to decide whether instructions in p have mem enc−H of data, and assumes false for the public data. Similar to implicit or explicit leaks. p has Secrets = {(l, v)} enc−H storeH, ereportH unconditionally marks all 432 bytes of the and Declassified = {(l, v)} annotations. However, there report as secret. egetkey stores 16 bytes of the sealing key are no other type declarations; therefore, Moat implements at address ecx, hence the egetkey rule marks those 16 bytes a type inference algorithm based on computing refinement in C as secret. Notice that we do not assert that ereport type constraints and checking their validity using a theorem mem and egetkey writes to enclave memory since this is enforced prover. In contrast, type checking without inference would by SGX. eexit jumps to the host application without clear- require the programmer to painstakingly provide security ing regs. Hence, the eexit rule asserts that those regs hold types for each memory location and CPU register, at each public values. We prove the following type soundness theo- program location — flow sensitivity and type inference are rem (machine-checked proof available at [2]). key requirements of type checking machine code. Moat’s type inference algorithm computes first-order logi- cal constraints under which an expression or statement takes Theorem 2. For any penc−H such that [τ] ` penc−H ⇒ a security type. A typing judgment ` e : τ ⇒ ψ means that (ψ, F) is derivable (where τ is either > or ⊥) and all for- the expression e has security type τ whenever the constraint mulae in F are valid, penc−H satisfies property 11. Moat implements this type system by replacing each state- (exp1 ) V (exp2 ) ment s in penc−H by I(s) using the instrumentation rules ` e : > ⇒ true ` e : ⊥ ⇒ ¬Cv v∈V ars(e) in Figure 8. Observe that we introduce Cpc to track whether [>] ` s ⇒ hψ, Ai confidential information is implicitly known through the pro- (coercion) gram counter. If a conditional statement’s guard depends on [⊥] ` s ⇒ hψ, Ai (skip) [>] ` skip ⇒ htrue, {∅}i a secret value, then we set Cpc to true within the then and (assume) else branches. Moat invokes I(penc−H) and applies the in- [τ] ` assume φ ⇒ hφ, {∅}i (assert) strumentation rules in Figure 8 recursively. Figure 4 demon- [τ] ` assert φ ⇒ hφ, {φ}i strates an example of instrumenting penc−H. Moat then feeds the instrumented program I(penc−H) to an off-the-shelf pro- 0 0 W (scalar) gram verifier, which proves validity all assertions or finds a [τ] ` x := e ⇒ h(x = e) ∧ (C 0 ↔ C ), {∅}i x v counter-example. Our implementation uses the Boogie [6] v∈V ars(e) program verifier, which receives I(penc−H) and generates ` ea : ⊥ ⇒ ψa verification conditions in the SMT format. Boogie uses the 0 (load) [τ] ` x := load(mem, ea) ⇒ Z3 [17] theorem prover (SMT solver) to prove the verifica- 0 h(x = load(mem, ea)) ∧ (Cx0 ↔ Cmem[ea]), {ψa}i tion conditions. An advantage of using SMT solving is that a typing error is explained using counter-example execution, ` ea : ⊥ ⇒ ψa demonstrating the information leak and exploit. 0 (storeH ) [>] ` mem := store(mem, ea, ed) ⇒ 0 hmem = store(mem, ea, ed) ∧ Cmem0 = Cmem[ea := true], Statement s Instrumented Statement I(s) {ψa ∧ enc(ea)}i assert φ assert φ assume φ assume φ skip skip ` ea : ⊥ ⇒ ψa ` ed : ⊥ ⇒ ψd (storeL) havoc mem¬epc havoc mem¬epc 0 W [⊥] ` mem := store(mem, ea, ed) ⇒ x := e Cx := Cpc ∨ v∈V ars(e) Cv; x := e 0 V hmem = store(mem, ea, ed) ∧ Cmem0 = Cmem[ea := ψd], x := load(mem, e) assert v∈V ars(e) ¬Cv; {ψa ∧ (¬enc(ea) → ψd)}i Cx := Cpc ∨ Cmem[e]; x := load(mem, e) V mem := assert v∈V ars(e ) ¬Cv; assert Cpc → enc(ea); a V store assert (¬Cpc ∧ ¬enc(ea)) → ( v∈V ars(e ) ¬Cv); W d (mem, ea, ed) Cmem[ea] := Cpc ∨ Cv; 0 (ereportL) v∈V ars(ed) [⊥] ` mem := ereport(mem, ebx, ecx, edx) ⇒ mem := store(mem, ea, ed) 0 old hmem = ereport(mem, ebx, ecx, edx) ∧ mem := assert ¬Cedx; Cmem := Cmem; havoc Cmem; ∀i. (edx ≤ i < edx + 320) → Cmem0 [i] ↔ false ereport assume ∀i. (edx ≤ i < edx + 320) → Cmem[i] = Cpc; ∧ (edx + 320 ≤ i < edx + 384) → (mem, ebx, ecx, edx) assume ∀i. (edx + 320 ≤ i < edx + 384) → C [i] = (C ∨ Cold [ecx + i − edx − 320]); Cmem0 [i] ↔ Cmem[ecx + i − edx − 320] mem pc mem assume ∀i. (edx + 384 ≤ i < edx + 432) → ∧ (edx + 384 ≤ i < edx + 432) → Cmem0 [i] ↔ false Cmem[i] = Cpc; ∧ ¬(edx ≤ i < edx + 432) → Cmem0 [i] ↔ Cmem[i], old assume ∀i. ¬(edx ≤ i < edx + 432) → Cmem[i] = Cmem[i]; {¬Cedx}i mem := ereport(mem, ebx, ecx, edx) old mem := assert ¬Cecx; Cmem := Cmem; havoc Cmem; egetkey assume ∀i. (ecx ≤ i < ecx + 16) → Cmem[i]; old 0 (ereportH ) (mem, ebx, ecx) assume ∀i. ¬(ecx ≤ i < ecx + 16) → Cmem[i] = Cmem[i]; [>] ` mem := ereport(mem, ebx, ecx, edx) ⇒ mem := egetkey(mem, ebx, ecx) 0 hmem = ereport(mem, ebx, ecx, edx) ∧ mem, regs := assert ∀r ∈ regs. ¬Cr; ( , ebx) , := ( ) ∀i. (edx ≤ i < edx + 432) → (Cmem0 [i] ↔ true) eexit mem mem regs eexit mem s ; s I(s ); I(s ) ∧ ¬(edx ≤ i < edx + 432) → (C 0 [i] ↔ Cmem[i]), 1 2 1 2 mem in {¬C }i if(e){s1}else{s2} Cpc := Cpc; edx W Cpc := Cpc ∨ v∈V ars(e) Cv; if (e) {I(s1)} else {I(s2)}; C := Cin (egetkey) pc pc [τ] ` mem0 := egetkey(mem, ebx, ecx) ⇒ 0 hmem = egetkey(mem, ebx, ecx) ∧ Figure 8: Instrumentation rules for penc−H ∀i. (ecx ≤ i < ecx + 16) → Cmem0 [i] ↔ true ∧ ¬(ecx ≤ i < ecx + 16) → Cmem0 [i] ↔ Cmem[i], {¬Cecx}i In summary, Moat’s type system is inspired by the type- based approach for information flow checking by Volpano et (eexit) [τ] ` mem0, regs0 := eexit(mem) ⇒ al. [34]. The core modifications are as follows: 0 0 h(mem , regs ) = eexit(mem), {∀r ∈ regs. ¬Cr}i • Our type system includes rules for SGX instructions ereport, [τ] ` s1 ⇒ hψ1, F1i [τ] ` s2 ⇒ hψ2, F2i (seq) egetkey, and eexit. The rules precisely model the mem- [τ] ` s1; s2 ⇒ hψ1 ∧ ψ2, F1 ∪ {ψ1 → f2 | f2 ∈ F2}i ory locations written by these these instructions, and whether the produced data is public or confidential. ` e : τ ⇒ ψ [τ] ` s1 ⇒ hψ1, F1i [τ] ` s2 ⇒ hψ2, F2i (ite) [τ] ` if (e) {s1} else {s2} ⇒ • Our type system is flow-sensitive and path-sensitive, and h(e → ψ1) ∧ (¬e → ψ2), performs type inference. A program is well-typed if the {ψ} ∪ {e → f | f ∈ F } ∪ {¬e → f | f ∈ F }i 1 1 1 2 2 2 typing assertions are valid in all feasible executions. We ensure soundness by using a sound program verifier to ex- Figure 7: Typing Rules for penc−H plore all feasible executions of the instrumented penc−H. bc • Our type system includes rules for updating unbounded First, we use Moat to prove that g and Kseal are not array variables (e.g. mem), without requiring that all in- leaked to H. Next, ProVerif uses secrecy assumption on gbc dices in the array take the same security type. and Kseal to prove that secret is not leaked to a network ad- versary. This proof allows Moat to declassify client’s output to disk while proving property 11. Moat successfully proves that the client enclave satisfies confidentiality. 8. EVALUATION AND EXPERIENCE Moat’s implementation comprises (1) translation from x86 Notary Service. + SGX program to penc using BAP, (2) transformation to We implement a notary service introduced by [21] but penc−H using instrumentation in4, (3) transformation to adapted to run on SGX. The notary enclave assigns logi- I(penc−H) using Figure 8, and (4) invoking the Boogie veri- cal timestamps to documents, giving them a total ordering. fier to prove validity of all assertions in I(penc−H) (modulo The notary enclave responds to (1) a connect message for declassifications from the protocol verification step). obtaining the attestation report, and (2) a notarize message Optimizations: Our primary objective was to build a sound for obtaining a signature over the document hash and the verifier for proving confidentiality in the presence of an ac- current counter. tive adversary. However, due to certain scalability chal- lenges, we implement the following optimizations. First, user → notary : connect | N we only introduce havoc mem¬epc prior to load instructions notary → user : Quotenotary(N) because only a load can be used to read mem¬epc. Further- user → notary : notarize | H(text) more, we axiomatize specific library calls such as memcpy notary → user : counter | H(text) | and memset, because their loopy implementations incur sig- Sig −1 (counter | H(text)) nificant verification overhead. Knotary We now describe some case studies which we verified us- −1 ing Moat and ProVerif in tandem, and summarize the results The only secret here is the private signature key Knotary. −1 in Figure 9. We use the following standard crytpographic no- First, we use Moat to prove that Knotary is not leaked to H. tation and assumptions. m1| ... |mn denotes tagged concate- This proof fails because the output of Sig (in the response nation of n messages. We use a keyed-hash message authen- to notarize message) depends on the secret signature key — tication function MACk(text) and hash function H(text), Moat is unaware of cryptographic properties of Sig. ProVerif −1 both of which are assumed to be collision-resistant. For proves that this message does not leak Knotary to a network −1 asymmetric cryptography, Ke and Ke are principal e’s pri- adversary, which allows Moat to declassify this message and vate and public signature keys, where we assume that Ke is prove that the notary enclave satisfies confidentiality. long-lived and distributed within certificates signed by a root of trust authority. Digital signature using a key k is written End-to-End Encrypted Instant Messaging. as Sigk(text); we assume unforgeability under chosen mes- We implement the off-the-record messaging protocol [13], sage attacks. Intel provisions each SGX processor with a which provides perfect forward secrecy and repudiability −1 unique private key KSGX that is available to a special quot- for messages exchanged between principals A and B. We ing enclave. In combination with this quoting enclave, an en- adapt this protocol to run on SGX, thus providing an addi- clave can invoke ereport to produce quotes, which is essen- tional guarantee that an infrastructure attack cannot com- −1 tially a signature (using the private key KSGX ) of the data promise the ephemeral Diffie-Hellman keys, which encrypt produced by the enclave and its measurement. We write a and integrity-protect the messages between A and B. We quote produced on behalf of enclave e as Quotee(text), which only present a synchronous form of communication here for is equivalent to Sig −1 (H(text) | Me) — measurement of simplicity. KSGX enclave e is written as Me. N is used to denote nonce. a1 a1 a1 A → B : g | SigK−1 (g ) | QuoteA(SigK−1 (g )) Finally, we write Enck(text) for the encryption of text, for A A b1 b1 b1 which we assume indistinguishability under chosen plaintext B → A : g | Sig −1 (g ) | QuoteB (Sig −1 (g )) KB KB attack. We also use AEnck(text) for authenticated encryp- a2 a2 tion, for which we assume indistinguishability under chosen A → B : g | EncH(ga1b1 )(m1) | MACH(H(ga1b1 ))(g | plaintext attack and integrity of ciphertext. Recall that al- EncH(ga1b1 )(m1)) though the enclave code contains calls to these cryptographic b2 b2 primitives, Moat abstracts them as uninterpreted functions B → A : g | EncH(ga2b1 )(m2) | MACH(H(ga2b1 ))(g | with basic memory safety axioms. We use cryptopp [1] in EncH(ga2b1 )(m2)) our case studies, and we do not verify its implementation. a3 a3 A → B : g | EncH(ga2b2 )(m3) | MACH(H(ga2b2 ))(g |
One-time Password Generator. EncH(ga2b2 )(m3)) The abstract model of the OTP secret provisiong protocol The OTR protocol only needs a digital signature on the (from § 2), where client runs in a SGX enclave, bank is an initial Diffie-Hellman exchange — future exchanges use MACs uncompromised service, and disk is under adversary control: to authenticate a new key using an older, known-authentic bank → client : N key. For the same reason, we only append a SGX quote to c c the initial key exchange. First, we use Moat to prove that the client → bank : N | g | Quoteclient(N | g ) a1b1 a2b1 Diffie-Hellman secrets computed by penc (i.e. g , g , b b a b bank → client : N | g | Sig −1 (N | g ) | AEncH(gbc)(secret) g 2 2 ) are not leaked to H. Next, ProVerif uses this secrey Kbank assumption to prove that messages m1, m2, and m3 are not client → disk : AEncKseal (secret) leaked to the network adversary. The ProVerif proofs al- verification techniques also exist for quantitative informa- lows Moat to declassify all messages following the initial key tion flow (e.g., [22]). However, these works assume that the exchange, and successfully prove confidentiality. infrastructure (OS/VMM, etc.) on which the code runs is safe, which is unrealistic due to malware and other attacks. Query Processing over Encrypted Database. Our approach builds upon this body of work, showing how In this case study, we evaluate Moat on a stand-alone ap- it can be adapted to the setting where programs run on plication, removing the possibility of protocol attacks and an adversarial OS/VMM, and instead rely on trusted SGX therefore the need for any protocol verification. We build a hardware for information-flow security. database table containing two columns: name which is deter- Cryptographic Protocol Verification. There is a vast ministically encrypted, and amount which is nondeterminis- literature on cryptographic protocol verification (e.g. [11, tically encrypted. Alice wishes to select all rows with name 12]). Our work builds on top of cryptographic protocol ver- “Alice” and sum all the amounts. We partition this com- ifiers showing how to use them to reason about protocol putation into two parts: unprivileged computation (which attacks and to generate annotations for more precise ver- selects the rows) and enclave computation (which computes ification of enclave programs. In the future, it may also the sum). be possible to connect our work to the work on correct- by-construction generation of cryptographic protocol imple- Benchmark x86+SGX BoogiePL Moat Policy mentation [19]. instructions statements proof Annotations OTP 188 1774 9.9 sec 4 10. CONCLUSION Notary 147 1222 3.2 sec 2 This paper introduces a technique for verifying informa- OTR IM 251 2191 7.8 sec 7 tion flow properties of enclave programs. Moat is a first step Query 575 4727 55 sec 9 towards building an end-to-end verifier. Our current evalu- Figure 9: Summary of experimental results. ation uses separate models for Moat and ProVerif. In future, Columns are (1) instructions analyzed by Moat not we plan to design a high-level language from which we gen- erate machine code, enclave model, and a protocol model. including crypto library, (2) size of I(penc−H), (3) proof time, (4) number of secret and declassifed an- notations 11. ACKNOWLEDGMENTS This research is supported in part by SRC contract 2460.001 and NSF STARSS grant 1528108. We gratefully acknowl- edge Brent ByungHoon Kang and the anonymous reviewers 9. RELATED WORK for their insightful feedback. Our work relates three somewhat distinct areas in security. 12. REFERENCES Secure Systems on Trusted Hardware. In recent years, [1] Available at http://www.cryptopp.com/. there has been growing interest in building secure systems [2] https://devmoat.github.io. on top of trusted hardware. Sancus [29] is a security archi- [3] P. Akritidis, C. Cadar, C. Raiciu, M. Costa, and tecture for networked embedded devices that seeks to pro- M. Castro. Preventing memory error exploits with wit. vide security guarantees without trusting any infrastructural In Proceedings of the 2008 IEEE Symposium on software, only relying on trusted hardware. Intel SGX [23] Security and Privacy, SP ’08, pages 263–277, seeks to provide similar guarantees via extension to the x86 Washington, DC, USA, 2008. IEEE Computer Society. instruction set. There are some recent efforts on using SGX [4] ARM Security Technology - Building a Secure System for trusted computation. Haven [10] is a system that exploits using TrustZone Technology. ARM Technical White Intel SGX for shielded execution of unmodified Windows ap- Paper. plications. It links the application together with a runtime library OS that implements the Windows 8 API. However, it [5] M. Balliu, M. Dam, and R. Guanciale. Automating does not provide any confidentiality or integrity guarantees, information flow analysis of low level code. In and includes a significant TCB. VC3 [33] uses SGX to run Proceedings of the 2014 ACM SIGSAC Conference on map-reduce computations while protecting data and code Computer and Communications Security, CCS ’14, from an active adversary. However, VC3’s confidentiality pages 1080–1091, New York, NY, USA, 2014. ACM. guarantee is based on the assumption that enclave code does [6] M. Barnett, B. E. Chang, R. DeLine, B. Jacobs, and not leak secrets, and we can use Moat to verify this assump- K. R. M. Leino. Boogie: A modular reusable verifier tion. Santos et al. [32] seek to build a trusted language run- for object-oriented programs. In FMCO ’05, LNCS time for mobile applications based on ARM TrustZone [4]. 4111, pages 364–387, 2005. These design efforts have thrown up very interesting associ- [7] M. Barnett and K. R. M. Leino. Weakest-precondition ated verification questions, and our paper seeks to address of unstructured programs. In PASTE ’05, pages these with a special focus on Intel SGX. 82–87, 2005. Verifying Information Flow on Programs. Checking [8] C. Barrett, R. Sebastiani, S. A. Seshia, and C. Tinelli. implementation code for safety is also a well studied prob- Satisfiability modulo theories. In A. Biere, H. van lem. Type systems proposed by Sabelfeld et al. [31], Barthe Maaren, and T. Walsh, editors, Handbook of et al. [9], and Volpano et al. [34] enable the programmer to Satisfiability, volume 4, chapter 8. IOS Press, 2009. annotate variables that hold secret values, and ensure that [9] G. Barthe and L. P. Nieto. Secure information flow for these values do not leak. Balliu et al. [5] automate informa- a concurrent language with scheduling. In Journal of tion flow analysis of ARMv7 machine code. Languages and Computer Security, pages 647–689. IOS Press, 2007. [10] A. Baumann, M. Peinado, and G. Hunt. Shielding [24] Intel Software Guard Extensions Programming applications from an untrusted cloud with Haven. In Reference. Available at https://software.intel. USENIX Symposium on Operating Systems Design com/sites/default/files/329298-001.pdf. and Implementation (OSDI), 2014. [25] G. Klein, K. Elphinstone, G. Heiser, J. Andronick, [11] B. Blanchet. An Efficient Cryptographic Protocol D. Cock, P. Derrin, D. Elkaduwe, K. Engelhardt, Verifier Based on Prolog Rules. In 14th IEEE R. Kolanski, M. Norrish, T. Sewell, H. Tuch, and Computer Security Foundations Workshop, pages S. Winwood. sel4: Formal verification of an os kernel. 82–96, Cape Breton, Canada, June 2001. In Proceedings of the ACM SIGOPS 22nd Symposium [12] B. Blanchet. A computationally sound automatic on Operating Systems Principles, SOSP ’09, pages prover for cryptographic protocols. In Workshop on 207–220, New York, USA, 2009. the link between formal and computational models, [26] F. McKeen, I. Alexandrovich, A. Berenzon, C. V. Paris, France, June 2005. Rozas, H. Shafi, V. Shanbhogue, and U. R. [13] N. Borisov, I. Goldberg, and E. Brewer. Off-the-record Savagaonkar. Innovative instructions and software communication, or, why not to use pgp. In Proceedings model for isolated execution. In Proceedings of the 2nd of the 2004 ACM Workshop on Privacy in the International Workshop on Hardware and Electronic Society, WPES ’04, pages 77–84, New York, Architectural Support for Security and Privacy, HASP NY, USA, 2004. ACM. ’13, pages 10:1–10:1, New York, NY, USA, 2013. [14] D. Brumley, I. Jager, T. Avgerinos, and E. J. ACM. Schwartz. BAP: A binary analysis platform. In [27] J. Mclean. Proving noninterference and functional Proceedings of the 23rd International Conference on correctness using traces. Journal of Computer Computer Aided Verification, CAV’11, pages 463–469, Security, 1:37–58, 1992. 2011. [28] A. C. Myers and B. Liskov. A decentralized model for [15] R. E. Bryant, S. K. Lahiri, and S. A. Seshia. Modeling information flow control. In Proceedings of the 16th and Verifying Systems using a Logic of Counter ACM Symposium on Operating Systems Principles, Arithmetic with Lambda Expressions and SOSP ’97, pages 129–142, New York, USA, 1997. Uninterpreted Functions. In Computer-Aided [29] J. Noorman, P. Agten, W. Daniels, R. Strackx, Verification (CAV’02), LNCS 2404, pages 78–92, July A. Van Herrewege, C. Huygens, B. Preneel, 2002. I. Verbauwhede, and F. Piessens. Sancus: Low-cost [16] M. R. Clarkson and F. B. Schneider. Hyperproperties. trustworthy extensible networked devices with a Journal of Computer Security, 18(6):1157–1210, Sept. zero-software trusted computing base. In Proceedings 2010. of the 22nd USENIX Conference on Security, pages [17] L. de Moura and N. Bjørner. Z3: An efficient SMT 479–494, 2013. solver. In TACAS ’08, pages 337–340, 2008. [30] A. Sabelfeld and A. C. Myers. Language-based [18] Z. Durumeric, J. Kasten, D. Adrian, J. A. Halderman, information-flow security. Selected Areas in M. Bailey, F. Li, N. Weaver, J. Amann, J. Beekman, Communications, IEEE Journal on, 21(1):5–19, 2003. M. Payer, and V. Paxson. The matter of heartbleed. [31] A. Sabelfeld and A. C. Myers. A model for delimited In Proceedings of the 2014 Conference on Internet information release. In In Proc. International Symp. Measurement Conference, pages 475–488, 2014. on Software Security, pages 174–191. Springer-Verlag, [19] C. Fournet and T. Rezk. Cryptographically sound 2004. implementations for typed information-flow security. [32] N. Santos, H. Raj, S. Saroiu, and A. Wolman. Using In Proceedings 35th Symposium on Principles of ARM TrustZone to build a trusted language runtime Programming Languages. G. Smith, 2008. for mobile applications. In Proceedings of the 19th [20] V. Ganapathy, S. A. Seshia, S. Jha, T. W. Reps, and international conference on Architectural support for R. E. Bryant. Automatic discovery of API-level programming languages and operating systems exploits. In Proceedings of the 27th International (ASPLOS), pages 67–80. ACM, 2014. Conference on Software Engineering (ICSE), pages [33] F. Schuster, M. Costa, C. Fournet, C. Gkantsidis, 312–321, May 2005. M. Peinado, G. Mainar-Ruiz, and M. Russinovich. [21] C. Hawblitzel, J. Howell, J. R. Lorch, A. Narayan, VC3: trustworthy data analytics in the cloud using B. Parno, D. Zhang, and B. Zill. Ironclad apps: SGX. In 2015 IEEE Symposium on Security and end-to-end security via automated full-system Privacy, SP 2015, San Jose, CA, USA, May 17-21, verification. In Proceedings of the 11th USENIX 2015, pages 38–54, 2015. conference on Operating Systems Design and [34] D. Volpano, C. Irvine, and G. Smith. A sound type Implementation, pages 165–181, 2014. system for secure flow analysis. Journal of Computer [22] J. Heusser and P. Malacaria. Quantifying information Security, 4(2-3):167–187, Jan. 1996. leaks in software. In Proceedings of the 26th Annual [35] J. Yang and C. Hawblitzel. Safe to the last Computer Security Applications Conference, pages instruction: Automated verification of a type-safe 261–269. ACM, 2010. operating system. In Proceedings of the 31st [23] M. Hoekstra, R. Lal, P. Pappachan, C. Rozas, Conference on Programming Language Design and V. Phegade, and J. Cuvillo. Using innovative Implementation, pages 99–110, 2010. instructions to create trustworthy software solutions. In Workshop on Hardware and Architectural Support for Security and Privacy, 2013.