Protecting information on a computer had traditionally focused on two conditions. Encryption could protect data while it was stored, and secure network protocols could protect it while it traveled between systems. Eventually, however, useful data had to be brought into memory so a program could work with it.
That created a difficult security boundary. An application might trust the operating system beneath it, the administrator controlling the machine, and other privileged software simply because those components normally had extensive access to system memory.
Intel SGX introduced processor instructions and memory protections that allowed an application to place selected code and data inside a protected execution area called an enclave.
The goal was not to put an entire computer inside another computer. It was to make a comparatively small portion of an application more difficult for software outside that protected area to inspect or modify.
The Security Boundary Moved Inside the Application
Ordinary process isolation separates applications from one another. The operating system manages those boundaries and normally remains more privileged than the programs it controls.
An enclave introduced another boundary within the application itself. Sensitive operations could be separated from the application’s ordinary code rather than assuming that everything running inside one process deserved equal access.
Most program logic could continue running normally and interact with the operating system, files, devices, networking, and the user interface.
Selected routines and sensitive data could operate inside a region protected by SGX access controls enforced with processor support.
This division encouraged developers to think about which portion of a program actually needed access to its most sensitive information. Instead of placing everything behind the same boundary, a smaller trusted component could be isolated.
The protected region could exist inside an ordinary application while following a different set of memory-access rules.
Entering the Enclave Changed the Execution Context
An enclave was not simply another allocated block of memory. The processor participated in controlling how enclave pages were established and how execution entered and left the protected environment.
Memory and code intended for protected execution are established according to the SGX enclave construction process.
The processor transitions execution into the enclave when the application calls an approved entry point.
Code operating within the enclave can work with information intended to remain isolated from ordinary software outside the enclave.
After the protected operation finishes, execution can leave the enclave and the rest of the application continues normally.
The application therefore did not live permanently inside the protected environment. Normal and enclave execution could cooperate, with transitions occurring when sensitive operations required the protected component.
Privilege Outside the Enclave Was Not the Same as Permission Inside It
Traditional computer security often assumes that software with greater system privilege can inspect software beneath it. Kernel components and administrative tools consequently occupy extremely powerful positions.
SGX was designed around a different assumption for enclave memory. Software did not automatically gain permission to read enclave contents merely because it occupied a conventionally privileged position outside the enclave.
The purpose of SGX isolation was to protect selected enclave code and data from disclosure or modification by software outside that enclave, including software that would normally have broad control over the machine.
This was a major conceptual shift. Instead of treating the operating system as the final security boundary for every application secret, the processor could enforce another boundary beneath ordinary software privilege.
The Protected Memory Needed Special Handling
SGX reserved protected physical memory resources for enclave pages. Access checks associated with those pages helped prevent ordinary software from treating enclave memory as though it were just another readable region of the application’s address space.
The processor also had to account for situations in which enclave pages could not remain resident in protected physical memory indefinitely. SGX included mechanisms for securely managing enclave pages as system memory demands changed.
An enclave still existed within a larger computer. It depended on ordinary software for many services and had to exchange information with the untrusted portion of the application carefully.
Small Trusted Code Was Easier to Separate
Moving an entire complex application into an enclave would work against one of the useful ideas behind the technology. Every additional function placed inside the trusted area increased the amount of code whose behavior had to be understood and secured.
A more focused design could leave ordinary work outside and reserve enclave execution for operations involving particularly sensitive information.
Operations involving protected information could be separated from the application’s general processing.
Information that should not be freely exposed to the rest of the process could be handled within the protected component.
Security-sensitive decisions could be placed behind a boundary different from the application’s ordinary execution environment.
The principle was similar to reducing the size of a trusted computing base. The less code entrusted with sensitive material, the fewer places developers had to consider when examining that protected portion for mistakes.
Outside Code Still Had to Communicate With the Enclave
Isolation creates a practical problem. If protected code could never exchange information with the rest of the application, it would have limited usefulness.
SGX applications therefore needed defined ways to cross the enclave boundary. Calls could enter enclave functions, and enclave code could request work from the untrusted side when it needed services that were not performed internally.
Controlled boundary
Outside the enclave the application could interact normally with operating-system services and the surrounding environment.
Across the boundary parameters and returned information had to be handled deliberately because protected and unprotected code did not share the same trust assumptions.
Inside the enclave the sensitive operation could execute using the code and data intended for the protected environment.
An enclave could protect memory boundaries, but application mistakes still mattered. Incorrect validation, insecure interfaces, programming errors, or deliberate leakage from trusted code could undermine what the enclave was intended to protect.
A Remote System Could Ask What Was Running
Protecting an enclave locally solved only part of a larger problem. A remote service might also need confidence that it was communicating with an expected enclave on a genuine SGX-capable platform rather than sending sensitive information to an imitation.
Attestation provided a way to establish information about the enclave’s identity and execution environment. This could allow another party to evaluate evidence about the protected component before deciding whether to trust it with secrets or sensitive work.
The protected component is created with an identity derived from the code and configuration involved in its construction.
The SGX attestation process can provide information associated with the enclave and platform.
A verifier can use the supplied evidence as part of deciding whether it recognizes and trusts the protected environment.
Once the required trust decision is made, the remote party can decide whether to continue an operation involving protected information.
This extended the idea beyond merely hiding memory from local software. An enclave could participate in establishing trust with another system that could not physically inspect the computer on which the protected code was running.
SGX Did Not Replace the Operating System
The presence of a processor-enforced enclave could easily create the impression that everything outside it had become irrelevant. That was never a safe assumption.
The operating system still scheduled work, managed hardware, provided files and networking, handled devices, and performed countless services required by applications. SGX changed the trust model for selected application code and data rather than replacing the surrounding computer architecture.
SGX was designed to protect chosen portions of an application. It was not a second general-purpose operating system hidden inside the processor.
The surrounding environment could also influence an enclave in ways other than directly reading its protected memory. Security analysis therefore had to consider the complete application design rather than treating the enclave boundary as a solution to every possible attack.
Protecting Data While It Was Being Used Became Practical
Encryption at rest protects information when it is stored. Encryption in transit protects information while it crosses an untrusted network. Neither description completely addresses the moment when a program must actually process the information.
Intel SGX approached that third condition by giving developers a processor-supported place for selected code and data to operate under a stronger isolation boundary.
That did not eliminate the need for secure operating systems, careful programming, encryption, access control, or conventional application security. Instead, it added another place where trust could be deliberately limited.
The important change was architectural. Sensitive application code no longer had to assume that every more-privileged piece of software surrounding it should automatically be able to see everything it was doing.
