zkTLS: Building A Verifiable and Private Web
Take a deep dive into zkTLS, one of crypto's newest privacy primitives.
.png)
In a digital-first world, privacy and security are omnipresent concerns. Among the emerging technologies designed to address these challenges, Zero-Knowledge Transport Layer Security, or zkTLS, has garnered a lot of buzz recently. As zkTLS is now part of the crypto zeitgeist, it's worth knowing what it is, how it works, and why it matters.
What is zkTLS?
As the name suggests, zkTLS is a hybrid protocol that uses zero knowledge with TLS, a combination that could revolutionize data transmission across the web. To understand zkTLS, it's necessary to break down its two main components.
- TLS: A key part of HTTPS, TLS provides encryption and authentication mechanisms to secure data transmission between a client and a server. In short, it's the foundation of secure communication on the internet.
- ZKPs: A cryptographic method that allows one party (prover) to convince another party (verifier) they know a piece of information without revealing it. In short, vital technology for privacy and performance in blockchains.
By blending these two technologies, zkTLS enables systems where data is provable and encrypted during transmission. This gives crypto access to a wide range of previously unusable data and, alongside things like confidential computing, introduces a new privacy primitive.
Note: The name "zkTLS" is a misnomer. Not all implementations use zk proofs, and the focus is often more on verifiability, not just privacy. Terms like web proofs or TLS attestations are likely more accurate.
How Does zkTLS Work?
How zkTLS works depends on its implementation, but one high-level example: it allows a user or a server to demonstrate that data fetched via a TLS-secured connection, like an API call to a bank’s server, is authentic. Best of all, it can do this without leaking any extra information.
zkTLS generates a zero-knowledge proof (e.g., zk-SNARK) confirming that data was fetched from a specific server (identified by its public key and domain) via a legitimate TLS session, without exposing the session key or plaintext data. For example, zkTLS can prove a user’s account has more than $10,000 without revealing the exact balance.
The flow goes like this:
1. The client and server perform a TLS handshake, establishing a secure session with encryption and server authentication.
2. zkTLS captures session details (e.g., encrypted data and server certificate) and processes them in a zk-SNARK circuit tailored to TLS constraints.
3. The circuit outputs a proof verifying the data’s authenticity and source, keeping sensitive details hidden (like the actual balance).
4. This proof is recorded on a blockchain for decentralized verification.
Different Types of zkTLS
MPC-based
The MPC version of zkTLS modifies the standard TLS handshake by introducing a network of nodes that collaboratively create a multi-party key instead of the browser generating its own. During the handshake, the website performs its part normally while the browser consults these nodes to generate a shared key through an MPC protocol, ensuring no single party knows the entire key.
This shared key is then used for encrypting and decrypting requests and responses, requiring cooperation between the browser and all nodes for every operation. When verifying a response to a third party, the browser provides attestations from all MPC nodes confirming their joint decryption of the data. This ensures no single node holds the full key, enhancing security, though it increases networking complexity due to node coordination.
TEE-based
The TEE implementation of zkTLS works by leveraging Trusted Execution Environments, tamper-proof, isolated areas within CPUs that can securely handle HTTPS requests. In this setup, sensitive data like authentication tokens are encrypted and sent to the service provider's TEE, which decrypts the data internally without exposing it to the provider or external systems.
The TEE then performs actions like logging in on behalf of the user and securely processes the response, providing cryptographic guarantees about the integrity of the request and response. This approach is efficient, with minimal overhead, but it does rely on TEE hardware and its manufacturer's security.
Proxy-based
The proxy-based zkTLS model uses HTTPS proxies as intermediaries to forward encrypted traffic between the browser and the website while observing the data exchange. During communication, the proxy provides attestations about the encrypted requests and responses, confirming they originated from the browser or the website.
The browser then generates a ZKP demonstrating that it can decrypt the received data without revealing the shared key, ensuring privacy. This approach is computationally efficient and minimizes networking overhead, but it depends on trusting the proxy not to misbehave.
Why zkTLS is a Game-Changer for Web3
Verifiability
Understanding the implications of zkTLS requires fully understanding the problems it solves. Let's back up a few steps and put this in a broader context.
Today, if a user opens a website, they use HTTPS, which means all the data is encrypted. If that website happens to be a bank account, all the data is protected. This end-to-end encryption ensures no one is in the middle or has access to sensitive details.
There's one problem: the interaction is deniable. If the bank sends encrypted data, and the user says they got it, the bank can dispute it. That's the nature of the encryption, which makes it hard/impossible to prove what the bank sent or confirm it with another party.
This limits the data that can be used onchain. And points to the bigger problem: TLS is unverifiable. The encryption scheme cannot generate proof that validates the data or its origin. And that, in essence, is what zkTLS does. It brings verifiability to the data transfer.
Privacy
The benefits of zkTLS also extend to data privacy. The ZK part comes in when a user wants to prove something to a third party. For example, they are employed for a rental application without revealing their entire employment history or other details.
It is possible to add verifiability to TLS without ZK but to prove something to another party, it is necessary to provide the decryption key for the data (e.g., a work contract). This is problematic because, with TLS or HTTPS, the same encryption key is also used for decryption.
This means that if a user is logged in to, say, a work email, the username and password could also be encrypted with the same key. Providing the decryption key proves that the data is correct, but the login details have also been compromised. This is the main reason ZK is needed. It enables selective disclosure.
Takeaways
- zkTLS proves information from any server and shields personal data, but it makes no claims about truth. It can confirm a work contract from an employer website, but cannot account for a case where the contract is invalid due to labor law violations. It does not assess the truthfulness or context of the data, it only vouches for its state and source.
- This might sound no better than pulling API data and putting it onchain, but there is a difference in terms of access. Regular APIs can easily be shut off, but with zkTLS, as long as users can access their data with an HTTPS connection, they cannot be shut down. This means almost any web2 data can be put onchain in a verifiable and permissionless manner.
- zkTLS is not fairy dust. Dumping a bunch of data onchain this way doesn't make it trustworthy. However, when combined with downstream filtering, reputation systems, cross-checks, and other safeguards, it is possible to prove more things to smart contracts. And this partial solution to the oracle problem improves blockchain data 100x.
Key Use Cases of zkTLS in Crypto
DeFi Lending
The classic example is in a DeFi lending scenario, borrowers might need to prove their creditworthiness by confirming they have a certain amount of money. With zkTLS, this can be verified, without exposing any other sensitive details. Real world example: 3Jane
Identity Verification
Confirming identity in a decentralized environment is hard. zkTLS provides a solution for users to prove identity-related claims (e.g., age, citizenship, or reviews in the case of a gig worker) using data from secure web sources without revealing sensitive details. Real world example: Nosh
Privacy-Preserving Oracles
Another promising direction, zkTLS privacy features enable oracles to provide verifiable data (e.g. price feeds) without exposing underlying data sources. This unlocks the ability to integrate sensitive, real-world data into decentralized applications. Real world example: TLS Notary
Verifiable Airdrops
Finally, zkTLS can be employed for better airdrops, confirming off-chain activity (e.g., social media engagement or shopping activity) from a TLS site, proving eligibility, and distributing tokens without exposing user data. Real world example: ZKON
Conclusion – zkTLS and the Road Ahead
zkTLS generates buzz because it makes it possible to layer Web3 economics onto Web2 activity in new and exciting ways. Of course, challenges like scalability, compatibility with varied web systems, and dependence on existing oracle networks do exist, but they don’t overshadow the promise.
The design space of zkTLS is vast. The upside is huge, and various flavors of this approach are already in production with many more being explored. By creating new methods of verifying and protecting data, zkTLS could fundamentally redefine how blockchains interact with the internet.
Interested in privacy-preserving dApps?
Learn more about:
