Introduction to SGX — The ELI5
--
This is the first of an ongoing series as we explain our technology in simple, easily understood terms. Read the 2nd part here, and the final article here.
Modern Intel chips support a feature called Software Guard Extensions (SGX). SGX allows applications to provision a “secure enclave” that is isolated from the host operating system and kernel. In this post we will aim to ELI5 what Intel’s SGX is all about — no technical background required!
Intel SGX provides an opaque box which, if implemented correctly, prevents anyone — including the owner of the box, from looking inside. Think of it as an impenetrable secret base where your trusty sidekick can be stationed in. This base is also an outpost where all your world-saving plans can be made and the associated fancy gadgets stored.
You might be thinking that this sounds too good to be true. Well, in the following series of posts we will be exploring what Trusted Execution Environments (TEEs) are and specifically, what guarantees Intel SGX brings to the table. We will also explore the issues surrounding the usage of such systems.
What TEEs like Intel SGX provide
They provide a protected environment in which computation can be performed without being observed by a third party. This allows for the off-loading of confidential computations to machines that are not directly under the control of the user. This is achieved using cryptographic primitives through a careful collaboration between both the hardware and software layer. Specifically, Intel SGX provides two fundamental primitives that allow for the creation of a protected environment and the utilization of said protected environment, data-in-use confidentiality along with integrity and remote attestation.
I know we promised a ELI5. Here it is:
Imagine for a moment that the CPU is a data entry clerk whose job is to take incoming tax documents and store them into a spreadsheet. These documents can come in sealed envelopes, or they can just be documents sitting out there in plain sight. Other than the clerk, there is a nosy parker/busybody who is snooping around trying to peek at all these documents. Traditionally, the clerk works in a common room accessible by everyone including the busybody. While the busybody is unable to look at the documents when it is sealed in the envelopes, there is nothing to stop him from looking over the clerk’s shoulder as envelopes are unsealed to be processed. What Intel SGX provides is a separate office which only the clerk has access to. The clerk can now work in this office, free from prying eyes. The sealed documents can be delivered directly to the office, unsealed, processed, destroyed or resealed. The busybody is now unable to read any of those documents.
While we might proclaim the problem solved at this point in time and give ourselves a pat on our backs, consider this scenario — one day when the clerk is not around, our dear busybody, fed-up with his inability to peek at all the juicy sealed tax documents, decides to sneak into clerk’s office and hides himself. The clerk, being blissfully unaware that the busybody is in the office, continues with the work of unsealing the documents, inadvertently revealing all the tax documents to the nosy busybody.
This is where the second primitive comes into play — remote attestation. Remote attestation is a process by which an entity can prove to a remote third party on the integrity of its environment, from the software all the way down to the hardware using cryptographic hashes and proofs.
Remote attestation allow us to be confident that the environment is indeed what we think it is before attempting to use it. Back to our ELI5 example, we can attest that the only person in the room is the clerk and there are no busybodies or spying devices in the room before we proceed to send in the sealed envelopes for clerk to unseal.
Now that you understand the concepts, let’s link them to the actual SGX terms.
Enclave
In many TEE technologies, enclave refers to the trusted execution mode created by the CPU. It’s a mode where memory regions (Enclave Page Cache) are encrypted by a private key possessed by the CPU (or more specifically, Memory Encryption Engine). The enclave is resistant to physical attacks such as memory bus tapping. This is analogous to the separate office for the clerk we referred to in the earlier example. The code and data inside the enclave cannot be accessed or tampered by any other user-level processes or even operating systems. No one, including the building manager can enter the office.
Remote Attestation
In our example remote attestation is the process of sweeping the separate office for busybodies or spy devices before opening the envelope.
Before anyone trusts an enclave, remote attestation is necessary so that the hardware and the software running in the enclave can be cryptographically verified. This includes checking if the CPU is genuine hardware manufactured by vendors such as Intel, if the other assisting enclaves running on the operation systems are trustworthy, and if the enclave is running the actual copy of the code that the user expects. The hardware check is based on asymmetric cryptography where private keys are incorporated into CPU during manufacturing and the corresponding public keys are recorded by manufacturers to prove the genuineness during a remote attestation. The software check is based on the measurement (cryptography hash) of any code and data that is loaded into the enclave at launch. This runtime measurement has to exactly match the measurement made during the building of the enclave software as intended by the developers.
End-to-end Security
The enclave software typically doesn’t carry any secrets as it’s plaintext code and data released as software packages. Therefore end-to-end security plays a vital role as it allows the user to provision any secret data into the enclave for next-step processing after remote attestation. When data is moving out from the enclave, it’s encrypted by the enclave to ensure data-at-rest security. The end-to-end secure channel can be established between the user and the running enclave using the information coming from the remote attestation. Similarly, two enclaves can establish secure channels to allow a chained computation.
To explain this using the previous example, it is the end-to-end process of the documents being sealed by the user in an envelope before sending out and upon receipt, can only be opened by the clerk inside the separate office.
Programming Model — where Oblivious RAM (ORAM) comes into play
TEE is not the magical pill that solves all problems. While there might not be major differences in developing enclave software vis-a-vis developing traditional software in terms of the programming language and tools, it requires developers to be aware of the limitations of the protection provided by the hardware during development. Developing an enclave software requires domain-specific knowledge regarding the hardware architecture and best practices in secure programming, specifically things like attestation, secret provisioning, etc. A commonly missed aspect of secure programming is the reasoning of side-channels. Developers have to understand the implications of certain memory and storage operations and not fall victim to such vulnerabilities. Oblivious RAM (ORAM), which serves as a proxy between the enclave and data store would help minimize this risk drastically. We will dive into the details in a future post, stay tuned.
A little about us
The Automata team has been researching TEE for many years and have hands-on experience in implementing distributed, high-performance and privacy-preserving systems, such as peer-to-peer computation and storage and DDoS defense. Research papers by the team have been published at top-tier security conferences. Here’s a list of selected publications.
- Robust P2P Primitives Using SGX Enclaves [RAID 2020]
- PRO-ORAM: Practical Read-Only Oblivious RAM [RAID 2019]
- OblivP2P: An Oblivious Peer-to-Peer Content Sharing System [USENIX Security 2016]
- Practical Verifiable In-network Filtering for DDoS Defense [ICDCS 2019]
- One Engine To Serve’em All: Inferring Taint Rules Without Architectural Semantics [NDSS 2019]
- BesFS: A POSIX Filesystem for Enclaves with a Mechanized Safety Proof [USENIX Security 2020]
- Panoply: Low-TCB Linux Applications With SGX Enclaves [NDSS 2017]
- Preventing Page Faults from Telling your Secrets [ASIACCS 2016]
