Chainlink DECO, zkTLS oracle
- Introduction
- A (Very) Brief Overview of Interactive Zero-Knowledge Proofs (ZKPs)
- Provenance and Authenticity
- References
DECO is a zkTLS-oracle made by Chainlink for authenticating and verifying web data in a privacy-preserving manner.
Warning: this article is still in draft state and its content is still mainly taken from several articles by Chainlink. See:
[TOC]
Introduction
DECO enables a user to prove the authenticity of data and claims about it without revealing the data itself.
Authenticity, in this context, means that the data is obtained from a specific web server through the TLS protocol.
- Example
For example, a user can prove that she obtained her financial report from her bank’s website and that, according to this report, her account balance is above a particular amount.
However, she does not reveal any other information present in the report, such as her account number or exact balance.
- Integration
DECO requires no server side cooperation.
The TLS server does not have to be modified or even be aware that it is participating in the DECO protocol, greatly simplifying DECO’s path to adoption.
A (Very) Brief Overview of Interactive Zero-Knowledge Proofs (ZKPs)
DECO adds a ZKP layer to the TLS protocol to ensure privacy.
If you want an introduction to ZKP, you can read my article Main Concept Behind Zero-Knowledge Proof
In TLS, the identity of the server is verified using fresh challenges generated by the client for every session. This makes TLS, and in turn DECO, interactive protocols.
Therefore, DECO uses an interactive “commit-and-prove” form of ZKP called VOLE-based ZKP in order to benefit from its higher speed, lower memory footprint, and scalability compared to non-interactive ZKP.
Commitments
Reminder
-
Commitments are a cryptographic concept that can be viewed as a locked box. The prover committing to a variable x is analogous to putting x in a locked box and sending it to the verifier.
- The verifier cannot view the committed value but has the guarantee that the prover cannot change it once sent.
- Later, the prover can send the key to the verifier to open the commitment. We denote the commitment to x with [x][�].
Commit-and-prove ZKP protocol
Given commitments to the inputs of a logic gate (AND/XOR), a commit-and-prove ZKP protocol enables the prover and verifier to compute the commitment to the output.
This in turn enables the prover to prove the correct computation of a circuit consisting of these gates through the following steps:
(i) The prover commits to the inputs of the circuit.
(ii) Together the prover and the verifier compute the commitments to the outputs of the gates going through them in topological order.
(iii) The prover opens the commitments to the outputs of the circuit.
Additively homomorphic
The commitment scheme used in the DECO ZKP core is additively homomorphic.
This means that the commitment to the output of an XOR gate (addition modulo 2) can be computed locally without incurring any communication or computation cost. The cost of evaluating a circuit through the ZKP protocol is thus linear in the number of AND gates.
As a reminder, here the table for the XOR operation
| Input 1 | Input 2 | Addition view | Result X |
|---|---|---|---|
| 0 | 0 | (0 + 0) % 2 | 0 |
| 1 | 0 | (1 + 0) % 2 | 1 |
| 0 | 1 | (0 + 1) % 2 | 1 |
| 1 | 1 | (1 + 1) % 2 | 0 |
Provenance and Authenticity
Context
DECO involves three parties:
- The prover (Alice, “she”),
- the verifier (Bob, “he”),
- and the TLS server (Charlie, “it”).
In TLS, authentication of the server relies on secret challenges generated by the client (prover in DECO) for every new session.
This makes TLS an interactive protocol. Therefore, the verifier needs to be a part of the protocol execution to be able to verify the authenticity of data.
Solution
The solution is to put the verifier as a proxy between the prover and the server and recording the bytes communicated as part of the TLS protocol.
These bytes are later used as the “truth” known by both prover and verifier in the proofs of authenticity. Note that TLS ensures the privacy of data from any eavesdropper, in this case the verifier.
The server is oblivious (“not aware”) to its participation in the DECO protocol.
This requires the TLS protocol to be executed without any modification, and DECO thus follows steps in the TLS protocol precisely.
- First, the TLS session keys are generated by the prover.
- Then the keys are used to decrypt the TLS ciphertext.
TLS Key Agreement and Key Binding Proofs
At the beginning of the TLS protocol, the prover and server generate a TLS session key K using a key exchange protocol, e.g., Diffie–Hellman.
The verifier does not learn K (otherwise TLS wouldn’t be secure).
Use of invalid key K′
However, this creates a security problem
what if the prover later uses an invalid key K′ in the subsequent ZKP proofs?
This is possible because encryption algorithms in modern TLS are not committing, which means that a ciphertext can be decrypted in multiple ways. This may allow the prover to decrypt the ciphertext to something the server has never sent, causing a soundness violation.
The solution in DECO is to ask the prover to show a key binding proof to prove that the commitment K to the session key is generated correctly.
The goal of a key binding proof is for the prover to convince the verifier that a session key K is uniquely bound to the session recorded by the verifier.