Intel(R) SGX Application
The first step in designing an Intel SGX enabled application is to identify the assets it needs to protect, the data structures where the assets are contained, and the set of code that operates on those data structures and then place them into a separate trusted library. Since the ISV knows the application best, the ISV should conduct a security analysis of the application and properly partition it making the decision about what code and data is placed in the enclave.
The code in an enclave is no different than code that exists as part of a regular application. However, enclave code is loaded in a special way such that once the enclave has been initialized, privileged code and the rest of the untrusted application cannot directly read data that resides in the protected environment, or change the behavior of the code within the enclave without detection. For this reason, even though identifying the secret processing components and the resources they use is an important step in any secure software development process, for using Intel SGX it is an essential activity.
Partitioning an application into trusted and untrusted components has additional implications from a security standpoint. It is generally accepted that a smaller memory footprint (smaller code and data) usually implies a lower chance of having defects in the final software product. It also implies simpler security analysis and safer software as a smaller attack surface can be exposed. Therefore, while it may be possible to move the majority of application code into an enclave, in most cases this would not be desirable. The TCB size should be a factor to consider when designing what goes inside an enclave. ISVs should attempt to minimize the enclave size, even though the Intel SGX architecture protects the enclave contents when the OS, VMM, or BIOS are compromised. The first generation of the Intel(R) SGX architecture requires that all the functionality inside an enclave is statically linked in at build-time. This creates a performance/size trade-off which developers must carefully analyze as it impacts the TCB size. When using static library functionality, ISVs have two choices. They could provide a shim layer to call the functionality outside the enclave, or alternatively include the implementation of the library as part of the enclave. The first approach adds performance overhead compared to normal library function calls. The second method causes an increase of the TCB size.
Partitioning also plays a key role in preparing an Intel SGX application to manage power events, see Section Power Management for additional details. The smaller the state information stored inside the enclave, the quicker the enclave will be able to backup this information outside the enclave and to recover from a power event.