Opacity Network: Trust but Verify

Here’s a question to think about: when logging into your bank account, how do you know that what is appearing on your screen hasn’t been compromised? The complex underpinnings of how we access, transact, and engage on the internet are easy to forget about when they happen seamlessly in the background. But offering traditional web2 services augmented by web3 functionality requires solving network communication issues—the protocols we forget about that run in the background. 

Over 95% of internet traffic leverages the HTTPS protocol–secured by Transport Layer Security or TLS–to cryptographically ensure that communications between a client and server cannot be tampered with or snooped on. TLS is generalizable and used to secure communications protocols like SMTP (email), FTP (file transfers), and VOIP (real-time audio).

Designed for secure point-to-point communications between exactly two counterparties, TLS loses its attractive security properties when third parties are introduced. For example, third parties have a hard time verifying messages secured by TLS because both counterparties share the symmetric key and can unilaterally falsify content (more on this below). To convince a third party that a TLS transcript is correct, therefore, involves ensuring that it was not modified to fit some predetermined criteria.

If third parties could verify TLS-encrypted messages—through zkTLS solutions—opportunities would arise for open networks and new methods of trust authentication. Crucially, this could occur  without the historical reliance on and power vested in dominant web2 corporations. Business models based on hoarding private user data and aggregating proprietary social or reputation graphs would be disintermediated. Instead, a new class of business models would use cross-platform composability to enable new forms of collaboration at global scale, fundamentally disrupting the balance of powers in industries like online payments, influencer marketing, and identity verification in favor of end-users (and at the expense of centralized platforms). As on-chain ecosystems enter the mainstream, zkTLS will unlock previously unimaginable flexibility and optionality.

Perhaps most importantly, we believe that zkTLS will empower users to regain ownership of their own data, generate and transfer their own authentications for a fraction of the price, and allow companies to build upon previously inaccessible networks. The best part: this will be done without the need for an API or any buy-in from the companies themselves. zkTLS is a clear solution that disintermediates walled gardens and embodies the ownership of the web3 movement.

Given the scale of value creation by social media giants alone—not to mention gig economy apps and tech companies in health care—on top of private social/reputation graphs over the past decade, we believe such a scenario could drive hundreds of billions of value transfer to new, open networks. 

Recent advancements in cryptography and secure computation have made third-party verification of TLS-encrypted messages a possibility in the near-term, though many challenges remain. This is the heart of the issue that cryptographers at Opacity, Clique, Reclaim, and other TLS projects are working on. Let’s take a look at the opportunities, structures, and possibilities of the leading on-chain TLS projects.

When communicating with a server over the internet, it is imperative that a user can trust the validity of queries from the server. Clients use the HTTP protocol to fetch resources such as HTML documents from the server and reconstruct them on screen. SSL, or Secure Socket Layer, is an encryption-based Internet security protocol and the predecessor to modern TLS encryption used today. When a website implements SSL/TLS, it has HTTPS in the URL, which we are often advised to look for, rather than just HTTP. 

Here’s a good mental model for how SSL/TLS works. The server has a private value and the client has a private value. The client and server use these private values to arrive at a common shared secret used to derive a symmetric key that both the client and server possess. With this symmetric key, both the client and server can encrypt and decrypt each other’s messages to the exclusion of anyone else. [1] 

This setup, however, is susceptible to a man-in-the-middle attack, where a malicious third party  intercepts packets between the client and server, impersonates each party, and can fabricate messages that look legitimate. [2] To overcome this flaw, Netscape implemented the Certificate of Authority in 1999, where the public key of the server is signed by a Certificate authority—a handful of predetermined actors who validate the identity of entities, such as websites. Now, before engaging with the server to create a shared secret, the client requests the server’s certificate signature to ensure they are communicating with the right entity. 

When convincing a third party of a valid transcript, however, things get more tricky. The challenge is that since both parties have the same secret key, the user is capable of fabricating a transcript and signing the server’s responses as well, creating the appearance of a valid claim to a third party. In order to trust the provenance of a claim, then, we must complicate the normal network request.

Symmetric keys are useful for a user and server to verify each other’s claims, but because the user possesses the same key as the server, an entire transcript can be forged by the user, allowing the user to claim anything they choose. There are a few different current and proposed solutions in the space, elaborated below.

