We want to provide the SERECA view on security risks related to the usage of Intel SGX. Particularly, in the following, we discuss short-term, medium-term and long-term risks.
We expect that in the short term more vulnerabilities of Intel CPUs will be discovered and published. These vulnerabilities will most likely include more side-channels that can be used both in native mode as well as for SGX. These vulnerabilities will most likely trigger CPU microcode updates by Intel. A major risk of these microcode updates are that the performance of Intel SGX enclaves will degrade such that they introduce an even larger overhead over native processing. On the other hand, the microcode updates will also introduce overheads in native mode and hence, it is not clear how the overheads of SGX over native mode will change.
Another short-term risk is that microcode updates alone will not be sufficient. We might have to adjust our systems software to adjust for the new vulnerabilities. This might introduce not only some additional overheads but also might reduce the generality of what software can run inside of enclaves.
As medium term risk we consider the option that other vendors will not provide solution that match the protection level of SGX. E.g. by now it becomes more and more clear that AMD’s SEV will enable better protection by providing a lightweight and fast encryption of virtual machines but offers no resilience against attacks of privileged system software. Also ARM seems to work on novel security extensions but there is no announced roadmap when this technology will arrive on the market or if it will be competitive to SGX. As a consequence we envision two scenarios. Major industry player will be reluctant to adopt SGX in a wider scope because it would lead to a classical vendor-lock-in situation. The other scenario is that adaption layers will be designed that enable a uniform interface to different technologies. While this would enable to utilize the protection as offered by the underlying hardware platform – in the end the common denominator might be the least protective platform. The second scenario has partly become reality with Google’s recently published open source project Asylo (https://asylo.dev), which exactly aims at offering a generic framework for enclavised execution.
In the long term, the recently discovered security vulnerabilities related to side channels and speculative execution have had a profound impact on the computer architecture community. Future generations of Intel and ARM CPUs are therefore likely to focus on novel security features, as opposed to merely performance improvements. Especially with the end of Moores Law and Dennard Scaling, it is likely that we will witness more fundamental micro-architectural changes in future CPUs. CPU manufacturer such as Intel, ARM and AMD will face increased market pressure to demonstrate that similar types of vulnerabilities are impossible in the future.
For trusted execution, this is both a challenge and an opportunity. While we believe that trusted execution will remain a core concept for protecting the confidentiality and integrity of data and computation on CPUs, a more fundamental rethinking of the CPU security architecture may result in a trusted execution model that is more pervasive. If the fundamental abstraction of trusted execution changes, this would have major implications on the software stack, and thus affect the applicability of previous results, as the ones developed in the SERECA project. At the same time, the outputs from the SERECA project are timely to inform the discussion about the future of a trusted execution model. Here the SERECA project engages with major stakeholders, including Intel, Microsoft, Google and Huawei, to help shape their thinking on how future versions of trusted execution should be designed.