A Technical Overview of zkPass Protocol
(https://miro.medium.com/v2/resize:fit:1400/format:webp/1*YjTpChAmp-d_L9zWGbi7XQ.png)
zkPass, a privacy-preserving protocol for private data verification. It is built on the foundation of Multi-Party Computation (MPC), Zero-Knowledge Proofs (ZKP), and three-party Transport Layer Security (3P-TLS). zkPass provides TransGate, which enables users to selectively and privately validate their data on any HTTPS website to the web3 world.
It can cover various data types such as legal identity, financial records, healthcare information, social interactions, work experience, education and skill certifications, etc. All these types of verifications can be done securely and privately without the need to disclose or upload any sensitive personal data to third parties.
zkPass can be readily incorporated into multiple application scenarios, including composable decentralized identity passes, DeFi lending protocols relying on off-chain credit, privacy-ensured healthcare data marketplaces, and dating apps featuring verifiable zkSBTs, etc. Wherever there is a need for trust and privacy, zkPass can provide a solution.
Users control the private Data without leaking sensitive personal information, avoiding unpredictable potential criminal convictions and offenses.
This post gives an overview of zkPass Protocol’s overall architecture and how it works.
Symbols and Definitions
P: Prover (Individuals)
V: Verifier (Business)
S: TLS server
Q: P-initiated query
R: Data replied by S
enc_key: The key of the encrypted data in TLS
mac_key: The MAC key in TLS
t: Digest
Overview Solutions
In the traditional data validation and confirmation process, the Prover submits their information to the Verifier. The Verifier retrieves this data and performs authentication checks in collaboration with the DataSource. Thus, the Verifier serves merely as an intermediary or broker in this model.
Each party faces unique challenges in this scenario: for the Prover, there’s a risk of disclosing excessive personal information; for the DataSource, while it’s a trusted data provider, it’s incapable of offering personalized verification services; and for the Verifier, they’re privy to all the customers’ private data, gaining total access, which presents significant potential risks of data leakage.
We propose a new approach that repositions these three entities, positioning the Prover between the Verifier and the DataSource. Rather than the traditional method, the Prover uses their access token to directly locate and retrieve their data from the DataSource, subsequently generating a Zero-Knowledge Proof (ZKP) for the Verifier to check. This process ensures the Verifier remains unaware of the Prover’s personal information.
In order to implement this structure, we incorporate 3P-TLS, MPC, and IZK technologies.
3P-TLS
Transport Layer Security (TLS) is the secure protocol for HTTPS, supported by almost all Data-Sources. It is a two-party protocol designed for a client/server structure. We have built the 3P-TLS protocol based on the elliptic curve DH protocol and combined it with MPC and Oblivious Transfer (OT) to prevent cheating.
MPC
One challenge we face is that the Prover may forge proof information provided by the DataSource to deceive the Verifier. The solution to this problem is through MPC, where both the Prover and the Verifier hold half of a session MAC key, which is a data integrity key used to maintain data integrity. Since the Prover cannot forge or tamper with information responses provided by the DataSource, it cannot deceive the Verifier. MPC can also prevent the Verifier from knowing any private information about the Prover. During the MPC handshake, there is no encryption key (data confidentiality key) for the Verifier, so it cannot decrypt any data and therefore does not know any private information about the Prover.
IZK
After obtaining information from the DataSource, the Prover needs to prove certain statements of the response in a secure and private manner. We use Zero-Knowledge Proofs (ZKP) to achieve this goal. More specifically, we use interactive commit and prove zero-knowledge proofs (ICP-ZKP) to deal with the large scale of the circuit. The Prover gives the commitment as c = commit(m, r), where m is the message and r is the randomness. Then the Verifier checks that commit(m, r) = c. The commitment does not reveal any information about m, and the Prover can’t find different m’ and r’ (and m’’ and r’’) such that commit(m’, r’) = c and commit(m’’, r’’) = c. During the protocol, the Prover needs to commit its private witness, then prove the input wires and the computation of each gate one by one, and continue to commit the output wires until the final one.
Future Direction
The fields of MPC and ZK related technologies are constantly evolving, with significant advancements being made each year. To ensure the continuous optimization of the zkPass protocol, we are actively staying abreast of the latest technologies. Here are some noteworthy references that we are considering: [FNO14], [NNOB11], [HK20], [HYDK22], [ADST21], [BDOZ10], [FKL+21], [DIO20], [JKO13], [GAZ+21].
OT: Oblivious Transfer
Traditional OT protocols like IKNP/KOS15, which we currently use, require a security parameter (𝑘) bits of communication for each OT. However, we propose building a new maliciously secure OT extension based on VOLE that only needs (log 𝑘) bits. For any (𝑛), this improvement comes at the expense of requiring (2𝑛) times the computation.
GC: Garbled Circuits
Existing GC evaluation methods such as [ZRE14] and [KS08] evaluate GC functions gate-by-gate using encrypted truth tables. The GC evaluator decrypts the corresponding output label based on input labels. However, interactive protocols offer more sophisticated techniques. For example, we can expose a (masked) private value to a party, allowing them to perform local computation and feed the resulting cleartext value back into the MPC.
IZK (Interactive Zero-Knowledge) Protocols
VOLE-based IZK ([WYKW20]/[YSWW21]) suffers from high communication overhead, often linear to the circuit size. We are constructing new ZK protocols with communication sublinear to the circuit size while maintaining a similar level of computational efficiency.
zkPass Official Links:
Website: https://zkpass.org/
Twitter: https://twitter.com/zkPass
Discord: https://discord.gg/zkpass
Medium: https://medium.com/zkPass
GitHub: https://github.com/zkPassOfficial