zkMe zkTLS
What is zkTLS?
zkTLS (Zero Knowledge Transport Layer Security) is a privacy preserving protocol that transforms a standard HTTPS session into a zero knowledge attestable interaction. It breaks the traditional Web2 data enclosure model by allowing users to locally decrypt TLS traffic, extract only the fields they need, and generate a verifiable proof without exposing the full plaintext session.
By combining the TLS protocol with zero knowledge proofs, zkTLS enables a user to prove that they accessed a specific HTTPS endpoint and obtained a particular piece of structured data while keeping all other page content and personal information completely hidden. The resulting proof can be verified on chain or off chain, ensuring both the authenticity of the data source and minimal disclosure.
Why zkTLS Matters?
In today's digital world, much of our important information, such as financial status, citizenship, and academic credentials, exists on Web2 platforms. However, these platforms were not designed to interact with decentralized systems in a privacy preserving way, and users often lack real control over how their data is accessed or verified.
zkTLS bridges this gap by enabling trustless, verifiable, and privacy preserving extraction of Web2 data while maintaining full user autonomy. Users can locally decrypt their own TLS sessions, select only the fields they wish to disclose, and generate a proof that can be independently verified. This restores genuine ownership of both identity and data without requiring cooperation from the original platforms and without exposing unnecessary information.
zkTLS supports a wide range of use cases, including:
University enrollment or graduation status
Government issued residency or citizenship
Regulatory eligibility for token sales such as accredited investor checks
Credit score thresholds from financial platforms
In addition to identity and compliance scenarios, zkTLS can also function as a privacy preserving alternative to traditional financial data aggregators. It allows users to prove:
Bank account ownership and balance
Verified income streams and income level
Transaction history summaries such as salary inflows or recurring expenses
Identity and address confirmation from banking or utility portals
All of this is achieved without exposing raw data, without granting API keys, and without relying on centralized intermediaries. zkTLS empowers users with true control over their identity and personal data and aligns verification with the principles of data autonomy and user sovereignty.
Value Proposition of zkTLS
zkTLS delivers several core properties that define its privacy, performance, and integration advantages.
Confidentiality
Users prove sensitive facts without revealing actual data
Compatibility
Built on top of standard TLS (v1.2/v1.3), no backend modifications needed
Scalability
zk-SNARKs enable fast verification (~200ms typical)
Compliance
Enables privacy-preserving onboarding aligned with GDPR, HIPAA, etc.
Cross-Chain Ready
Proofs can be consumed across different chains.
How zkTLS Works
zkTLS relies on a combination of client side TLS session capture, structured data extraction, and zero knowledge proof generation. The process consists of the following steps.
Establishing a Secure Session via the Local zkTLS Module
The user connects to a target HTTPS website (e.g. creditkarma.com) through the Local zkTLS Module, which:
Records the TLS handshake, including the server’s certificate and session metadata
Captures encrypted segments of the server response without decrypting or modifying any content
The module operates entirely on the user’s device and does not transmit or store any raw data.
Proof Submission & Verification
The resulting proof is a short cryptographic object designed to support multiple verification flows:
Submitted on-chain, to trigger smart contract logic (e.g., issue a credential)
Verified off-chain, by a service provider or application
At no point does the verifier see the user’s browsing session or original data, only a valid cryptographic proof.
Technical Foundations of zkTLS
The diagram below outlines the core components of the zkTLS architecture and how data flows across layers.
zkTLS is built on a tightly integrated set of components that work together to guarantee privacy, integrity, authenticity, and verifiability.
These foundations include structured data extraction, TLS-layer cryptographic isolation, lightweight zero-knowledge proof circuits, and a decentralized attestor network.
The sections below break down each layer of the architecture in detail.
Provider Schema: Structured, Verifiable Data Extraction
To precisely define what users are proving, zkTLS uses a schema-based extraction system similar to JSON Schema, combined with modern selectors such as XPath, JSONPath, and regex.
A Provider Schema specifies:
the target HTTPS endpoint
how the response should be matched
what part of the response may be selectively disclosed
optional hashing (OPRF) for sensitive fields
Selectors follow a priority order (XPath → JSONPath → Regex), ensuring reliable extraction even in complex Web2 pages. This guarantees that only the intended data is disclosed, and no additional context can be injected by adversaries.
Provider Schema Structure
url
string
The target URL (must be HTTPS).
method
string
HTTP method (GET, POST, etc.).
responseMatches
object
Rules for matching the response, using regex or contains.
responseRedactions
object
(Optional) Selectors for redacting content, using XPath, jsonPath, or regex.
TLS-Level Security & Selective Disclosure
zkTLS leverages native properties of the TLS protocol to isolate and protect sensitive data regions.
TLS 1.3 KeyUpdate Mode
TLS 1.3 supports dynamic key rotation. zkTLS uses this mechanism to bracket the part of the response containing the target data: a new session key is created before the sensitive region, and another key update follows immediately afterward. Only the ciphertext under that specific key version is eligible for disclosure. This enables selective disclosure without exposing the rest of the session.
TLS 1.2 Compatibility Mode
Because TLS 1.2 does not support KeyUpdate, zkTLS instead uses a full zero-knowledge redaction proof verifying that the disclosed plaintext is a valid decryption of the redacted ciphertext and that no additional content is leaked. Supported cipher suites include AES-GCM and ChaCha20-Poly1305.
Zero-Knowledge Circuit Design
zkTLS adopts a minimalistic ZK circuit that focuses exclusively on verifying the correctness of selective decryption.
Rather than re-implementing TLS internally, the circuit works with two classes of information:
Public information that the verifier sees (redacted ciphertext fragment + TLS metadata)
Private information held only by the user (TLS session key material)
The circuit proves a single essential statement:
The disclosed plaintext is the only valid decryption of the corresponding ciphertext segment using the private session key.
This design keeps proving lightweight, auditable, and compatible with both browser-friendly and high-performance backends.
Circuit Overview Diagram
Attestor Network: Verification & Economic Security
Attestors act as independent verifiers, ensuring that claims originate from authentic TLS sessions.
Each attestor:
relays encrypted TLS traffic without accessing plaintext
validates ZK proofs and schema rules
signs claims once validation succeeds
The network is governed by on-chain staking and slashing:
nodes must stake to participate
malicious behavior results in penalties
all events are auditable
a threshold of signatures is required for final validity
This design prevents single-point compromise and mitigates user–attestor collusion.
Security & Threat Mitigation
zkTLS is designed to operate securely in adversarial environments. Protections include MITM resistance via TLS authentication, strict domain binding, replay resistance, schema-based extraction preventing data injection, multi-attestor consensus, and ephemeral session keys.
Security Matrix
MITM Attack
TLS is used to encrypt communication between the proxy and the Attestor, combined with certificate pinning.
Phishing Attack
The Attestor verifies the target host, preventing spoofing.
Replay Attack
A timestamp and unique ID are bound to the session to prevent reuse.
Collusion Attack
Multiple Attestor nodes and a slashing mechanism disincentivize collusion.
Injection Attack
The Provider Schema validates the location of the disclosed data.
DoS Attack
Rate limiting and service fees are implemented to deter denial-of-service attacks.
zkTLS by zkMe
Live, Private, Powerful
Proven in Production zkTLS is already live in real-world applications, powering regulatory compliance, token sales, and identity verification for education and finance.
No Data Provider Required Users extract proofs directly from any HTTPS site, no need for API keys, platform integrations, or third-party approvals.
Native to zkMe Identity Stack zkTLS is fully integrated into zkMe’s Self-Sovereign Identity system, enabling seamless, automated issuance of verifiable credentials from Web2 sources.
End-to-End User Privacy The entire flow, from data access to ZK proof generation, runs locally on the user’s device. No data is stored, shared, or exposed at any point.
Last updated