SGAxe: How SGX Fails in Practice Stephan van Schaik Andrew Kwong Daniel Genkin Yuval Yarom University of Michigan University of Michigan University of Michigan University of Adelaide and Data61 [email protected] [email protected] [email protected] [email protected] Abstract—Intel’s Software Guard Extensions (SGX) promises the associated cryptographic keys inaccessible to software. an isolated execution environment, protected from all software Finally, SGX provides a remote attestation mechanism, which running on the machine. A significant limitation of SGX is its allows enclaves to prove to remote parties that they have been lack of protection against side-channel attacks. In particular, recent works have shown that transient-execution attacks can correctly initialized on a genuine (hence, presumed secure) leak arbitrary data from SGX, breaching SGX’s confidentiality. Intel processor. However, less work has been done on the implications of such Notwithstanding its strong security guarantees, SGX does attacks on the SGX ecosystems. not protect against microarchitectural side channel attacks. In this work we start from CacheOut, a recent confidentiality As acknowledged by Intel, “SGX does not defend against attack on SGX, which allows the retrieval of an enclave’s memory contents. We show how CacheOut can be leveraged this adversary” [46, Page 115] arguing that “preventing side to compromise the confidentiality and the integrity of a victim channel attacks is a matter for the enclave developer” [45]. enclave’s long-term storage. By using the extended attack against Starting with the controlled channel attack [94], numerous the Intel-provided and signed architectural SGX enclaves, we works have demonstrated side channel attacks on or from retrieve the secret attestation key used for cryptographically SGX enclaves [10, 21, 23, 32, 67, 91, 92]. Foreshadow [85] proving the genuinity of enclaves over the network, allowing us to pass fake enclaves as genuine. Finally, we analyze the impact and following transient-execution attacks [17, 56, 79, 86, 87], of our attack on two proposed SGX applications, the Signal demonstrated the capability of recovering contents from within communication app and Town Crier, an SGX-based blockchain the enclave’s memory space. application. Recognizing the danger, Intel released several patches, CPU microcode updates, and even new architectures designed to I. INTRODUCTION mitigate SGX side channel leakage via transient execution. However, the fix for TSX Asynchronous Abort (TAA) [44, 88], Trusted Execution Environments (TEEs) are architectural released in November 2019, was shown to be insufficient [79, extensions, recently introduced in commodity processors, 89, 90]. In particular, the CacheOut attack demonstrated the which collectively provide strong security guarantees to soft- capability to leak SGX data by first evicting the data from the ware running in the presence of powerful adversaries. TEEs’ cache and then using TAA to recover it. promise to allow secure execution on adversary-controlled While CacheOut shows the ability to steal data from machines has spawned many new applications [57, 76, 84, enclaves, it stops short of investigating the implications of 98, 100], both in academia [7,8, 11, 18, 24, 27, 38, 78, 98] this leak on the security of the SGX ecosystem. Given the and industry [1,2,4, 22, 25, 39, 60, 63, 80]. Whereas several increasing adoption of SGX as an alternative to heavyweight TEEs have been proposed (e.g., ARM’s TrustZone [6, 70, 75] cryptographic protocols [2, 18, 31, 63, 98], there is clear or AMD’s Secure Encrypted Virtualization [53]), the currently danger in deploying SGX-based protocols on current Intel prevailing x86 TEE implementation is Intel’s Software Guard machines. With several SGX-based works aiming to offer eXtensions (SGX) [20]. some security guarantees even in the presence of information To support private and secure code execution, SGX provides leakage, in this paper we ask the following questions: isolated execution environments, called enclaves, which offer What are the implications of information leakage from en- confidentiality and integrity guarantees to programs running claves on the security of the SGX ecosystem? In particular, can inside them. While SGX’s security properties strongly rely SGX-based protocols maintain their strong security guarantees on the processor’s hardware implementation, SGX removes in the presence of side channel attacks? all other system components (such as the memory hardware, the firmware, and the operating system) from the Trusted Computing Base (TCB). In particular, SGX ensures that the A. Our Contributions processor and memory states of an enclave are only accessible In this work we show that the security of the SGX ecosys- to the code running inside it and that they remain out of reach tem completely collapses, even in the presence of all currently- to all other enclaves and software, running at any privilege published countermeasures. Specifically, we test CacheOut on level, including a potentially malicious operating system (OS), a fully updated machine, including a dedicated GPU to avoid and/or the hypervisor. At a high level, SGX achieves these Intel’s Security Advisory SA-00219 [47], the latest SGX SDK strong security guarantees by encrypting enclave memory and Intel-signed enclaves for mitigating LVI [86], and all and protecting it with a secure authentication code, making of the countermeasures and microcode updates required to mitigate TAA [44, 79, 88], PlunderVolt [69], Zombieload [79], based secure remote computation protocols such as [1,2,7, RIDL [87] and Foreshadow [85]. We show that despite activat- 8, 11, 18, 22, 24, 27, 38, 39, 76, 78, 80, 98] as users cannot ing all countermeasures, CacheOut [90] can effectively dump trust that their data will be properly protected by a genuine the contents of SGX enclaves. SGX enclave. Moreover, we show that CacheOut does not need to execute Exploiting SGX’s Privacy Guarantees. Finally, we note code within the enclave to dump its contents. Instead, it that Intel’s Extended Privacy ID (EPID) [52] severely com- works while the enclave is completely idle. Thus, the attack pounds the consequences of compromised attestation keys. bypasses all software-based SGX side-channel defenses, such More specifically, when running in anonymous mode, EPID as constant-time coding and countermeasures that rely on signatures are unlinkable, meaning that an attestation output enclave code for ensuring protection [16, 26, 71, 77, 81]. cannot be linked to identity of the machine producing it [52]. Breaking the Integrity of Sealed Data. Next, going beyond This means that obtaining even a single EPID private key attacks on SGX’s confidentiality properties, in this work we allows us to forge signatures for the entire EPID group, extend CacheOut to also breach SGX enclaves’ integrity. which contains millions of SGX-capable Intel CPUs. Thus, Specifically, we target the SGX sealing mechanism [5], which the leak of even a single key from a single compromised provides long-term storage of data, by securely generating machine jeopardizes the trustworthiness of large parts of the an encryption key used to seal data by encrypting it before SGX ecosystem. Luckily however, the unlinkable attestation forwarding it to the operating system for long-term storage. mode is not recommended by default [52], allowing remote We use CacheOut to extract the sealing key from a victim stakeholders to recognize our attestation quotes as coming enclave. The main challenge is that the SGX SDK imple- from a different platform. mentation of the sealing API [40] wipes out the sealing key Undermining SGX-Based Protocols. To demonstrate the immediately after using it, leaving a short window in which concrete implications of our breach of SGX, we conduct case the key can be retrieved. After recovering the sealing key, we studies examining how actual protocols, in both academic use it to unseal and read the sealed information, then modify software and commercial products, may fail in practice when and reseal it. As SGX provides no integrity mechanism to they rely upon SGX. We explore the Signal App [3] and Town detect such a change, the victim enclave now operates on data Crier [98], which was acquired by ChainLink, a cryptocur- corrupted by the attacker. rency with a $1.5B market cap. We explore nuanced effects Breaking Remote Attestation Next, we turn our attention to that breaching the integrity and confidentiality of SGX has SGX’s remote attestation protocol, which allows an enclave to on reliant protocols. This discussion is vital for securing the prove to a remote party that it has been initialized correctly and future of SGX-reliant protocols and designing such protocols is executing on a genuine (presumably secure) Intel processor. to be resilient even when the underlying TEE is compromised. To attack attestation, we first use our attack on SGX’s sealing Summary of Contributions. In this paper we make the mechanism and retrieve the sealing key of the SGX Quoting following contributions: Enclave. Notably, unlike previous works [79, 86, 90] which • We use CacheOut to obtain the sealing key of enclaves, build and sign their own quoting enclave, we attack a genuine, including architectural enclaves compiled and signed by Intel-signed, production enclave, which employs all of Intel’s Intel (Section III). countermeasures for transient-execution attacks, including the • We show how to use the sealing key of the Intel’s Quoting recent hardening for the LVI attack [86]. enclave in order to retrieve the machine’s attestation key We then use the retrieved sealing key to unseal the persistent (Section III-C). storage of the Quoting Enclave, which contains the private • We show how to use the retrieved attestation key to forge attestation key. We note that this attestation key is the only SGX attestation quotes (Section IV). differentiating factor between a fully secure SGX enclave • Finally, we discuss the implications of a broken attestation running on genuine Intel hardware and a malicious SGX mechanism on Signal and on Town Crier (Section V).