September 10, 2024
Volume 22, issue 4

Download PDF version of this article PDF

Confidential Computing Proofs

An alternative to cryptographic zero-knowledge

Mark Russinovich, Cédric Fournet, Greg Zaverucha, Josh Benaloh, Brandon Murdoch, Manuel Costa

Zero Knowledge Proofs (ZKP) are versatile cryptographic algorithms that yield strong privacy and integrity guarantees for computations on confidential data. For example, they have been used to realize anonymous credentials and as a building block in more complex applications, such as e-voting and decentralized finance.

Confidential Computing (CC) similarly yields privacy and integrity guarantees but follows a different system-based approach: Computations on confidential data are executed inside processors equipped with hardware mechanisms to isolate them from the rest of the platform and measure their code. The resulting attestation reports serve the same purpose as cryptographic proofs: They allow remote parties to verify that the computation was correctly executed without disclosing its confidential data. To facilitate the comparison with ZKPs, hardware-based attestation reports are referred to as Confidential-Computing Proofs (CCPs). This does not presume they are perfect mathematical proofs or interchangeable with ZKPs; in both cases, argument or evidence may be more accurate than proof but less common terminology.

This article attempts to relate the ZKP and CCP concepts. This is challenging since they are being developed by different communities, under very different trust assumptions, and both are still making fast progress and exploring new use cases. The article begins by describing how CCPs can be used to provide functionality similar to ZKPs. It then describes the tradeoffs they provide in terms of security, performance, usability, and scalability. It also illustrates them on a practical use case where both approaches apply. This side-by-side comparison is meant to facilitate discussions between ZKP and CC experts and be of use to those considering their practical deployment.

Introduction and Motivation

Suppose that Alice is planning a dream vacation and wants to rent a luxury sailboat. Bob has a sailboat that he would like to rent, but he has specific criteria: A prospective renter must be at least 30 years old, have a suitable sailing license, have the funds to pay for the rental, and either have obtained insurance or be capable of self-insuring. Alice meets all of Bob's criteria but doesn't want to reveal specifics. She fears discrimination based on her identity and doesn't want to disclose her assets to self-insure the expensive boat.

Scenarios like this are not new. Fifty years ago, the only available approach was a trusted third party (TTP). An escrow agent can serve as a TTP as long as Alice trusts the agent to maintain her privacy and Bob trusts the agent to perform the necessary validations and vouch for Alice's credentials.

Forty years ago, zero-knowledge protocols were introduced that enable such "proofs" to be accomplished by replacing the TTP with mathematical assumptions. Since that time, our understanding of ZKPs has grown, their capabilities have expanded, and more efficient instantiations have been developed. Nevertheless, the ZKP process is still generally complex and cumbersome, and infrastructure to support scenarios such as Alice's rental simply doesn't exist.

Meanwhile, the hardware infrastructure has improved, and it is now a good time to re-examine whether a modern version of the TTP might be viable for some scenarios. Specifically, a variety of trusted execution environments (TEEs) is now available with the potential to solve Alice's rental needs more easily and efficiently by applying different assumptions. For example, a cloud provider might provide TEE services that Alice and Bob could use. Bob's requirements could be encoded into a program that Alice could inspect. If Alice and Bob are willing to accept the TEE assumptions, they can execute their agreement without even the cloud provider learning the details.

TEEs are not suitable for all proof applications. Their trust assumptions are different from those required for cryptographic ZKPs; many other tradeoffs are described in the side-by-side comparison shown in table 1. There are scenarios, however, where TEEs may provide an attractive alternative. To that end, this article introduces CCPs and explores their characteristics as a proof system.

Defining Proofs

Let's first specify what is meant by proofs, based on their existing cryptographic ideal functionality, regardless of their implementation. Consider two parties, a prover and a verifier, that agree on a property of interest, expressed as a pure Boolean function parameterized by public inputs (defining an instance of the property) and private inputs (providing witnesses for this instance).