Using a trusted execution environment: Clique, a network that closed its recent $8m Series A, focuses on building out a trusted execution environment (TEE) network for blockchain networks as a whole, but one of the major offerings is a zkTLS solution that utilizes TEE. 

A TEE is a secure area in the main processor that is entirely encrypted and cannot be directly opened by even its owner. Owners interact with the TEE through designated and secure interfaces that allow the running of secure authorized applications called trusted applications. The TEE then returns a result and a signature attesting that the result comes from a particular program. Theoretically, this makes the system tamper-proof, even against those running TEEs in the network. 

However, as Dr. Andrew Miller at University of Illinois has been demonstrating for years by breaking TEEs (primarily Intel SGX), they aren’t a perfect solution. Any large-scale solution relying solely on TEEs has to contend with this challenge, especially when involved with smart contracts in more high-stakes situations, like KYC (Know Your Customer) regulation. 

Using a proxy witness: Another possible solution is to use a proxy witness that acts as a middleman between the client and server and attests to the accuracy of the transcript. The Reclaim Protocol, whose white paper was published late last year, is the most popular example of this strategy.

A trivial solution is to reveal to a third party, called the attestor, the user’s TLS private key. This allows the attestor to decrypt the encrypted request, check the correctness of the request, the correctness of the corresponding response, and attest if deemed correct. The challenge, however, is that this approach also reveals private information such as authentication tokens and cookies to the attestor, which gives the attestor login access to the user’s account.

The Reclaim Protocol solves this using a three-part construction that involves a key-upgrade mechanism. With only one attestor, however, the collusion problem once again rears its ugly head. If the user and attestor collude, then anything can be signed. To overcome this, Reclaim includes a subset selection of validators to help randomize and prevent this. However, since the attestor in the Reclaim protocol is responsible for conducting parts of the TLS handshake, their IP address is known by the server. Therefore, it is possible that servers could block IP addresses associated with attestors at scale, reducing the viability of such a system.

Using multi-party computation (MPC): TLSNotary and Opacity

In MPC schemes, two or more parties jointly compute a function over their inputs while keeping the inputs private. The parties learn the result of the function at the end, but none of the participants learns anything about the other’s inputs. In the case of TLS, an MPC node and the client would jointly make the TLS request and generate the transcript such that no one knows the shared secret key until after the session is finalized. Crucially, this approach is undetectable by the target server, which, unlike the Reclaim Protocol, is not being bombarded with requests in a short timespan but only has to respond to one. It is indistinguishable from the client logging in by themselves.

A few challenges arise from the MPC-TLS approach. The Shamir Secret Sharing MPC (SSS-MPC) scheme is very effective in scaling the number of parties that are conducting the computation. Since all parties must collude to reveal the shared secret, the more parties conducting the computation, the harder it is to collude—and the greater our security guarantees can be. SSS-MPC is commonly used in MPC wallets, like those in the Lit Protocol.

SSS-MPC, however, is not a good solution for the zkTLS case because of the type of computation required for TLS. The shared secret is the result of an ECDH (Elliptic Curve Diffie-Hellman) key exchange. To hash in SSS-MPC without any party being able to reconstruct the input or output is challenging because SSS-MPC is fundamentally an algebraic scheme. To make them harder to break, however, the hash functions used in TLS are not algebraic in nature and rely on binary operations (like XOR). This discrepancy creates a prohibitively high communication overhead that scales factorially as new parties are added.

To get around this, Opacity uses garbled circuits and oblivious transfer (OT) schemes. Unlike arithmetic circuits, garbled circuits are boolean in nature and consist of gates (like AND, OR, NOT) that perform binary operations, making them much more efficient for hashing. OT is a cryptographic technique that allows one party (the sender) to send information to another party (the receiver) in such a way that the sender does not learn which specific piece of information the receiver obtained, and the receiver cannot obtain more information than they are entitled to. By using an OT scheme, parties can select and compute on data inputs without revealing which inputs they are interested in, maintaining the privacy of their choices and inputs throughout computation. For garbled circuits, OT can be used to securely transmit keys for the input wires without revealing which keys were chosen. Garbled circuits and OT schemes, however, scale poorly beyond two parties—many of the optimizations developed for two-party garbled circuit/OT computation are unavailable for MPC with more parties.

