TL;TR

Soft­ware Guard Exten­sion (SGX) adds pow­er­ful secu­ri­ty capa­bil­i­ties to x86-archi­tec­ture based Intel CPUs enabling the cre­ation of enclaves. Enclaves are user space areas inside the mem­o­ry address space specif­i­cal­ly pro­tect­ed by the CPU that pre­vent access even from high­er priv­i­leged, ker­nel space process­es. To imple­ment the iso­la­tion from oth­er process­es and the oper­at­ing sys­tem, SGX empow­ers the encryp­tion and integri­ty pro­tec­tion of enclaved pro­grams. This gives raise to a new, pow­er­ful pro­gram­ming mod­el for appli­ca­tion developers.

Pri­vate infor­ma­tion such as user­names, pass­words, cred­it records should grant access to autho­rized users. Gen­er­al­ly, the oper­at­ing sys­tem (OS) is able to enforce secu­ri­ty poli­cies to avoid unin­ten­tion­al leak­age of those secrets. Near­ly all pro­tec­tion mech­a­nisms added by OS could not defend a mali­cious appli­ca­tion with admin­is­tra­tion priv­i­leges. Such appli­ca­tions have unre­strict­ed access to all sys­tem resources and all run­ning appli­ca­tions and extract secret data direct­ly from the mem­o­ry. To defend such mali­cious appli­ca­tions and give users a high­er lev­el of pro­tec­tion of their secret data, Intel designed SGX.

To con­clude, Intel SGX offers an extra set of CPU instruc­tions to cre­ate Enclaves, areas that are pro­tect­ed by hard­ware and ensure con­fi­den­tial­i­ty and integri­ty even in front of priv­i­leged oper­at­ing systems.

Intel SGX — A Primer

Intel SGX was intro­duced by Intel in the year of 2015 with its Sky­lake CPU familiy. SGX is a new instruc­tion set to pro­vide a reserve sand­box that pro­tects Enclaves from

• OS or hyper­vi­sor (in case of vir­tu­al machine host systems)
• BIOS, firmware, drivers
• Sys­tem man­age­ment mod­ule (ring‑2)
• Intel man­age­ment engine (ME)
• Any remote attack

Over­all, SGX is an hard­ware enforced secu­ri­ty mech­a­nism that requires a Trust­ed Com­put­er Base (TCB), Hard­ware secrets, Remote Attes­ta­tion, Sealed Stor­age and Mem­o­ry Encryption.

The TCB is the CPU’s pack­age bound­ary and SGX relat­ed soft­ware com­po­nents. The hard­ware secrets are two 128-bit keys burned into the CPU while pro­duc­tion, while Intel has knowl­edge of the Root Pro­vi­sion­ing Key (RPK) and in con­trast, the Root Seal Key (RSK) is not known by Intel. That’s the rea­son why most derived keys are based on RSK. Remote Attes­ta­tion is applied for the client to prove to the ser­vice provider that an Enclave is run­ning a giv­en soft­ware, inside a giv­en CPU, with a giv­en secu­ri­ty lev­el, for a giv­en Indi­vid­ual Soft­ware Vender (ISV). This is nec­es­sary before the ser­vice provider decides to pro­vide request­ed secrets. With the help of sealed stor­age SGX is able to save secret data to untrust­ed media. Data and code inside Enclaves are not secrets. They are just log­ics that are required to process the secret and most of them are open sourced or can be reverse engi­neered. There­fore, secrets are pro­vi­sioned lat­er by the ser­vice provider and should be stored out of the Enclave through seal­ing mech­a­nism when nec­es­sary (e.g. for future usage).

Final­ly, Intel SGX imple­ments the fol­low­ing pro­tec­tions from known hard­ware and soft­ware attacks:

• The mem­o­ry of the Enclave can­not be read or writ­ten from out­side the Enclave regard­less of the cur­rent priv­i­lege lev­el and CPU mode.
• It’s not pos­si­ble to debug the Pro­duc­tion Enclaves by soft­ware or hard­ware debuggers.
• To call an Enclave func­tion the only way is through a new instruc­tion that per­forms sev­er­al pro­tec­tion checks. The Enclave envi­ron­ment itself can­not be entered through clas­sic func­tion calls, jumps, reg­is­ter manip­u­la­tion, or stack manipulation.
• SGX enables indus­try-stan­dard encryp­tion algo­rithms with replay pro­tec­tion for Enclave mem­o­ry. Direct attacks on hard­ware lev­el of the mem­o­ry to con­nect anoth­er sys­tem will yield to encrypt­ed data.
• The mem­o­ry encryp­tion key is stored with­in the CPU and is not acces­si­ble and changes every pow­er cycle.
• Iso­lat­ed data with­in Enclaves are only acces­si­ble by code that shares the Enclave.

All those advan­tages lead to a reduced attack sur­face using Intel SGX shown in Fig­ure 1.

Enclaves from mem­o­ry perspective

