Figure 1 SGX enclave cannot interact with user devices
A1Logic’s Reverse Hypervisor Sandbox (RHS) might seem comparable to Intel’s SGX, since both are isolated execution environments separated by the CPU’s Memory Management Unit (MMU) that protect data “in use”. However, the choice of isolation technology has some major effects on applications that you can run in it.
Before jumping into the technical details of RHS and SGX, it is worth looking at recent history in the tech industry, as history repeats itself. Internet Protocol version 4 (IPv4) was an early networking technology that enjoyed widespread adoption on the internet, and became the “de facto” standard for internetworking. When the public IPv4 address space was exhausted, IPv6 came out with a solution: to replace older IPv4 format addresses with newer and longer IPv6 format addresses that greatly increase the number of publically available IP addresses. The problem was that IPv6 was “too little too late”. The internet had already adopted Network Address Translation (NAT) to solve the IPv4 address space exhaustion problem by multiplexing a single public IPv4 address into multiple private IP addresses, and therefore IPv6 never gained traction, making IPv4 with NAT the de facto standard today. The lesson here (and throughout other places in human history) is that old and widely adopted infrastructure is not replaced, but tweaked with elegant backward compatible “hacks” to satisfy new requirements.
Client Side
Intel’s SGX is an extension to the x86 architecture that introduces new x86 instructions that allow CPU encryption of physical memory in protected “enclaves”. Since new CPU instructions have to be explicitly executed by the application in order to use these enclaves, all current and legacy application must be modified in order to include these instructions. In fact, Intel built prototypes [1] of Open Source Enterprise Rights Management and Secure Video Conferencing software protected with SGX, which required a full refactoring of the each application into trusted and untrusted parts.
With the IPv4 to IPv6 transition failure, history has taught that existing infrastructure will not be replaced and therefore it is not reasonable to expect all vendors of all current and legacy applications to rewrite their applications to separate trusted and untrusted code and data and use Intel’s new SGX instructions. This same history lesson says that the industry will not backport homomorphic encryption technology which requires current and legacy applications to be modified, for protecting all applications. Since abstraction was a design goal, A1Logic’s RHS is both backward and forward compatible with unmodified legacy applications and future applications that have not been written yet. In the IPv4 analogy, RHS protects unmodified applications without requiring them to change, just like NAT allowed more devices on the internet without requiring the internet to change. For smooth adoption of new technology, abstraction should be maintained so that upper layers (source code) are not impacted by modifications in the lower layers (SGX’s encrypted memory bus writes from the CPU).
More important than adoption of SGX is that it has a fatal flaw in the client-side use case: it cannot interact with user devices, such as mouse, keyboard and display in a safe manner. The SGX enclave shown in Figure 1 is an “Island of Trust” on the physical machine, where the Operating System (OS) and applications are untrusted. Since the OS’s purpose is to interface between the applications and the hardware, the SGX enclave code must either go through the untrusted OS to use hardware, or not have any User Interface. Research has been done in the area of allowing SGX to interface with user devices. The solution in SGXIO [2] is to use the same technique that the RHS already uses: hypervisors to redirect user device communication. In short, SGXIO requires application modification, SGX and a hypervisor, while RHS requires only a hypervisor to obtain the same result.
A possible confidentiality use case for SGX is for new applications to protect encryption keys in memory with low overhead, acting as a Secure Element. Ciphertext could be imported into the enclave, decrypted with the protected key and then the clear text could be copied out of the enclave so that it can interact with user devices. However from a threat modelling point of view, the encryption key is only as valuable as the data that it is protecting the confidentiality of, so copying the clear text out of the enclave defeats the whole purpose of the protection scheme. For example, if there is an encrypted file with credit card numbers, malware outside the enclave can be waiting for the clear text to be copied out after decryption for display on the screen, which is where the data can be stolen.
Server Side
SGX might have had a place in the cloud hosted datacenter because customers might assume an Untrusted Computing Base in the cloud, and cloud applications commonly do not interact with user devices such as mouse, keyboard and display. There have even been some tricks as seen in Graphene-SGX [3] and Haven [4] to allow cloud applications to be protected by SGX without modification, such as by pulling application dependencies from the OS into the SGX enclave and simulating an OS in user land. However, the Untrusted Computing Base problem is already being solved by AMD Secure Memory Encryption [5], AMD Secure Encrypted Virtualization [5], and Intel Total Memory Encryption [6], which would not require modifications to the application or a custom Operating System.
AMD SME, AMD SEV and Intel TME can transparently encrypt memory with Virtual Machine (VM) granularity, which means that cloud applications which run on VMs on a physical server in the untrusted cloud host’s datacenter get the same confidentiality guarantees provided by SGX, without the vendor having to modify the application, or play tricks in the SGX enclave such as pulling in OS dependencies. The fusion of the Docker containers with VMs will accelerate the adoption of VM encryption. SGX could help in authentication or the theoretical corner case of protecting VM elements from themselves, where the OS in a cloud VM is compromised possibly by an exploit of the application running in the VM. In this case, data inside the enclave would be protected from malware in the VM.
Conclusion
Due to A1Logic’s RHS design using VMs rather than SGX enclaves, customers can protect their workloads in the cloud or client side, simply by enabling SME, SEV or TME. In addition, customers do not have to modify application code or application configuration for nonstandard environments [4]. Most applications today can run on physical machines, and since VMs simulate physical machines, the applications should be able run unmodified on VMs. A1Logic’s RHS protects data “in use” by running unmodified applications in isolated VMs, and new VM memory encryption technologies will protect applications in the RHS, transparently to the RHS and to the application being protected. SGX provided too little too late.
Thanks to Dr. Atul Luykx of Visa for his feedback on this article.