Establishing a Generic End-To-End Trusted Execution Path for Intel® SGX Applications

   When it comes to security, you are only as secure as your weakest link.  Thus providing end to end security is imperative for any technology that claims to provide a secure execution environment.  This post is the first of possibly several that could follow, given the potential this topic holds.  It briefly summarizes the current state of end-to-end security, and Intel® SGX technology within that.  Taking one of several areas of application as an example,  it then explains how the same technology could help fill a void, if it were to stretch itself to strive towards end-to-end security.

   Providing comprehensive security and supporting trusted execution throughout the execution cycle requires all layers of software stack working in tandem to provide equal and uncompromising level of security, preferably by leveraging security aware hardware.  While there are hardware supported security technologies to enable security at each layer or at several layers of software stack, and perhaps with hierarchical protection, there doesn't exist a consolidated hardware enabled security technology that provides comprehensive end-to-end security for an otherwise general purpose system.  The disjoint nature of the current state of hardware enabled security can largely be attributed to the timeline in which each relevant technology was introduced and perhaps in some cases, without a more definitive vision of how the future technologies are going to play along with the existing ones.  Within that, Intel® SGX is especially different, as it was built to distrust the environment outside its scope!  While the reasoning for that built-in distrust is understandable, it does constraint the scope of usage of the technology considerably, because of such distrust by design.

   Use cases that require interfacing with human interface devices, like modules requiring password or other input from users or towards secure display, generally tend to fall outside the scope of that built-in trust.  Banking or e-commerce applications, are examples of where the above mentioned constraint is more obvious.  Yet, it is exactly in these sectors there is a pressing need for technologies like Intel® SGX to step up, because of introduction of more sophisticated technologies in their own vertical, like EMV technology in credit card industry, which has shifted the risk to e-commerce, as mentioned here!  In fact, as mentioned here, online card-not-present fraud is 81% more likely than point of sales fraud now, and just because of switch to EMV. 

   While Intel® SGX is currently constrained by way of its built-in distrust model and its scope of use, to be of help readily, it in fact can help offset the shift in risk.  For that, Intel® SGX will have to broaden it's scope and/or provide tighter integration with few other existing hardware level security technologies.  In specific, Intel is going to have to focus on adding more seamlessness, if not full blown integration, along with extending its own feature set, when technologies like Intel VT-d/VT-x/TPM/TXT are used alongside Intel® SGX, to provide more comprehensive end to end trusted execution path for scenario like the one mentioned above.  What is likely to make it harder, if not infeasible to accomplish, is the decentralized nature of handling of peripherals, starting from the manufacturer.  That is going to come in the way of single point of authority and autonomy that may be needed, to provide uncompromising level of security, architecturally and by design.

   While Intel works out that problem, what would be necessary is to come up with stop gap solutions that fill the void momentarily.  It looks like academia is tackling this problem and have come up with potential solutions.  SGXIO, by researchers at Graz University of Technology, is one such solution that combines multiple technologies to provide an end to end trusted execution path.  It enlists Intel's TPM/TXT, SGX and VT-d towards providing end to end trusted execution path.  Combining technologies that perhaps weren't necessarily designed to work harmoniously could make the implementation somewhat clumsy, if not less feasible for the field.  And it is mainly for this reason, it might be worth while for Intel to solve this problem at hardware level, end to end, with less if not near to no burden at software level.​