Fre­quent­ly Asked Questions

Intel® Soft­ware Guard Exten­sions (SGX) is a set of CPU machine lan­guage instruc­tions that secure data and code exe­cu­tion in memory.

The appli­ca­tion code and data inside the SGX enclave is iso­lat­ed from all oth­er appli­ca­tions run­ning on the same sys­tem, the host oper­at­ing sys­tem, as well as the hyper­vi­sor itself.

AMD Secure Encryp­tion Vir­tu­al­iza­tion (SEV) is a secure enclave tech­nol­o­gy that enables encrypt­ing the mem­o­ry of an entire vir­tu­al machine at runtime.

It is suit­able for secur­ing lega­cy, large and enter­prise-lev­el applications.

SGX treats the sys­tem soft­ware as untrust­ed and poten­tial­ly mali­cious. For this rea­son the mea­sure­ment of enclaves is used. It allows the appli­ca­tion cre­at­ing the enclave to ensure the set­up was done cor­rect. This includes the com­mands used as well as the data and code set­up in the enclave. This pre­vents the sys­tem soft­ware or priv­i­leged attack­ers from manip­u­lat­ing the enclaves code and data dur­ing the set­up, for exam­ple by load­ing oth­er pages then request­ed by the appli­ca­tion or manip­u­lat­ing the pages before they are loaded into the enclave.

SGX decides inside the CPU, who is trust­ed to work inside an enclave. This way a pow­er­ful, hard­ware-based secu­ri­ty gate is imple­ment­ed, and no vul­ner­a­ble soft­ware is used for this deci­sion-mak­ing process.
The CPU man­ages inside its Mem­o­ry Man­age­ment Unit (MMU), whether an access to a spe­cif­ic area of its PRM is allowed or not. Inside each enclave one or more Thread Con­trol Struc­tures (TCS) con­tain fixed entry points for enclave enter­ing, mak­ing it impos­si­ble to enter through ille­gal gate­ways. A safe pro­gram­ming style inside the enclave will make it impos­si­ble for attack­ers to enter the enclave or to inves­ti­gate pos­si­ble in- and out­puts of the enclave by sim­ple test­ing.
Fur­ther the EPCM con­tains the autho­rized vir­tu­al address and the enclave own­er, which is nec­es­sary for enter­ing a spe­cif­ic enclave. If an access from a non-trust­ed vir­tu­al address occurs, it will be redi­rect­ed to non-exis­tent mem­o­ry or a sig­nal fault will be throwed. This EPCM is locat­ed inside the CPU, and only the CPU is capa­ble to access it in real­time
Last but not least — every page inside the enclave has dif­fer­ent per­mis­sion like read-only. This builds an extra bar­ri­er for attack­ers, to harm enclaves.

Each enclave con­tains the SECS, where its spe­cif­ic hash for integri­ty checks is stored. This hash is stored in the enclave, which is stored inside the EPC, which gets real time decrypt­ed through the MEE inside the CPU in enclave mode. The SGX unit con­tains an fixed secret key, gen­er­at­ed at the man­u­fac­tur­ing process of the chip, which should be even unknown to Intel (you have to trust Intel at that point) for decrypt­ing inside the MEE. The decryp­tion is only pos­si­ble with this secret key, which is inac­ces­si­ble from out­side the SGX unit.

Data inside the enclave is stored safe, unless an unpriv­i­leged par­ty gets inside it. Since enclaves get cre­at­ed at the begin­ning of an app start from the untrust­ed part of the app, a gate­way for attack­ers could lay here.

Fur­ther the SGX on a spe­cif­ic sys­tem is only safe, if the secret hard­ware-based key inside the Mem­o­ry Encryp­tion Engine is unknown to every­body else as the SGX mod­ule itself.

The Proces­sor Reserved Mem­o­ry gets ini­ti­at­ed at the very begin­ning of start­ing the sys­tem from the BIOS. SGX is only stat­ed safe, if the PRM is inac­ces­si­ble for oth­er parts of the sys­tem besides the CPU. Hard­ware attacks trough phys­i­cal ways would be need­ed for this example.

A mali­cious enclave can attack soft­ware through cache attacks to steal secret infor­ma­tion of enclaves. A proof of con­cept is pub­lished in the paper Mal­ware Guard Exten­sion: Using SGX to Con­ceal Cache Attacks.

Spec­u­la­tive Exe­cu­tions are a plus for the per­for­mance but allows to read decrypt­ed enclave data when inside the CPU e.g. in the cache ille­gal­ly by oth­er software.

Fur­ther the giv­en Intel secu­ri­ty guide­lines must be fol­lowed to pre­vent leak­ages caused by bad code.