Design Considerations For Intel® SGX Applications

This post discusses several possible ways in which an Intel® SGX application could be designed.  First, the most obvious and simplest of options - choosing a design that is most conducive for the targeted environment.  This can be done by studying the technology itself, its design, what it is targeted towards and built for.  At that level, with CPU boundary as its security perimeter, Intel® SGX is designed to provide the smallest possible attack surface, along with hardware level access checks.  Thus applications that have isolated a small subset of code as sensitive enough to warrant a secure execution environment are best suited for this option.  This way, existing functionalities can remain nearly intact while porting just a small portion of sensitive code to work within a secure enclave.  The downside of this approach is its restricted scope, which won't open up the technology for wider use.

Second design option would allow for a scenario where considerable parts of an application, or a module, or several modules enlisted by the application calls for secure execution, while the rest of the application could run outside that secure context.  Such a design would require a good understanding of the application and an intimate knowledge of all its dependencies and path of execution, to decide what to port for secure execution and what not to.  Also, interfaces need to be designed for secure enclave code to communicate with the outside, and vise versa, and precautions taken to avoid introducing vulnerabilities in the process.

Third of the design options and the most straight forward, would be to port an existing application or library, in its entirety, to run within a secure enclave environment.  While relatively trivial to implement, it is neither ideal for significant scenarios nor comparatively more secure.  But, this is the kind one is likely to widely encounter, especially among freely ported and published software.

What is more interesting is the fourth design option, where a contained version of the OS subsystem itself is ported, along with the targeted application, to run within a secure enclave.  This minimizes the dependency on the classic subsystem, and adds to the overall application security in one way while reducing the same in another way due to the increased attack surface, at software level.  This is what projects like Haven and Graphene SGX attempts, via its own flavor of library OS.  While it is really interesting to experiment with this design model, I am not sure of its viability unless such a design is implemented by and within the underlying platform itself.

Lastly, the most interesting of design options is just in time trusted execution.  This would require no source level change at all to the targeted applications but will introduce a complex just in time execution engine, built to switch to secure execution environment on the fly.  And the decision as to what is run within the secure environment is as well decided on the fly and during execution time, perhaps by studying the context and activities during any point in time, but possibly more than that.  This, while non trivial to implement, is what is likely to make Intel® SGX ubiquitous.  Otherwise, the prospect of the technology is likely to rely on niche sectors currently leveraging it, along with technologies like blockchain dabbling with it lately, especially for its consensus model, but possibly more.