This sec­tion gives you a short intro­duc­tion of Enclave estab­lish­ment from mem­o­ry scope. It cov­ers the main archi­tec­tur­al con­cepts for Enclave oper­a­tion to give you a gen­er­al com­pre­hen­sion for appli­ca­tion design in the next sec­tion. Fig­ure 2 illus­trates a typ­i­cal Enclave mem­o­ry layout.

1. The first step to cre­ate an Enclave to load code and data from user space into the Enclave Page Cache (EPC) and estab­lish the Enclave enti­ty. ECREATE is the ini­tial com­mand to set up the ini­tial envi­ron­ment, but I’ll dis­cuss the pro­gram­ming func­tions in the next sec­tion. The appli­ca­tion hands over the Enclave con­tent along with addi­tion­al infor­ma­tion required by the Enclave cre­ation API to the Enclave cre­ation ser­vice run­ning at ring‑0. The com­mit­ment of mem­o­ry resources is passed by ECREATE to set up the ini­tial envi­ron­ment, spec­i­fy­ing base address and size of the Enclave. While the address range (ELRANGE) is part of the application’s address space, this reserves the mem­o­ry range. So the Enclave will reside in this address region, while ECREATE allo­cates an EPC for the SGX Enclave Con­trol Struc­ture (SECS).
2. Con­se­quent­ly, the Enclave is able to add pages (EADD) and mea­sure the com­mit­ted mem­o­ry con­tent of the Enclave (EEXTEND). Mea­sure­ment means, an Enclave is instan­ti­at­ed in a trust­ed envi­ron­ment and an accu­rate and pro­tect­ed record­ing of its iden­ti­ty is taken.
3. After­wards, the ini­tial­iza­tion of the Enclave final­izes the cryp­to­graph­ic log and estab­lish­es the Enclave iden­ti­ty and seal­ing iden­ti­ty (EINIT). A cryp­to­graph­ic hash of the log is stored. The Enclave is ini­tial­ized by the EINIT instruc­tion. The EINIT instruc­tion checks the EINIT token to val­i­date that the Enclave has been enabled on this plat­form. If the Enclave is not cor­rect­ly con­struct­ed or the EINIT token is not valid for the plat­form then EINIT will fail. Until an EINIT is exe­cut­ed, the enclave is not per­mit­ted to exe­cute any Enclave code (i.e. enter­ing the Enclave by exe­cut­ing EENTER).
4. Final­ly, the Enclave is able to entry and exit­ing using two dif­fer­ent oper­a­tions:
   - Syn­chro­nous entry and exit
   - Asyn­chro­nous Enclave Exit (AEX) and resum­ing exe­cu­tion after an AEX The EENTER instruc­tion is the method to enter the Enclave under pro­gram control.

Enclaves from an appli­ca­tion perspective

To cre­ate an appli­ca­tion with SGX enabled Enclaves it is first nec­es­sary to inter­nal­ize the three words Enclave, attes­ta­tion and seal­ing and it’s usage.

Enclave:

An appli­ca­tion with Intel SGX is sep­a­rat­ed in two components:

• Trust­ed com­po­nent, describes the Enclave itself. The code that resides in the trust­ed code is the code that access­es an application’s secrets. An appli­ca­tion can have more than one trust­ed component/enclave.
• Untrust­ed com­po­nent describes the “user appli­ca­tion”. It is impor­tant to note that, from the stand­point of an Enclave, the OS is already an untrust­ed component.

It is a good prac­tice to min­i­mize the size of the untrust­ed com­po­nent as well as reduc­tion of the inter­con­nect com­mu­ni­ca­tion between trust­ed and unstrust­ed com­po­nents to reduce attack sur­face for mali­cious applications.

Attes­ta­tion:

Attes­ta­tion describes the mech­a­nism to demon­strate to oth­er enti­ties that a par­tic­u­lar envi­ron­ment was instan­ti­at­ed in the cor­rect manner.

Seal­ing:

Seal­ing enables data belong­ing to the trust­ed envi­ron­ment to be bound to it such that it can be restored only when the trust­ed envi­ron­ment is restored. The encryp­tion keys are derived inter­nal­ly on demand and are not exposed to the enclave.

To ini­tial­ize an enclave, four of the new CPU instruc­tions (ECREATE, EADD, EEXTEND, EINIT) pro­vid­ed by SGX archi­tec­ture are used.

ECREATE:

Ini­tial­ly, the ECREATE instruc­tion, which turns a free EPC page into the SECS for the new enclave, is the begin­ning of a new Enclave. The instruc­tion copies an SECS struc­ture out­side the EPC into an SECS page inside the EPC. The inter­nal struc­ture of SECS is not acces­si­ble to soft­ware. The Soft­ware sets the Base address, size and fur­ther attrib­ut­es in the source struc­ture. At the same time, ECREATE val­i­dates the infor­ma­tion used to ini­tial­ize the SECS.

EADD:

