Brief Introduction to Secure Cryptographic Enclaves

Some enclave history

When Apple released the iPhone 5S in 2013, most people focused on its new camera and features such as Touch ID. However, on top of these features, Apple introduced what was meant to be a very influential idea on the cryptography world. Underpinning Touch ID, the Secure Enclave Processor (SEP) was presented as a separate sub processor that would store sensitive data and run computer programs on top of it. The sensitive data could never be accessed by the regular CPU. The design and inner workings were kept secret by Apple who released only sparse information on the internals. However, some time after that, Intel also started offering such a feature named Intel Software Guard Extensions, or SGX for short that promised to keep the data encrypted even while in-use.  Shortly after, AMD started offering a similar product, and even Amazon AWS developed a software-based secure enclave of its own. While all 4 products have some differ significantly, they all focus on protecting the data in-use aiming at slightly different usecases.

Why it is useful

Before the introduction of enclaves, the technology for segregating your setup into isolated components was the Virtual Machine (VM). Virtual Machines acted like a sandbox in which you could open anything you want, execute it, and it wouldn’t affect the rest of the system. This software was developed as a testing ground, ensuring that everything happening in the VM would stay in the VM, without leaking out. The need for this was apparent at the time with a boom in malware and a fragmented OS market with many compatibility issues dictating the need for a solution that could enable quick and safe testing.

Instead of a sandbox, a blackbox

Enclaves can be easily understood as reverse Virtual Machines. There is again a place where execution can be made without affecting the rest of the system. However, the target now has shifted from avoiding whatever is kept in the separate space to leak out, to not allowing the rest of the system to see what is going on inside the enclave. Instead of a sandbox, a blackbox. The need for such a system arose from the increasing consumer demand for more privacy and more control over their own private data. Hence, the enclaves form a quick and elegant solution to protecting said data.

How it works

There are currently 3 types of implementations for enclaves. The Apple implementation, the Intel/AMD implementation, and the Amazon implementation. Apple’s approach is based on a physical separation between the CPU and the secondary secure processor (they are located in different sections on the motherboard). The Intel/AMD implementation relies on additional CPU instructions and trusted hardware, which hosts the confidential data and the software to be used on the data. And finally, the Amazon AWS implementation, which is not hardware-dependent since its implemented on the software-level by AWS. All of these implementations, attempt to accomplish the same goal; That is, to isolate some data and computation from the rest of the system giving access only to agents with privileged rights. Truth is that there is no silver bullet when it comes to secure enclaves (for now). Each implementation takes a different assumption regarding development type, scalability, speed, and security. On a future article we will expand on the differences between those enclaves and how the can be best used for each usecase.

Epilogue

Encryption in-use is a very hot topic in the security and privacy community in the past few years. As in any relatively hot topic, multiple solutions arise to solve the issue at hand. In the privacy/security space the solutions are dubbed as privacy-enhancing technologies (PETs) and secure enclaves is the one with the widest industry adoption thanks to its ease of use, availability, and performance.

At Decentriq we use secure enclaves in conjunction with other PETs to develop data clean rooms that allow data collaboration on sensitive data without the need to trust anyone.