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.
How many is one too many when it comes to migrating cryptography libraries to run within a hardware backed secure environment?
Following is a long pending post on the topic of running cryptography libraries within a secure environment.
There are quite a number of innovative ways to use Intel® SGX technology. The low hanging fruits usually gets the traction right away, not only because they are easier to attain but also because it satisfies an immediate need. At that level, porting classic libraries to work within a secure environment has received fair amount of attention. I myself discussed the topic of migrating SQLite to Intel® SGX environment, along with a proof of concept. A "SGX" keyword search alone, and within GitHub, returns several hundred results. Areas like cryptography and database technologies get far more attention than the rest when it comes to migrating to a secure environment. Former more so than the latter, within that. And that is understandable, mainly because, the point in enlisting cryptography is somewhat, if not fully lost if security cannot be guaranteed in the process. Thus cryptography makes for an ideal candidate for technologies like Intel® SGX to embrace, or more importantly, the other way around.
Then again, one might ask, how many is one too many when it comes to porting cryptography libraries or to be more specific, services that heavily enlist cryptography, to run within a secure environment like an Intel® SGX enclave? Intel® itself has ported OpenSSL to work within an enclave environment. Then there is WolfSSL, TaLos project, LibTomCrypt (source here), mbedTLS and more. So, when I ventured into porting Cryptlib (commercial version here), a security toolkit that provides varied services in its area, to work within an Intel® SGX enclave, I had to ask - is it really necessary? That is, to add support for yet another library, albeit with its own differentiating point, in comparison to the rest of its kind. I won't distract the conversation by getting into why Cryptlib is different and who or why someone might chose that over the rest. I would suggest looking into their website.
That said, the question as to whether or not it is worth porting Cryptlib, yet another cryptography library or to be more specific in this case, a security toolkit with considerable amount of cryptography functionality, need addressing. I believe the answer is, yes. Any library with an active customer base is worth a consideration. Because, to the customers of those libraries, it really comes down to whether security is important enough to switch to a tool that provides a more secure way to execute the much needed functionality or keep the same library for its differentiating benefits, over which it was chosen in the first place, but at the cost of better security. By forcing the active customer base to have to chose between the two is constraining them one way or other and there is no need for it, as porting existing libraries to work within a secure enclave is not that hard! Cryptlib perhaps being comparatively vast and more versatile in terms of the services it offers, might make porting a more involved task than most others. Nevertheless, I believe it is certainly worth the effort.
I have ported Cryptlib to a point where it makes for a functional prototype, which acts as a proof of concept that could be turned production ready, if there should be enough interest among its users in the field. If there are Cryptlib users and customers considering migrating to run the library within a secure enclave environment, powered by Intel® SGX technology, please feel free to reach out to firstname.lastname@example.org for further information.
Founder of KryptoGuard™ technology initiative, product and services.