• Benefits from new Intel SGX instructions introduced with 6th generation Intel® Core™ processor (or later) platforms
• Relies on an Intel® driver or the operating system for access to Intel SGX instructions and resource management
• Runs within the context of its parent application, thereby benefiting from the full power of the Intel® processor
• Reduces the trusted computing base of its parent application to the smallest possible footprint
• Remains protected even when the BIOS, virtual machine monitor (VMM), operating system, and driver are compromised, implying that an attacker with full execution control over the platform can be kept at bay

• Benefits from memory protections that thwart memory bus snooping, memory tampering, and “cold boot” attacks on images retained in RAM
• Uses hardware-based mechanisms to respond to remote attestation challenges that validate its integrity
• Can work in concert with other enclaves owned or trusted by the parent application
• Can be developed using standard development tools, thereby reducing the learning curve impact on application developers

• The enclave memory cannot be read or written from outside the enclave regardless of current privilege level and CPU mode (ring3 [user-mode], ring0 [kernel-mode], system management mode [SMM], VMM, or another enclave). The abort page is returned in such conditions.
• An enclave can be created with a debug attribute that allows a special debugger (Intel SGX debugger) to view its content like a standard debugger. Production enclaves (non-debug) cannot be debugged by software or hardware debuggers.
• The enclave environment cannot be entered via classic function calls, jumps, register manipulation, or stack manipulation. The only way to call an enclave function is via a new instruction that performs several protective checks. Classic function calls initiated by enclave code to functions inside the enclave are allowed.
• CPU mode can only be 32- or 64-bit when executing enclave code. Other CPU modes are not supported. An exception is raised in such conditions.

• The enclave memory is encrypted using industry-standard encryption algorithms.
• Tapping the memory or connecting the DRAM modules to another system only gives access to encrypted data.
• The memory encryption key randomly changes every power cycle (for example, boot, sleep, or hibernate). The key is stored within the CPU and is not accessible.
• Intel SGX is not designed to handle side channel attacks or reverse engineering. It is up to the Intel SGX developers to build enclaves that are protected against these types of attacks.

Design for an Intel SGX application is different than a third-party application because it requires dividing the application into two logical components:

• Trusted component. The code that accesses the secret resides here, and is called an enclave. More than one enclave can exist in an application.
• Untrusted component. This is the rest of the application, including all of its modules.¹

The application developer should make the trusted component as small as possible with a minimal enclave interface definition. It is suggested that enclave functionality be limited to operating on the secret data. A large enclave with complex interface definition presents a larger attack surface than a small enclave with a small and concise interface.

The enclave code can leave the protected memory region and call functions in the untrusted zone (by a special instruction). Reducing the enclave dependency on untrusted code also strengthens its protection against possible attacks.

Embracing the above design considerations improves protection as the attack surface is minimized.

As the first step to harnessing the Intel® Software Guard Extensions SDK in the application, developers must rearchitect or refactor the application to fit these guidelines. This is accomplished by isolating the code modules that access any secrets, and then moving these modules to a separate package or library. Sample code included in the Intel SGX SDK demonstrates how to create an enclave.