In an era where data privacy and trustless verification are paramount, zkPass emerges as a groundbreaking oracle protocol that enables users to securely prove ownership of private internet data—without exposing the data itself. Built on zkTLS, a fusion of 3P-TLS and hybrid zero-knowledge (ZK) cryptography, zkPass redefines how personal information is shared and verified across decentralized applications.
Whether it's financial records, educational credentials, or identity documents, zkPass allows individuals to generate on-chain verifiable proofs from any HTTPS website—bypassing traditional OAuth APIs while preserving full confidentiality.
Core Architecture: Redefining Trust in Data Sharing
Traditional verification systems place users at risk by requiring them to hand over sensitive data to third parties. In contrast, zkPass flips this model: the prover (user) interacts directly with the data source and generates cryptographic proof for the verifier (service provider)—ensuring no raw data ever leaves the user’s device.
This paradigm shift introduces three key roles:
- P (Prover): The individual proving ownership of data.
- V (Verifier): The entity requesting proof (e.g., a lending platform).
- S (TLS Server): The trusted data source (e.g., government portal, bank).
The protocol leverages advanced cryptographic techniques including:
- 3P-TLS: A three-party TLS handshake enabling secure communication between user, node, and server.
- Secure Multi-Party Computation (MPC): Distributes encryption keys so no single party holds full access.
- Hybrid ZK Proofs: Combines interactive and non-interactive zero-knowledge protocols for efficiency and scalability.
How 3P-TLS and MPC Enable Privacy-First Communication
Phase 1: Three-Way Handshake
Unlike standard TLS, which only involves client and server, zkPass introduces a third participant—the zkPass node—to jointly establish session keys using Paillier homomorphic encryption. During the handshake:
- The pre-master secret is split between the user (P) and node (V).
- The server (S) retains the full key but cannot learn which user is connecting.
- Certificates and digital signatures ensure authenticity, preventing phishing or fake site attacks.
This design guarantees that even if the node is compromised, it cannot reconstruct the user’s encrypted data.
Phase 2: Key Derivation via MPC
After the handshake, P and V engage in MPC to derive two critical keys:
- enc_key: Used to decrypt application data.
- mac_key: Ensures data integrity via message authentication codes (HMAC-SHA256).
Crucially, V only receives part of the mac_key and none of the enc_key, making it impossible for the node to view or tamper with user data. Any modification to the response will fail MAC verification.
Phase 3: Secure Data Exchange & Proof Preparation
Standard TLS procedures handle data transmission. Then, P and V exchange parameters needed for the upcoming ZK proof generation. Optimizations such as silent Oblivious Transfer (OT), stacked Garbled Circuits (GC), and AES128 circuit reductions cut computation time by over 70% compared to naive implementations.
These enhancements make zkPass not only secure but also practical for real-world use.
Zero-Knowledge Proof Layer: Hybrid ZK Protocol
zkPass employs a two-stage ZK system combining Interactive ZK (IZK) and Non-Interactive ZK (NIZK) for optimal performance and privacy.
Interactive ZK (VOLE-ZK23)
Using Vector Oblivious Linear Evaluation (VOLE), zkPass constructs a "commit-and-prove" framework where:
- P commits to values derived from decrypted responses.
- V verifies linear relationships without seeing raw inputs.
Key constraints enforced in the circuit include:
Dec(enc_key, Q') = Q— Ensures request was properly encrypted.Q = Query(token)— Confirms use of valid session token (e.g., cookie).Dec(enc_key, R') = R— Validates correct decryption of server response.Verify(mac_key_pv, MAC, R) = 1— Proves response hasn’t been altered.b = Assert(R)— Enforces business logic (e.g., “age > 18”).
Optimizations like SoftSpoken reduce network overhead by 50%, while SIMD-like "multi-data signal input" enables reuse of VOLE parameters across repeated operations—dramatically improving throughput.
👉 Explore how blockchain platforms are integrating privacy-preserving proofs
Transition to NIZK with SNARKs
Once IZK verification succeeds, the node signs the result. The user then inserts this signed output into a Merkle tree managed by an SBT (Selective Blockchain Tree) smart contract.
To later prove validity publicly:
- The user submits a ZK-SNARK proving membership in the Merkle tree.
- The proof includes a signature from the node, ensuring authenticity.
- No details about the underlying template or full dataset are revealed.
This approach enables selective disclosure: users can prove specific claims (e.g., “I am over 18”) without revealing their actual birthdate or other attributes.
Selective Blockchain Trees (SBT): Structured Privacy
zkPass implements SBTs based on ERC998, a composable NFT standard. Two types of tokens are used:
- tSBT: Represents categories like identity, finance, or education.
- dSBT: Stores actual credentials (e.g., digital ID from a government site).
Each dSBT contains a claim tree:
- Leaves represent individual data points (e.g., age, nationality).
- Internal nodes store hashes of children.
- Root hash is stored on-chain; ZK proofs verify subtree correctness.
Users generate proofs for specific queries:
Example: Prove “age > 18” without revealing exact age.
Proofs are verified on-chain using lightweight functions—ensuring transparency without compromising privacy.
Security Model: Defense Against Malicious Actors
zkPass assumes semi-honest behavior by default but defends against active threats through:
Gateway Anonymization
A gateway layer masks network metadata, ensuring nodes cannot distinguish real users from auditors ("fishermen").
Fisherman Incentives
Randomly assigned tasks challenge nodes to process dummy requests. If a node behaves maliciously:
- It risks losing staked assets.
- The fisherman earns a reward.
This creates strong economic disincentives for cheating.
Automated Arbitration
A mediator caches communication logs and can replay VOLE parameters to audit disputes. Entire process is automated—no manual intervention required.
Frequently Asked Questions
Q: What kind of data can zkPass verify?
A: Any data accessible via HTTPS—legal IDs, bank statements, academic records, social profiles, medical history, and more.
Q: Does zkPass require special integration with websites?
A: No. It works with existing HTTPS sites without requiring API changes or backend modifications.
Q: Can verifiers see my private data?
A: No. Only zero-knowledge proofs are shared. Your raw data remains encrypted and local.
Q: How does zkPass prevent fake proofs?
A: Through cryptographic binding to TLS sessions, MAC verification, and node-signed Merkle inclusion proofs.
Q: Is zkPass decentralized?
A: Yes. Nodes operate in a permissionless network with slashing mechanisms and fisherman oversight.
Q: What blockchains support zkPass?
A: zkPass integrates with Ethereum-compatible chains and Layer 2 solutions via smart contracts.
👉 Learn how next-gen dApps are using zero-knowledge oracles for secure identity verification