Sorry, you need to enable JavaScript to visit this website.


Intel designed Intel® Software Guard Extensions (Intel®SGX) to protect against both hardware and software attacks.

For software protection:

  • 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, 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® Software Guard Extensions 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 protect 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.


For hardware protection:

  • The enclave memory is encrypted using industry-standard encryption algorithms with replay protection.
  • Tapping the memory or connecting the DRAM modules to another system will only give access to encrypted data.
  • The memory encryption key randomly changes every power cycle (for example, boot/sleep/hibernate). The key is stored within the CPU and is not accessible.
  • Intel® Software Guard Extensions 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 attack.

Intel® Software Guard Extensions uses strong industry-standard algorithms for signing enclaves. The signature of an enclave characterizes the content and the layout of the enclave at build time. If the enclave’s content and layout are not correct per the signature, then the enclave fails to be initialized and will not be executed. If an enclave is initialized, it should be identical to the original enclave and will not be modified at runtime.


An Intel® Software Guard Extensions application design is different than a non-Intel® SGX application as it requires dividing the application into two logical components:

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

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 will also strengthen its protection against possible attacks.

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

Application developers, as the first step to harnessing Intel® Software Guard Extensions SDK in the application, 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/library. You can see the demonstrations on creating an enclave in the sample code that are shipped with the Intel® Software Guard Extensions SDK.


1 From an enclave standpoint, the operating system and VMM are not trusted components, either.