TLSNotary is the current MPC TLS solution. The scheme works as follows: the user, called the prover, and another party, called a notary, engage in an MPC together. The output is then signed by the notary, making the data portable. The user can take the signed data and disclose parts to any application-specific verifier. The challenge here is that the notary must be trusted. If the notary and the prover collude in MPC, they can reveal the shared secret key and fabricate any transcript between the user and the server. While it is possible to have the user generate multiple proofs from many notaries before trusting the result, known as proof by committee, such a system would only work if the user cannot change the value between proofs. We can use the bank example to illustrate this further. If we have a committee of five nodes, all of whom have to agree for the server transcript to be considered valid, and a recurring debit hits the account between the third and fourth nodes conducting the MPC, then the last two nodes will disagree with the first three and may be slashed even though they conducted the protocol correctly. An easy solution might be to have all of the nodes conduct the MPC at once, but most servers will flag this as fraudulent behavior since it looks like multiple login attempts to the same account, all at the same time. For a truly general zkTLS solution, proof by committee doesn’t work, since price data (a stock price for example) is changing too quickly to allow for multiple parties to conduct the MPC and determine a value without significant margin.

Opacity Network:

Opacity builds from the existing TLSNotary framework with added safeguards and provisions to reduce the trust assumptions inherent in the protocol. It does this by layering multiple security considerations that disincentivize byzantine behavior and collusion. These include an on-chain verification of a web2 account ID, a commit and reveal scheme, a random sampling of the MPC-network, an on-chain verifiable log of attempts, and a whistleblowing process.

Given that account IDs act as the primary identifiers in a web2 company’s database, it is standard practice never to change them. This enables a proof by committee to prove ownership of a web2 account, and Opacity’s framework expects users to generate ten identical proofs by different nodes in order to claim a web2 account. Because this account is now mapped to a unique wallet address, a user cannot try different wallets until they find a node willing to collude. This scheme doesn’t work for public data not associated with any account such as a weather feed or public stock price. In these cases, oracles can be limited to a trusted subset or required to put up stake, and the protocol can be engineered to be much stricter with the log of attempts (discussed below).

The commit and reveal scheme to further secure against collusion where a user cryptographically commits to a value before a notary node is selected. If a user claims to have $1 million in a bank account, they would have to commit to the $1m before a node is chosen. Combined with an on-chain record of a user’s attempts to generate a signed transcript, Opacity further disincentivizes users from trying the process repeatedly before finding a node willing to collude. For example, even if a user could find a node to collude with on the third attempt, a smart contract reading the signed transcript will still be able to read the on-chain log and see the previously failed attempts, raising red flags.

Additionally, Opacity nodes are required to run their software within Intel SGX (a TEE). Assuming the TEE is not broken, this alone makes collusion impossible. Unlike Clique, we note Opacity’s specific solution as a layering of security considerations beyond TEEs. The plan is working closely with the Eigenlayer team to use Eigenlayer’s AVS (actively validated service) whereby nodes will be required to restake 32 stETH and are slashed for improper behavior. And because Eigenlayer uses stETH for its restaking, slashing and redistribution of stake takes place immediately rather than waiting until a withdrawal cooldown period is completed. 

While we note it’s possible that the breaking of the TEE would allow a node to collude in MPC, Opacity’s team is currently focusing on implementing a whistleblowing process whereby any user that can submit proof of a notary acting improperly will receive part of the slashed stake (more on that to come).

The ability to prove TLS transcripts onchain will unlock entirely new functionality as users will have control over their own data without needing permission from large corporations. While there is work to be done, zkTLS companies promise to enable novel use cases that shift power towards the users. And Opacity's thoughtful method of layering security considerations while using MPC is a novel approach that is already being used to drive value across industries.

1. The process by which a user and server obtain symmetrical keys is a Diffie-Hellman key exchange to find a shared point on an elliptical curve. The x-coordinate of this shared secret is then HMAC’d (hash-based message authentication code) by both the client and the server to derive a symmetric key. Since both the client and the server use the SAME set of the symmetric keys, they can now both encrypt/decrypt the transcript. 

2. In a man-in-the-middle attack, the malicious party performs individual Diffie-Hellman key exchanges with the client and the server while pretending to be the other party, so that it alone can fabricate messages claiming to be the server to the client and vice versa.

3. Opacity is also adding moving to add support for vector oblivious linear evaluation (VOLE), which allows for efficiently constructing a 1 of N oblivious transfer (OT) vs 1 of 2, thereby reducing network overhead by a factor of one to two orders of magnitude.