Today the Intel® Software Guard Extensions (Intel® SGX) programming reference manual was published (more information is available here). Given the significant time and effort that my colleagues and I have spent defining Intel® SGX, I can't find a strong enough word in my thesaurus to describe how thrilled/elated/ecstatic I am to finally be able to write about it publicly.
At its root, Intel® SGX is a set of new CPU instructions that can be used by applications to set aside private regions of code and data. But looking at the technology upward from the instructions is analogous to trying to describe an animal by examining its DNA chain. In this short post I will try to uplevel things a bit by outlining the objectives that guided the design of Intel® SGX and provide some more detail on two of the objectives. In future posts, I will dive deeper into the remaining objectives and review some of our experiences using Intel® SGX to protect various software applications.
Much of the motivation for Intel® SGX can be summarized in the following eight objectives:
Allow application developers to protect sensitive data from unauthorized access or modification by rogue software running at higher privilege levels.
Enable applications to preserve the confidentiality and integrity of sensitive code and data without disrupting the ability of legitimate system software to schedule and manage the use of platform resources.
Enable consumers of computing devices to retain control of their platforms and the freedom to install and uninstall applications and services as they choose.
Enable the platform to measure an application’s trusted code and produce a signed attestation, rooted in the processor, that includes this measurement and other certification that the code has been correctly initialized in a trustable environment.
Enable the development of trusted applications using familiar tools and processes.
Allow the performance of trusted applications to scale with the capabilities of the underlying application processor.
Enable software vendors to deliver trusted applications and updates at their cadence, using the distribution channels of their choice.
Enable applications to define secure regions of code and data that maintain confidentiality even when an attacker has physical control of the platform and can conduct direct attacks on memory.
Here is a little more detail behind the first two objectives
Objective 1 – Allow application developers to protect sensitive data from unauthorized access or modification by rogue software running at higher privilege levels.
Several aspects of Objective 1 are worth amplifying. First, protecting sensitive data demands both confidentiality (preventing data disclosure) and integrity (preventing data tampering). Second, it implies a need to protect sensitive code as well as data (consider, for example, that an attacker can easily obtain unauthorized access to data by modifying or skipping authorization checks). Third, data must be protected not only when it is stored in encrypted form, but also at run-time when the data is unencrypted and being actively used for computation. Finally, it is critical to maintain run-time protection despite attacks from rogue software that has subverted legitimate system software to gain amplified privilege levels.
Objective 2 – Enable applications to preserve the confidentiality and integrity of sensitive code and data without disrupting the ability of legitimate system software to schedule and manage the use of platform resources.
While sensitive data must be protected from attack by rogue software running at high privilege levels, legitimate system software must be allowed to do its job. It is unacceptable to require protected applications to take over or significantly disrupt the basic operating system features (job scheduling, device management, etc.). Operating systems have evolved over many generations to perform these roles well, and requiring a duplicate, parallel environment would be impractical.
I will follow up shortly with more details on the remaining objectives.
Read more >
The post Intel® SGX for Dummies (Intel® SGX Design Objectives) appeared first on Blogs@Intel.