The instruc­tion EADD loads the ini­tial code and data into the enclave. EADD is used to cre­ate both TCS pages and reg­u­lar pages. This func­tion copies a source page from non-enclave mem­o­ry into the EPC, asso­ciates the EPC page with an SECS page inside in the EPC, and stores the lin­ear address and secu­ri­ty attrib­ut­es in EPC Map (EPCM). EADD reads its input data from a Page Infor­ma­tion struc­ture, which con­tains the vir­tu­al address of the EPC page and fur­ther attrib­ut­es. EADD ensures that the EPC page is not allo­cat­ed to anoth­er Enclave, the page’s vir­tu­al address falls with­in the enclave’s ELRANGE and all the reserved fields are set to zero.

EEXTEND:

Dur­ing load­ing an enclave, the sys­tem soft­ware will also use the EEXTEND instruc­tion, which updates the enclave’s mea­sure­ment used in the soft­ware attes­ta­tion process. It updates the MRENCLAVE mea­sure­ment reg­is­ter of an SECS with the mea­sure­ment of an EXTEND string.

EINIT:

This instruc­tion is the final punch for the exe­cu­tion of the Enclave build process. After EINIT, the MRENCLAVE mea­sure­ment is fin­ished and the Enclave is ready to start user exe­cu­tion using EENTER instruc­tion. The INIT attribute is set to true, if ini­tial­iza­tion is suc­cess­ful. On the oth­er hand, once EINIT is set to true, EADD can­not be invoked on that enclave any­more, so the sys­tem soft­ware must load all the pages that make up the enclave’s ini­tial state before exe­cut­ing the EINIT instruction.

Since the Intel SGX SDK pro­vides a wrap­per for soft­ware develeop­ment it is com­mon prac­tice to define ECALL and OCALL func­tions in the Enclave def­i­n­i­tion lan­guage (EDL) as following:

ECALL:

“Enclave Call”, a call made into an inter­face func­tion with­in the Enclave

OCALL:

“Out Call”, a call made from with­in the Enclave to the out­side application

In a nut­shell, ECALLs are pro­to­typed in the trust­ed sec­tion, and OCALLs are pro­to­typed in the untrust­ed section.

Proxy func­tion­al­i­ty:

The proxy func­tion­al­i­ty of the Edger8r tool, which is includ­ed in the Intel SGX SDK and exe­cut­ed while build­ing the project, pars­es the EDL file and gen­er­ates a series of proxy func­tions. These proxy func­tions are essen­tial­ly wrap­pers around the real func­tions that are pro­to­typed in the EDL. Each ECALL and OCALL gets a pair of proxy func­tions: a trust­ed half and an untrust­ed half. The trust­ed func­tions go into a trust­ed head­er and trust­ed code-file and are includ­ed in the auto-gen­er­at­ed Files fold­er of your enclave project. The untrust­ed prox­ies go into an untrust­ed head­er and untrust­ed code-file and are placed in the auto-gen­er­at­ed Files fold­er of the project that will be inter­fac­ing with your enclave. Fig­ure 3 illus­trates the proxy mechanisms.

That means, your appli­ca­tion does not call the ECALL and OCALL func­tions direct­ly, instead the proxy func­tions are exe­cut­ed. When you make an ECALL, you call the untrust­ed proxy func­tion for the ECALL, which in turn calls the trust­ed proxy func­tion inside the enclave. That proxy then calls the “real” ECALL and the return val­ue prop­a­gates back to the untrust­ed func­tion. This sequence is shown in the fig­ure above. When you make an OCALL, the sequence is reversed: you call the trust­ed proxy func­tion for the OCALL, which calls an untrust­ed proxy func­tion out­side the enclave that, in turn, invokes the “real” OCALL.

Over­all, the proxy func­tions are respon­si­ble for:

• Orga­nize data into and out of the enclave.
• Plac­ing the return val­ue of the real ECALL or OCALL in an address ref­er­enced by a point­er parameter.
• Return­ing the suc­cess or fail­ure of the ECALL or OCALL itself as a sta­tus value.

Ref­er­ences

[1] Intel® Soft­ware Guard Exten­sions Pro­gram­ming Ref­er­ence: https://software.intel.com/sites/default/files/managed/48/88/329298–002.pdf

[2] Intel® Soft­ware Guard Exten­sions Enclave Writer’s Guide: https://software.intel.com/sites/default/files/managed/ae/48/Software-Guard-Extensions-Enclave-Writers-Guide.pdf

[3] Intel® Soft­ware Guard Exten­sions (Intel® SGX) Devel­op­er Guide: https://software.intel.com/content/www/us/en/develop/download/intel-software-guard-extensions-intel-sgx-developer-guide.html

[4] SGX 101: https://sgx101.gitbook.io/sgx101/sgx-bootstrap/enclave

[5] Vic­tor Costan and Srini­vas Devadas, Intel SGX Explained. Ref­er­ence: https://eprint.iacr.org/2016/086