Given an instance and witnesses such that the property holds (i.e., the Boolean function returns "true"), the prover can produce a proof to convince the verifier that it knows some witnesses for this instance, without disclosing its witnesses to the verifier.

A proof system is sound when no one can forge a proof for any instance without knowing a valid witness. It is zero-knowledge when the proof yields no information about the witnesses used by the prover (beyond the fact that they satisfy the instance). The focus here is on noninteractive, universally verifiable proofs, meaning that the prover generates the proof without communicating with the verifier, and any party can verify the proof given the property instance.

Intuitively, the property may describe a puzzle, the witness may describe a solution, and the proof may enable a party to convince others that it has solved the puzzle without disclosing its solution.

As an example, the public inputs may consist of a hash, a database query, and its result; the private inputs may comprise the whole contents of a database; and the function may verify that (1) the hash is the cryptographic digest of the database; and (2) evaluating the query on this database yields this result. The hash may be used by the verifier to authenticate the database (e.g., it may be given or signed by a trusted party) and to ensure the same database is used for answering a series of queries.

This example illustrates two common motivations for proofs.

• Privacy for the prover. Thanks to zero-knowledge, the prover controls precisely which information it reveals about the database, such as authorizing a series of queries it executes and proves. The prover has assurance that the proof reveals nothing more about the database than what can be learned from the responses to the queries.

• Integrity and performance for the verifier. Only the prover needs to run the computation and maintain the potentially large database. In contrast, the verifier operates only on the inputs, outputs, and proofs it cares about, which can be much simpler. This form of delegation is particularly useful for verifiers with limited capabilities, even when privacy is not a requirement.

The example also shows that many properties already involve some form of cryptography in their definition. Notably, public inputs often include cryptographic commitments to private data, which can be used, for example, to correlate multiple proofs sharing some of their private state—here, the whole state of the database.

Proofs Based on Cryptographic Algorithms

The defining paper on ZKPs was published in 1985.⁶ Noninteractive ZKPs, introduced soon after, are closely related to digital signatures.⁴ In fact, some ZKPs such as Schnorr proofs yield practical signature schemes such as EdDSA (Edwards-curve Digital Signature Algorithm). Intuitively, a signature is a basic kind of proof, where the message and the verification key are public inputs, and the signing key is a private input. General ZKPs support arbitrary computations on their inputs.

