Increasingly stringent privacy regulations—for example, the European Union’s General Data Protection Regulation (GDPR) or the California Consumer Privacy Act (CCPA) in the U.S.—and sophisticated attacks leading to massive breaches have increased the demand for protecting data in use, or encryption in use. The encryption-in-use paradigm is important for security because it protects data during processing; in contrast, encryption at rest protects data only when it is in storage and encryption in transit protects data only when it is being communicated over the network. In both cases, however, the data is exposed during computation—namely, while it is being used/processed at the servers. It is during that processing window when many data breaches happen, either at the hands of hackers or insider attackers.
Another advantage of encryption in use is that it allows different parties to collaborate by putting their data together for the purpose of learning insights from their aggregate data—without actually sharing their data with each other. This is because the parties share encrypted data with each other, so no party can see the data of any other party in decrypted form. The parties can still run useful functions on the data and release only the computation results. For example, medical organizations can train a disease-treatment model on their aggregate patient data without seeing each other’s data. Another example is within a financial institution, such as a bank, where data analysts can build models across different branches or teams that would otherwise not be allowed to share data with each other.
Today there are two prominent approaches to secure computation:
A purely cryptographic approach (using homomorphic encryption and/or secure multi-party computation).
A hardware security approach (using hardware enclaves sometimes combined with cryptographic mechanisms), also known as confidential computing.
There is a complex trade-off between these two approaches in terms of security guarantees, performance, and deployment. Comparisons between the two for ease of use, security, and performance are shown in Tables 1, 2, and 3. For simple computations, both approaches tend to be efficient, so the choice between these two would likely be based on security and deployment considerations. However, for complex workloads, such as advanced machine-learning (ML) training (for example, transformers) and rich SQL analytics, the purely cryptographic approach is too inefficient for many real-world deployments. In these cases, the hardware security approach is the practical choice.
Cryptographic Computation
There are two main ways to compute on encrypted data using cryptographic mechanisms: homomorphic encryption and secure multi-party computation.
Homomorphic encryption permits evaluating a function on encrypted input. For example, with fully homomorphic encryption,9 a user can send to a cloud Encrypt(x) for some input x, and a cloud can compute Encrypt(f(x)) using a public evaluation key for any function f.
Secure multi-party computation23 is often more efficient than homomorphic encryption and can protect against a malicious attacker, but it has a different setup, shown in Figure 1. In secure multi-party computation (MPC), n parties having private inputs x_1, ..., x_n, compute a function f(x_1, ..., x_n) without sharing their inputs with each other. This is a cryptographic protocol at the end of which the parties learn the function result, but in the process no party learns the input of the other party beyond what can be inferred from the function result.
There are many different threat models for computation in MPC, resulting in different performance overheads. A natural threat model is to assume that all but one of the participating parties are malicious, so each party need only trust itself. This natural threat model, however, comes with implementations that have high overheads because the attacker is quite powerful. To improve performance, people often compromise in the threat model by assuming that a majority of the parties act honestly (and only a minority are malicious).
Also, since the performance overheads often increase with the number of parties, another compromise in some MPC models is to outsource the computation to m < n servers in different trust domains. For example, some works propose outsourcing the secure computation to two mutually distrustful servers. This latter model tends to be weaker than threat models, where a party needs to trust only itself. Therefore, in the rest of this article, we only consider maliciously secure n-party MPC. This also makes the comparison to secure computation via hardware enclaves more consistent, because this second approach, which is discussed next, aims to protect against all parties being malicious.
Hardware Enclaves
Figure 2 shows a simplified view of one processor. The light blue area denotes the inside of the enclave. The Memory Encryption Engine (MEE) is a special hardware unit that contains cryptographic keys and, by using them, it encrypts the data leaving the processor, so the memory bus and memory receive encrypted data. Inside the processor, the MEE decrypts the data so the core can compute on data at regular processor speeds.
Trusted execution environments such as hardware enclaves aim to protect an application’s code and data from all other software in the system. The MEE ensures that even an administrator of a machine with full privileges examining the data in memory sees encrypted data (Figure 2). When encrypted data returns from main memory into the processor, the MEE decrypts the data and the CPU computes on decrypted data. This is what enables the high performance of enclaves compared with the purely cryptographic computation: The CPU performs computation on raw data as in regular processing.
At the same time, from the perspective of any software or user accessing the machine, the data looks encrypted at any point in time: The data going into the processor and coming out is always encrypted, giving the illusion that the processor is computing on the encrypted data. Hardware enclaves also provide a useful feature called remote attestation,5 with which remote clients can verify code and data loaded in an enclave and establish a secure connection with the enclave, which they can use to exchange keys.
A number of enclave services are available today on public clouds such as Intel Software Guard Extensions (SGX) in Azure, Amazon Nitro Enclaves in Amazon Web Services (although this enclave is mostly software-based and does not provide memory encryption), Secure Encrypted Virtualization (SEV) from AMD12 in Google Cloud, and others. Nvidia recently added enclave support in its H100 GPU.6
Ease-of-use comparison. With a purely cryptographic approach, there is no need for specialized hardware and special hardware assumptions. At the same time, in a setting like MPC, the parties must be deployed in different trust domains for the security guarantees of MPC to hold. In the threat models discussed earlier, participating organizations have to run the cryptographic protocol on site or in their private clouds, which is often a setup, management, and/or cost burden compared with running the whole computation on a cloud. This can be a deal-breaker for some organizations.
| Cryptographic Computing (such as FHE and MPC) | Enclave/Confidential Computing |
| x Requires cryptographic expertise to design a tailored protocol for increased performance | √ Can run proprietary systems in confidential computing without modification |
| √ Does not require specialized hardware | x Requires specialized hardware to run on |
| x Requires a deployment across multiple trust domains | √ Can be deployed in a single trust domain (for example, the Cloud) |
| x Cannot support proprietary systems |
With homomorphic encryption, in principle, the whole computation can be run in the cloud, but homomorphic encryption does not protect against malicious attackers as MPC and hardware enclaves do. For such protection, you would also have to use heavy cryptographic tools, such as zero-knowledge proofs.
In contrast, hardware enclaves are now available on major cloud providers such as Azure, AWS, and Google Cloud. Running an enclave collaborative computation is as easy as using one of these cloud services. This also means that to use enclaves, you do not need to purchase specialized hardware: The major clouds already provide services based on these machines. Of course, if the participating organizations want, they could each deploy enclaves on their premises or in private clouds and perform the collaborative computation across the organizations in a distributed manner similar to MPC. The rest of this article assumes a cloud-based deployment for hardware enclaves, unless otherwise specified.
With cryptographic computing, cryptographic expertise is often required to run a certain task. Since the cryptographic overhead is high, tailoring the MPC design for a certain task can bring significant savings. At the same time, this requires expertise and time that many users do not have. Hiring cryptography experts for this task is burdensome and expensive. For example, a user cannot simply run a data-analytics or machine-learning pipeline in MPC. Instead, the user has to identify some key algorithms in those libraries to support, employ tailored cryptographic protocols for those, and implement the resulting cryptographic protocols in a system that likely requires significant code changes as compared with an existing analytics/ML pipeline.
In contrast, modern enclaves provide a VM interface, resulting in a Confidential Virtual Machine.10 This means that the user can install proprietary software in these enclaves without modifying this software. Complex codebases are supported in this manner. For example, Confidential Google Kubernetes engine nodes11 enable Kubernetes to run in confidential VMs. The first iteration of the enclave, Intel SGX, did not have this flexibility and required modifying and porting a program to run it in the enclave. Since then, it has been recognized that to use this technology for confidential data pipelines, users must remove the friction of porting to the enclave interface. This is how the confidential VM model was born.
Security comparison. The homomorphic encryption referred to here can compute more complex functions, meaning either fully or leveled homomorphic encryption. Some homomorphic encryption schemes can perform simple functions efficiently (such as addition or low-degree polynomials). As soon as the function becomes more complex, performance degrades significantly.
| Cryptographic Computing (such as FHE and MPC) | Enclave/Confidential Computing |
| x Homomorphic encryption is typically slower than MPC for non-trivial functionalities and does not protect against malicious attackers | √ Enclaves offer a notion of integrity of computation and data, unlike FHE |
| √ MPC does not suffer from side-channel attacks within the permitted number of compromised parties. | x Enclaves suffer from side-channel attacks. (Leveraging oblivious computation prevents many of these attacks.) |
| x Enclaves have a large, trusted compute base (TCB). |
Homomorphic encryption is a special form of secure computation, where a cloud can compute a function over encrypted data without interacting with the owner of the encrypted data. It is a cryptographic tool that can be used as part of an MPC protocol. MPC is more generic and encompasses more cryptographic tools; parties running an MPC protocol often interact with each other over multiple rounds, which affords better performance than being restricted to a noninteractive setting.
For general functions, homomorphic encryption is slower than MPC. Also, as discussed, it does not provide malicious security without employing an additional cryptographic tool such as zero-knowledge proofs, which can be computationally expensive.
When an MPC protocol protects against some malicious parties, it also protects against any side-channel attacks at the servers of those parties. In this sense, the threat model for the malicious parties is cleaner than for hardware enclaves’ threat model because it does not matter what attack adversaries mount at their servers; MPC considers any sort of compromise for these parties. For the honest parties, MPC does not protect against side-channel attacks.
In the case of enclaves, attackers can attempt to perform side-channel attacks. A common class of side-channel attack (which encompasses many different types) involves an attacker who observes which memory locations are accessed as well as the order and frequency of these accesses. Even though the data at those memory locations is encrypted, seeing the access pattern can provide confidential information to the attacker. These attacks are called memory-based access-pattern attacks, or simply access-pattern attacks.
There has been significant research on protecting against these access-pattern side-channel attacks using a cryptographic technique called data-oblivious computation. Oblivious computation ensures that the accesses to memory do not reveal any information about the sensitive data being accessed. Intuitively, it transforms the code into a side-channel-free version of the code, similar to how the OpenSSL cryptographic libraries have been hardened.
Oblivious computation protects against a large class of side-channel attacks based on cache-timing-exploiting memory accesses, page faults, branch predictor, memory bus leakage, dirty bit, and others.
Hardware enclaves such as Intel SGX are also prone to other side-channel attacks besides access patterns (for example, speculative-execution-based attacks, attacks to remote attestation), which are not prevented by oblivious computation. Fortunately, when such attacks are discovered, they are typically patched in a short amount of time by cloud providers, such as Azure confidential computing and others. Even if the hardware enclaves would be vulnerable for the time period before the patch, the traditional cloud security layer is designed to prevent attackers from breaking in to mount such a side-channel attack. This additional level of security would not exist on a client-side usage of enclaves.
Subverting this layer as well as being able to set up a side-channel attack in a real system with such protection is typically much harder to do for an attacker because it requires the attacker to succeed at mounting two different and difficult types of attacks. It is not sufficient for the attacker to succeed in attacking only one. At the time of writing this article, there is no evidence of any such dual attack having occurred on state-of-the-art public clouds such as Azure confidential computing. This is why, when using hardware enclaves, you can assume that the cloud provider is a well-intended organization and its security practices are state of the art, as would be expected from major cloud providers today.
Another aspect pertaining to security is the size of the trusted computing base (TCB). The larger the TCB, the larger the attack surface and the more difficult it is to harden the code against exploits. Considering the typical use of enclaves these days—namely, the confidential VM abstraction—the enclave contains an entire virtual machine. This means that the TCB for enclaves is large—many times larger than the one for cryptographic computation. For cryptographic computation, the TCB is typically the client software that encrypts the data, but there might be some extra assumptions on the server system, depending on the threat model.
Performance comparison. Cryptographic computation is efficient enough for running simple computations, such as summations, counts, or low-degree polynomials. As of the time this article was published, cryptographic computation was still too slow to run complex functions, such as ML training or rich data analytics. Take, for example, training a neural-network model. Recent state-of-the-art work on Microsoft Falcon (2021) estimates that training a moderate-size neural network such as VGG-16 on datasets such as CIFAR-10 could range into years. This work also assumes a threat model with three parties that have an honest majority, so a weaker threat model than the n organizations where n-1 can be malicious.
| Cryptographic Computing (such as FHE or MPC) | Enclave/Confidential Computing |
| x MPC (and homomorphic encryption) are still very inefficient for complex computation. | √ Enclave computation is much more efficienct, sometimes close to vanilla processor speeds. |
Now let us take an example with the stronger threat model: our state-of-the-art work on Senate,18 which enables rich SQL data analytics with maliciously secure MPC. Senate improved the performance of existing MPC protocols by up to 145 times. Even with this improvement, Senate can perform analytics only on small databases of tens of thousands of rows and cannot scale to hundreds of thousands or millions of rows because the MPC computation runs out of memory and becomes very slow. We have been making a lot of progress on reducing the memory overheads in our recent work on MAGE13 and in another work, Piranha, on employing GPUs for secure computation learning,22 but the overheads of MPC remain too high for training advanced ML models and for rich SQL data analytics. It could still take years until MPC becomes efficient for these workloads.
Some companies claim to run MPC efficiently for rich SQL queries and ML training. How is that possible? An investigation of a few of them showed that they decrypt a part of the data or keep a part of the query processing in unencrypted form, which exposes that data and the computation to an attacker. This compromise reduces the privacy guarantee.
Hardware enclaves are far more efficient than cryptographic computation because, as explained earlier, deep down in the processor the CPU computes on unencrypted data. At the same time, data coming in and out of the processor is in encrypted form, and any software or entity outside of the enclave that examines the data sees it in encrypted form. This has the effect of computing on encrypted data without the large overheads of MPC or homomorphic encryption. The overheads of such computation depend a lot on the workload, but there have been overheads of, for example, 20%—twice for many workloads.
Adding side-channel protection, such as oblivious computation, can increase the overhead, but overall the performance of secure computation using enclaves still is much better than MPC/homomorphic encryption for many realistic SQL analytics and ML workloads. The amount of overhead from side-channel protection via oblivious computation varies based on the workload—from adding almost no overhead for workloads that are close to being oblivious to 10 times the overhead for some workloads.
The Nvidia GPU enclaves16 in the H100 architecture offer significant speed-ups for ML workloads, especially for generative AI. Indeed, there are significant industry efforts around using GPU enclaves to protect prompts during generative AI inference, data during generative AI fine-tuning, and even model weights during training of the foundational model. At the time of writing this article, Azure offers a preview of its GPU Confidential Computing service, and other major clouds have similar efforts under way. Confidential computing promises to bring the benefits of generative AI to confidential data, such as the proprietary data of businesses, to increase their productivity and the private data of users to assist them in various tasks.
Real-world Use Cases
Because of the need for data protection in use, there has been an increase in use secure-computation use cases, whether it is cryptographic or hardware-enclave based. This section looks at use cases for both types.
Cryptographic computation. One of the main resources to track major use cases for secure multi-party computation is the MPC Deployments dashboard15 hosted by University of California, Berkeley. The community can contribute use cases to this tracker if they have users. A variety of deployed use cases are available for applications such as privacy-preserving advertising, cryptocurrency wallets (Coinbase, Fireblocks, Dfns), private inventory matching (J.P. Morgan), privacy-preserving Covid exposure notifications (Google, Apple), and others.
Most of these use cases are centered around a specific, typically simple computation and use specialized cryptography to achieve efficiency. This is in contrast to supporting a more generic system, on top of which you can build many applications such as a database, data-analytics framework, or ML pipeline—these use cases are more efficiently served by confidential computing.
One prominent use case was collecting Covid exposure notification information from users’ devices in a private way. The organizations involved were Internet Security Research Group (ISRG) and National Institutes of Health (NIH). Apple and Google served as injection servers to obtain encrypted user data, and the ISRG and NIH ran servers that computed aggregates with help from MITRE. The results were shared with public health authorities. The computation in this case checked that the data uploaded from users satisfied some expected format and bounds, and then performed simple aggregates such as summation.
Heading toward a more general system based on MPC, Jana8 is an MPC-secured database developed by Galois Inc. using funding from DARPA over 4½ years and providing privacy-preserving data as a service (PDaaS). Jana’s goal is to protect the privacy of data subjects while allowing parties to query this data. The database is encrypted, and parties perform queries using MPC. Jana also combines differential privacy and searchable encryption with MPC.
The Jana developers detail the challenges7 they encountered, such as “Performance of queries evaluated in our linear secret-sharing protocols remained disappointing, with JOIN-intensive and nested queries on realistic data running up to 10,000 times slower than the same queries without privacy protection.” Nevertheless, Jana was used in real-world prototype applications, such as inter-agency data sharing for public policy development, and in a secure computation class at Columbia University.
Confidential Computing Use Cases
Because of its efficiency, confidential computing has been more widely adopted than cryptographic computation. The major clouds—Azure, AWS, and Google Cloud—offer confidential computing solutions. They provide CPU-based confidential computing, and some are in the process of offering GPU-based confidential computing (for example, Azure has a preview offering for the H100 enclave). A significant number of companies have emerged to enable various types of workloads in confidential computing in these clouds. Among them are Opaque, Fortanix, Anjuna, Husmesh, Antimatter, Edgeless, and Enclaive.
For example, Opaque17 enables data analytics and ML to run in confidential computing. Using the hardware enclave in a cloud requires significant security expertise. Consider, for example, that a user wants to run a certain data-analytics pipeline—say, from Databricks—in confidential VMs in the cloud. Simply running in confidential VMs is not sufficient for security: The user has to be concerned with correctly setting up the enclaves’ remote attestation process, key distribution and management, a cluster of enclaves that offer scaling out, as well as defining and enforcing end-to-end policies on who can see what part of the data or the computation.
To avoid this work for the user, Opaque provides a software stack running on top of the enclave hardware infrastructure that allows the user to run the workflow frictionlessly without security expertise. Opaque’s software stack takes care of all these technical aspects. This is the result of years of research at UC Berkeley, followed by product development. Specifically, the technology behind Opaque was initially developed in the Berkeley RISELab (Realtime Intelligent Secure Explainable Systems),19 and it has evolved to support ML workloads and a variety of data-analytics pipelines.
Opaque can scale to an arbitrary cluster size and big data, essentially creating one “large cluster enclave” out of individual enclaves. It enables collaboration between organizations or teams in the same organization that cannot share data with each other: These organizations can share encrypted data with each other in Opaque’s workspace and perform data analytics or ML without seeing each other’s dataset. Use cases include financial services (such as cross-team collaboration for identity resolution or cross-organization collaboration for crime detection); high-tech (such as fine-tuning ML from encrypted data sets); a privacy-preserving large language model (LLM) gateway that offers logging, control, and accountability; and generating a verifiable audit report for compliance.
A number of companies have created the Confidential Computing Consortium,2 an organization meant to catalyze the adoption of confidential computing through a community-led consortium and open collaboration. The consortium lists more than 30 companies that offer confidential computing technology.
Following are a few examples of end use cases. Signal, a popular end-to-end encrypted messaging application, uses hardware enclaves to secure its private contact discovery service.21 Signal built this service using techniques from the research projects Oblix14 and Snoopy.4 In this use case, each user has a private list of contacts on their device, and Signal wants to discover which of these contacts are Signal users as well. At the same time, Signal does not want to reveal the list of its users to any user, nor does it want to learn the private contact list of each user. Essentially, this computation is a private set intersection. Signal investigated various cryptographic computation options and concluded that these would not perform fast enough and cheaply enough for its large-scale use case. As a result, it chose to use hardware enclaves in combination with oblivious computation to reduce a large number of side channels, as discussed earlier. Our work on Oblix and Snoopy developed efficient oblivious algorithms for use inside enclaves.
Other adopters include the cryptocurrency MobileCoin, the Israeli Ministry of Defense,1 Meta, ByteDance (to increase user privacy in TikTok), and many others.
Combining the Two Approaches
Given the trade-off between confidential computing via enclaves and secure computation via cryptography, a natural question is whether a solution can be designed that benefits from the best of both worlds. A few solutions have been proposed, but they still inherit the slowdown from MPC.
For example, my students and I have collaborated with Signal with its SecureValueRecovery20 system to develop a mechanism that helps Signal users recover secret keys based on a combination of different hardware enclaves on three clouds and secure multi-party computation. The purpose of this combination is to provide a strong security guarantee, stacking the power of the two technologies as defense in depth.
A similar approach is taken by Meta and Fireblocks, a popular cryptocurrency wallet: They both combine hardware enclaves with cryptographic computation for increased security. The resulting system will be at least as slow as the underlying MPC, but these examples are for specialized tasks for which there are efficient MPC techniques.
Conclusions and How to Learn More
Secure computation via MPC/homomorphic encryption versus hardware enclaves presents trade-offs involving deployment, security, and performance. Regarding performance, it depends significantly on the target workload. For simple workloads, such as simple summations, low-degree polynomials, or simple ML tasks, both approaches can be ready to use in practice. However, for rich computations, such as complex SQL analytics or training large ML models, only the hardware enclave approach is practical enough at the moment for many real-world deployment scenarios.
Confidential computing is a relatively young sub-field in computer science—but one that is evolving rapidly. To learn more about confidential computing, attend or watch the content from the Confidential Computing Summit,3 which was held in June of 2024 in San Francisco. This conference is the premier in-person event for confidential computing and has attracted the top technology players in the space, from hardware manufacturers (Intel, ARM, Nvidia) to hyperscalers (Azure, AWS, Google), solution providers (Opaque, Fortanix), and use-case providers (Signal, Anthropic). The conference is hosted by Opaque and co-organized by the Confidential Computing Consortium.
Join the Discussion (0)
Become a Member or Sign In to Post a Comment