Cryptographic proofs typically provide perfect information-theoretic privacy, meaning that the proof is statistically independent from the witness used to produce it; and computational soundness, meaning that an attacker with limited computing resources can forge a proof only with negligible probability. A common formalization of this guarantee is called knowledge soundness, where it is shown that an adversary who can output a proof accepted by the verifier must know a witness. (How you go about proving an adversary "knows" a witness is a fascinating question beyond the scope of this article; Oded Goldreich's book, Foundations of Cryptography, provides an accessible explanation.⁵)

Classic cryptographic ZKP constructions target simple, fixed properties, which can be expressed using, for example, linear or quadratic functions. Intuitively, the prover and the verifier both evaluate the function by computing on commitments instead of plaintext values, and the proof provides just enough auxiliary values to match some of these commitments against the function's public inputs and outputs. While the resulting proofs are linear in the size of the property and the overhead is large for both parties, these constructions are practical for many applications involving simple functions.

More-advanced ZKP constructions^10,12 involve more-succinct proofs, enabling the whole computation to be verified in a logarithmic, or even constant, number of operations on cryptographic commitments. While this is very efficient for verifiers, which sometimes can verify millions of operations at a cost similar to plain signature verification, this requires more-advanced algorithms and incurs additional costs for the prover.

Independently of core proof systems, there is much work to compile properties of interest (expressed for example in subsets of C or LLVM code) into the systems of linear or quadratic equations supported by these cryptographic algorithms. Even when the compilation applies to arbitrary properties, the resulting systems of equations can get much larger (hence, more costly to prove) than the source code of the property. This overhead is also hard to predict, as some operations are directly encoded, while others require an equation for every bit of their operands.

The prover typically executes the compiled property in a custom mode where each step of the computation produces witnesses, which are accumulated in the resulting proof. Since each step involves cryptographic computations (such as operations on elliptic curves), this generally entails several orders of magnitude of performance overhead compared with native execution.

Proofs based on Confidential Computing

Confidential computing was introduced in 2014 with some of the first applications of Software Guard Extensions (SGX) enclaves.¹³ It leverages hardware support for TEEs to protect the privacy and integrity of computation. The hardware ensures that the contents of a TEE are not visible to and cannot be modified by any party outside of the TEE, including hypervisors and other privileged software, and even those that may have access to the TEE's physical device.

A computation running inside a TEE can request it to generate an attestation of its code and initial configuration together with a message chosen at runtime. An attestation is usually implemented by signing a record that includes all this information using a unique, hardware-controlled key bound to the device and endorsed by a platform certificate provided by the hardware vendor. An attestation is effectively a proof that a TEE was started with this code and configuration and then received a request from this code to attest this message. Given the attestation, a verifier can independently review its code and configuration—for example, to confirm that the attested message meets some property.

CC is particularly useful to protect computations from their hosting environment, such as a cloud provider, and to let multiple parties jointly compute on data without sharing that data with the other parties. CC's attractiveness owes much to its practicality: Unlike advanced cryptographic computation techniques such as ZKP, multiparty computation, and homomorphic encryption, TEEs are highly compatible with existing software and usually have low performance overheads.

Achieving zero-knowledge with CC

Continuing from our definition of proofs, suppose the prover and the verifier agree on a program that (1) reads an instance from its initial memory; (2) reads its witnesses from the untrusted host; (3) verifies the property; and (4) if the verification succeeds, requests and returns its attestation report as a proof that the property holds.

The prover creates a TEE that runs the program for this instance, then provides the witnesses and collects the resulting proof. This proof is just a signature on a specification of the property instance, rather than (a cryptographic encoding of) its execution.

CCP verification involves three checks, verifying that:

• The proof is a valid attestation report from a trusted hardware platform.

• The program correctly implements the property and matches the code measurement in the attestation report.

• The instance is correctly encoded in the initial-memory measurement in the attestation report.

At a high level, similar steps are involved in the verification of cryptographic proofs:

• The proof is valid with regard to public parameters obtained from a setup phase.

• The property is correctly encoded using these parameters.

• The instance is correctly encoded using these parameters.

If the hardware is trustworthy, CCPs are sound because the prover may obtain an attestation report that passes these three steps only by creating a TEE for this program and this instance, and then providing correct witnesses for it; and CCPs are zero-knowledge because they are signatures on measurements taken before the witnesses are provided to the TEE, hence, they do not carry any information about these witnesses.

From simple properties to general-purpose computations

Since TEEs can run any program supported by their hardware processor, they offer flexibility in the way they produce proofs. As illustrated below, running larger and more complex programs may be more convenient, but also increases the amount of code that must be trusted by the verifier.

Instead of compiling the property to its own attested code, the prover can create a TEE that runs a small interpreter and takes both the property and its instance as attested inputs. This simplifies verification, since the code executed by the TEE can be reviewed and compiled once and for all. (This is the approach adopted later in this article.)

Instead of creating a TEE for each proof, the prover can create a TEE that handles multiple requests, each including an instance and its witnesses, and (assuming verification succeeds) returns an attestation for each instance.

So far, it is assumed that the prover trusted with the confidentiality of the requests acts as the local host for the TEE that produces its proofs; more generally, if the TEE runs on a remote server, its code may additionally include code to terminate a Transport Layer Security (TLS) connection, for example. It is also implicitly assumed that the property is a pure (deterministic, noninteractive) function; this restriction can be lifted by extending the TEE with system capabilities—for example, to interact with the host or even open connections to other parties.

Side-by-Side Comparison

Table 1 compares CCPs and ZKPs in security, performance, and usability.

Security

Both kinds of proofs—CCPs and ZKPs—involve some trust in cryptography, although ZKPs often involve more advanced cryptographic primitives and security assumptions. Hence, attestation reports usually rely on a traditional public-key infrastructure (PKI) for platform certificates, whereas ZKP schemes may rely on a trusted setup to produce and distribute public parameters.

Fundamentally, the soundness of CCPs is based on trust in the hardware, including its design, manufacture, supply chain, and operations (TEEs are potentially subject to glitches, physical attacks, and side-channel attacks). As an example, if a cosmic ray or overheating causes a bitflip that goes undetected, the CCP prover may yield an unsound proof, whereas the ZKP prover will yield a proof that fails to verify.

These risks can be partly mitigated by, for example, requiring that critical firmware updates have been installed; whitelisting the platform certificates of CPUs provisioned to a datacenter trusted to host the TEEs; and building some redundancy checks in the TEE code. All these requirements can be strictly enforced by verifiers as part of their attestation policies. More generally, modern CPUs are remarkably complex, but they are already trusted to some extent for most applications. Specifically, both for CCP and ZKP, the platform that runs the verifier is implicitly trusted.

For both kinds of proofs, the software TCB includes at least code for the verifier and code for the property to be verified. It is critical that the verifier review that the property is correctly implemented in all cases since (by privacy design) it won't be able to review the details of the run used to produce the proof. While code reviews can be challenging, this task can be facilitated by using formally verified code (notably for cryptography⁷ and parsing¹¹) and a code-transparency service.²

Additional parts of the TCB are specific to the proof technology. For ZKP, they include the custom toolchain used, for example, to compile the property into an arithmetic circuit, as well as their library of cryptographic gadgets with handwritten arithmetic circuits. For CCP, they include a standard toolchain as well as any firmware and runtime support included in the TEE.

Regarding confidentiality, TEEs are intended to protect their code and data from all other parties, including their hosts. This goes beyond zero-knowledge, which (strictly speaking) protects the witnesses given access only to the proof but leaves the protection of the prover itself as a separate issue. More generally, CCP enables proofs where multiple parties each contribute their own private inputs to a TEE (after verifying its attestation) and the TEE finally returns selected results and proofs, whereas ZKP requires that each prover be trusted with all private inputs to produce its proof.

Using PQ (post-quantum) security as an example, let's now consider the agility of both systems should changes be required. With CCPs, this is conceptually straightforward—new standard PQ-safe algorithms are required for the attestation and the PKI—but it requires coordinated changes by many parties and, potentially, updated hardware, making it difficult to make such changes quickly. In contrast, ZKPs are purely software, and the prover and verifier libraries and parameters can be updated quickly. The changes are less straightforward, however, as PQ-safe zero-knowledge constructions are less efficient and mature.

Performance and scalability

Prover performance clearly favors CCPs. Intuitively, TEEs run at the same native speed as any other computation on the CPU, with small additional fixed costs for creating and attesting the TEEs and linear costs for encrypting/decrypting data between the CPU and DRAM (dynamic random access memory). The relative creation overhead is negligible except for very short computations. Hardware encryption at line speed for all I/O can eliminate the linear overhead at a low cost in gate numbers and power budget on server CPUs (a small percentage) but may be more problematic on small devices.

Although initial TEEs suffered from system limitations (limiting, for example, the amount of memory they could use), more recent TEEs enable confidential computations to scale as well as plain computations with less than 10 percent overhead, making verifiable confidential computing a safe default for many applications.

Prover performance for ZKP is an active research topic, and steady progress continues to be made, but producing proofs is still several orders of magnitude more expensive than the computation itself,¹⁴ and the most efficient provers require additional memory to keep intermediate values, keys, and precomputations. While recent algorithms provide excellent scalability in theory and can leverage powerful hardware to accelerate the production of proofs, these additional costs limit their general application and constrain the shape of the computations that can be proved in practice (expressed, for example, as iterated evaluations of the same arithmetic circuit).

Both CCP and ZKP yield succinct proofs that can be efficiently verified even on small devices, with sizes and verification performance approaching those expected of plain public-key cryptography, independent of the size of the computation being verified. For example, compressed attestation reports for Intel SGX and AMD SEV-SNP (Secure Encrypted Virtualization-Secure Nested Paging) are about 2,355 bytes and about 640 bytes verified on a laptop in 27 ms and 13 ms, respectively. Basic ZKPs may be as small as 64 bytes verified in less than 1 ms, whereas Nova compressed proofs for large circuits are about 9 KB verified in about 100 ms.¹⁰

Ease of development and usability

Custom code is required for proof verification: CCPs require specific libraries to process hardware attestations for the TEE platforms they trust, whereas ZKPs require specific libraries for their cryptographic algorithms. This code also needs to be updated and correctly configured, for example, with hardware vendor certificates for TEEs and public parameters for ZKPs. The availability and usability of these libraries are expected to improve over time.

On the prover side, CCP requires TEE-capable hardware, which was initially scarce and limited, whereas ZKP can be implemented purely in software. Major cloud providers now provide a range of managed TEE platforms, lowering this adoption barrier for at least cloud deployments and increasing their usability—for example, by handling firmware updates and platform certificate caches. Similarly, devices such as phones and laptops increasingly provide TEE capabilities.

ZKP uses custom compiler toolchains and initially required cryptographers to write custom application code. The situation is improving with the adoption of shared compilers and formats for arithmetic circuits, but their correct usage still involves substantial expertise and code refactoring. Whereas CCP implicitly supports stateful interactive computations that reuse existing runtimes and software stacks, including legacy and proprietary software, ZKP natively supports only pure computations and requires refactoring for the rest. Some ZKP systems make a different tradeoff between usability and performance by interpreting an existing architecture, such as an ISA or language runtime. Hence, for example, arbitrary machine code or Ethereum contracts may be supported but at a higher cost—their initial implementations could run only a few instructions per second.

Privacy-Friendly Paperwork and Credentials

Let's return to the sailboat rental example outlined in the introduction. As the owner of the sailboat, Bob wants to verify that Alice has assorted credentials that meet his rental policy. These may include a valid form of identification such as a driver's license or passport; a proof of competency such as a sailing certification from an accredited school; a proof of financial soundness to pay for the rental; and either a certificate of insurance that covers some of the risks of sailing or a proof of having sufficient assets to self-insure.

Conveniently, such documents are increasingly available in digital formats, enabling rental agreements to be completed online. Digital driving licenses⁹ and electronic insurance certificates, for example, are becoming more practical, thanks to ongoing standardization efforts.

At the same time, digital credentials come with new privacy risks. The casual dissemination of authenticated personal information, including age, gender, address, contact information, and ID pictures (and their potential aggregation by third parties) may facilitate identity theft, online tracking, and targeted advertising. In this case, Bob need not, and should not, care about the details of Alice's credentials, as long as he can verify that they satisfy his policy. Bob also need not learn whether Alice has obtained insurance or is self-insuring. Can Alice provide such a proof of policy compliance without disclosing these documents and sensitive financial data?

Figure 1 shows sample credentials presented by Alice to meet Bob's rental policy; additional credentials may include sailing school accreditations, certificates of insurance, proof of solvency, etc. As illustrated in figure 1, identity providers and other trusted authorities issue credentials and other documents in the form of signed sets of claims in some standard format (such as X.509 certificates or JSON web tokens). In practice, credentials may be delivered to the digital wallet of the credentials' owner on a personal device such as a phone or laptop, which is able to identify the owner using, for example, biometric authentication, before unlocking their credentials.

Credentials usually include a signature from the issuer to protect their integrity. To present them to a third party, their owner may need to provide another signature to prove possession of the credentials and prevent their reuse. On the other hand, these credentials are not assumed to come with any custom privacy features, as would be the case with more advanced anonymous credentials.

For verifiers—in this example Bob, the boat owner—the policy to be satisfied may be expressed as a simple program or script, using a domain-specific policy language such as Rego or a subset of JavaScript. Figure 2 shows a sample policy enforcing Bob's requirements to rent his sailboat; the current date and session identifier bind the policy evaluation to Alice's request. As illustrated in figure 2, such policies may take as inputs some parameters such as a timestamp and a session ID. They may be created by the verifier and possibly endorsed by a regulator or a privacy watchdog. They should be simple enough to enable credential owners—in this example Alice—to review them and assess their privacy risks.

Some basic policies may just require proving possession of a single credential with a given property, such as "My passport is valid for more than six months," without disclosing its full contents. Bob's sailboat renting policy involves more thorough verifications spanning multiple credentials. For example, Bob must verify that the same name is used in the documents presented to satisfy the policy, that they are all currently valid, and that each of them is signed by an authority that he trusts. This verification may in turn involve checks on auxiliary statements (omitted in the figure) such as the accreditation of Alice's sailing school or the certificate chain that endorses the DMV (Department of Motor Vehicles) key used for signing her driver's license.

While policy details should be carefully written by the verifier and may add up to dozens of lines of code, Alice can review policies on a case-by-case basis, considering the actual credentials she needs to present as well as the sensitivity of the information this may disclose. This review occurs before Alice decides to proceed, and no information is disclosed unless the policy requirements are actually satisfied.

On the other hand, neither the credential owners nor the verifiers need to review the underlying CCP or ZKP technology, in as much as its fixed TCB can be independently reviewed, regardless of the actual policy and credentials involved.

A simple CCP-based protocol

This section describes a simple rental protocol between Alice and Bob using CCPs, then briefly outlines a similar protocol using ZKPs instead. The protocol involves three roles.

• Identity providers and other trusted authorities issue various credentials before the protocol starts; they are offline in the protocol and thus learn nothing about the use of their credentials.

• Alice acts as the prover. She holds her credentials in a digital wallet and controls their use; she presents some of these credentials upon legitimate requests from relying parties but wishes to protect her privacy. To this end, TEEs are created and controlled to produce proofs of their properties.

• Bob acts as the verifier. He guards access to resources (his boat), creates the corresponding authorization policies, and ensures compliance with these policies.

The details of Alice's wallet are unimportant here, assuming that it is trusted by Alice and its credential issuers, so the focus should be on the session between Alice and Bob to secure the boat rental. Figure 3 shows message flow for proving compliance to Bob's rental policy based on Alice's credentials without revealing their details. The proof of compliance is bound to the TLS connection and the current time.

As shown in figure 3, they first establish a secure communication channel, which allows Alice to authenticate Bob and provides a fresh session identifier for this run of the protocol. (This is important to make the proof of compliance specific to this run, as otherwise Bob might reuse this proof for some other purpose such as renting another boat from a competitor.) Alice can then review the details of Bob's boat and fetch his rental policy (see figure 2). Assuming she finds this policy acceptable, she creates a TEE specifically for evaluating the policy on her actual credentials and attesting its result. The TEE returns a CCP, then terminates. Alice forwards the CCP to Bob, who verifies its validity; then they can finalize their transaction. As an optional final step of the protocol, Bob may issue a signed rental agreement, which may be added to Alice's wallet and used to fulfill further paperwork requirements—for example, applying for a cruising license.

What's in the software TCB?

While conceptually simple, the TEE needs to run a substantial amount of trusted code for evaluating this kind of policy.

• As illustrated, the policy itself should be simple enough to be reviewed by all parties. This can be facilitated by using a high-level, domain-specific policy language.

• The rest of the code is complex but generic. It may include, for example, a basic language runtime for evaluating policy, libraries for cryptographic primitives and protocols, as well as code for parsing the formats for all supported credentials (including JSON for tokens and ASN.1 for X.509 certificates). This code can be tested, reviewed, or even formally verified once and for all.

Can ZKPs be used instead?

A proof of policy compliance in this protocol can also be implemented purely in software, using a general-purpose succinct ZKP scheme instead of a CCP, without affecting the rest of the protocol (except for the proof format). Unfortunately, the "complex but generic" code described here complicates this task. For example, correctly parsing the name field out of a JSON token without revealing its position and length already requires custom techniques. As another example, Cinderella describes how to prove, in zero-knowledge, possession of a valid certificate chain¹ (a generic subtask for the example rental policy that involves ASN.1 parsing and signature verifications). Support for real-world Web certificate chains involved a custom arithmetic circuit with 3 million equations, which would require one to two minutes to prove with more recent proof systems.³

These difficulties are largely caused by legacy credential formats. More efficient protocols are now available for ZKP-friendly formats, but correctly implementing such security-critical operations, as well as a language runtime for policies, still requires cutting-edge ZKP handcrafting.

TEE placement and privacy considerations

The TEE trusted with the credentials to evaluate policies and attest their results may either be located on the user's device (as shown in figure 3) or hosted in the cloud. Both approaches have their merits.

• When available, a personal TEE on a device protected with multifactor authentication mechanisms yields clear privacy guarantees and avoids the need for online services. It provides excellent credential protection for the device owner, but its TEE technology must be sufficiently trusted by the other parties (and their regulators).

Personal TEEs may also create additional privacy risks since verifiers may demand to identify a TEE's host in order to trust its attestations, such as to check if it has been revoked. (It is possible to use zero-knowledge to demonstrate that a TEE was not instantiated by a revoked host, but this approach is not widely supported.)

With proofs that are linkable in this way, relying parties can collude to track users across services and link their transactions to a durable identifier. While this risk seems acceptable for the example sailboat rental, there are many scenarios where anonymity or stronger pseudonymity is best for user privacy.

• Alternatively, using a CCP cloud service can provide uniform hardware protection (including physical datacenter protection) for a variety of client devices. A TEE hosted by a reputable cloud provider may be more trusted by verifiers and relying parties than a TEE on a personal device. It may also be convenient for policies that require online checks, such as interactive user sign-ins or lookups in certificate revocation lists. Regarding privacy, code reviews can be conducted to ensure that TEEs leak no information about client credentials besides the CCPs they produce. While it may still be possible to observe a client making a request to the CCP service and correlate it with a session between the client and the relying party, this risk can be mitigated at the transport level using, for example, Oblivious HTTP.

Conclusions

Proofs are powerful tools for integrity and privacy, enabling the verifier to delegate a computation and still verify its correct execution, and enabling the prover to keep the details of the computation private. Both CCP and ZKP can achieve soundness and zero-knowledge but with important differences. CCP relies on hardware trust assumptions, which yield high performance and additional confidentiality protection for the prover but may be unacceptable for some applications. CCP is also often easier to use, notably with existing code, whereas ZKP comes with a large prover overhead that may be unpractical for some applications.

As these technologies gain wider adoption, it is likely that applications will increasingly leverage either or both CCP and ZKP for their computations. For example, ZKPs may be produced inside TEEs for additional prover protection, while TEEs may feature ZKPs for additional attestation privacy—for example, to hide the hardware identity of the TEE that runs the computation and produces its attestation.⁸ From a wider perspective, individuals and governments are increasingly looking to safeguard data privacy, and we believe privacy-preserving proofs will help create a world where privacy is protected by default.

References

1. Delignat-Lavaud, A., Fournet, C., Kohlweiss, M., Parno, B. 2016. Cinderella: turning shabby X.509 certificates into elegant anonymous credentials with the magic of verifiable computation. In Proceedings of the IEEE Symposium on Security and Privacy, 235?254; https://ieeexplore.ieee.org/document/7546505.

2. Delignat-Lavaud, A., Fournet, C., Vaswani, K., Clebsch, S., Riechert, M., Costa, M., Russinovich, M. 2023. Why should I trust your code? Communications of the ACM 67 (1), 68?76; https://dl.acm.org/doi/10.1145/3624578.

3. Ernstberger, J., Chaliasos, S., Kadianakis, G., Steinhorst, S., Jovanovic, P., Gervais, A., Livshits, B., Orrù, M. 2023. zk-Bench: a toolset for comparative evaluation and performance benchmarking of SNARKs; https://eprint.iacr.org/2023/1503.pdf.

4. Fiat, A., Shamir, A. 1986. How to prove yourself: practical solutions to identification and signature problems. In Proceedings of Advances in Cryptology (CRYPTO), 186?194; https://dl.acm.org/doi/10.5555/36664.36676.

5. Goldreich, O. 2001. Foundations of Cryptography, Volume 1: Basic Tools. Cambridge University Press.

6. Goldwasser, S., Micali, S., Rackoff, C. 1985. The knowledge complexity of interactive proof-systems. In Proceedings of the 17th Annual ACM Symposium on Theory of Computing (STOC), 291?304; https://dl.acm.org/doi/10.1145/22145.22178.

7. High Assurance Cryptographic Library ? HACL* and EverCrypt Manual; https://hacl-star.github.io.

8. Intel. 2021. Intel Enhanced Privacy ID (EPID) Security Technology; https://www.intel.com/content/www/us/en/developer/articles/technical/intel-enhanced-privacy-id-epid-security-technology.html.

9. ISO. 2021. ISO/IEC 18013-5:2021 ? Personal identification ? ISO-compliant driving license; https://www.iso.org/standard/69084.html.

10. Kothapalli, A., Setty, S., Tzialla, I. 2022. Nova: recursive zero-knowledge arguments from folding schemes. In Proceedings of Advances in Cryptology, 42nd Annual International Cryptology Conference (CRYPTO), 359?388; https://dl.acm.org/doi/abs/10.1007/978-3-031-15985-5_13.

11. Ni, H., Delignat-Lavaud, A. Fournet, C., Ramananandro, T., Swamy, N. ASN1*: Provably correct, non-malleable parsing for ASN.1 DER. In Proceedings of the 12th ACM SIGPLAN International Conference on Certified Programs and Proofs, 275?289; https://dl.acm.org/doi/10.1145/3573105.3575684.

12. Parno, B., Howell, J., Gentry, C., Raykova, M. 2013. Pinocchio: nearly practical verifiable computation. In Proceedings of the IEEE Symposium on Security and Privacy, 238?252; https://ieeexplore.ieee.org/document/6547113.

13. Schuster, F., Costa, M., Fournet, C., Gkantsidis, C., Peinado, M., Mainar-Ruiz, G., Russinovich, M. 2015. VC3: trustworthy data analytics in the cloud using SGX. In Proceedings of the IEEE Symposium on Security and Privacy, 38?54; https://dl.acm.org/doi/10.1109/SP.2015.10.

14. Walfish, M., Blumberg, A. J. 2015. Verifying computations without reexecuting them: from theoretical possibility to near practicality. Communications of the ACM 58 (2), 74?84; https://dl.acm.org/doi/10.1145/2641562.

Mark Russinovich is CTO of Microsoft Azure, where he leads technical strategy and architecture for Microsoft's cloud computing platform.

Cédric Fournet is a senior principal research manager in Azure Research at Microsoft, Cambridge, UK. He is interested in security, privacy, cryptography, distributed systems, and formal verification.

Greg Zaverucha is a software engineer and researcher at Microsoft Research. He does research in applied cryptography, implements cryptographic primitives and systems, and helps product teams use cryptography securely.

Josh Benaloh is a senior cryptographer at Microsoft Research. His research focuses primarily on multiparty protocols, especially those supporting verifiable election technologies.

Brandon Murdoch is a director of engineering in the Microsoft Security division, London, UK, where he leads work on authorization and decentralized identity, with focus on privacy-preserving technologies.

Manuel Costa is a vice president and distinguished engineer at Microsoft, where he leads Azure Research on security and privacy. He is interested in advancing the state of the art in security and privacy, computer systems, and programming languages.

Originally published in Queue vol. 22, no. 4—
Comment on this article in the ACM Digital Library