In November’s ZK Call, we discussed about the MPC-based zkTLS methods. Here is a overview of the talk for further discussion points.
Why we need the combination of TLS and ZK
The majority of the information is stored in servers and fetched over the TLS. The nature of the TLS, it is not exportable by default, especially on the TLS standards such as TLS 1.2 or 1.3. In other words, the TLS client cannot create a proof about the current TLS attestation is executed correctly.
MPC-based zkTLS methods (also known as DCTLS) are interactive protocols between server, prover and verifier to provide the privacy preserving TLS attestation to verifier. The definitions of role are as follows:
- Server S: The place the prover’s information data is stored such as age or solvency.
- Prover P: The data owner and also wants to prove a piece d of data to the verifier. The rest of data is never to the verifier with help of the ZK. The information d can be a boolean that holds relation information about data; e.g., prover’s age is above 18.
- Verifier V: The entity that the Prover needs to convince d. The Verifier is convinced of the integrity (means d coming from data that comes by the TLS session) without data by verifying the Prover’s proof.
DECO
One of the first privacy-privacy preserving TLS attestation protocol that uses MPC and ZKP in TLS 1.2 CBC-HMAC mode called DECO. At the end of the protocol, verifier V is fully convinced about the prover’s redacted TLS information.
DECO consists of three main phases:
- 3-Part Handshake
- Query
- Proving
3-Part Handshake
In this phase, verifier V and prover P behave like a single TLS client against server S. At the end of the handshake, verifier V and prover P get the additive shares of the TLS client MAC key, namely K_v and K_p where full MAC key is K_{MAC} = K_v + K_p. Note that, prover P also obtains K_{ENC}.
Query
Prover creates a query by passing a secret information (such as password) that can fetch the provers information but cannot prepare an authentication tag \tau because prover has no full MAC key. To do this, they call 2PC circuit that prover can generate \tau for the query Q, then encrypted it, Q’, and send to the server S. Server S gets back the encrpyed response R’. In here, again the prover descrypts and reads it but cannot verify the authenticity because of the same reason. Without verification, prover P, commits (Q’,R’) with its MAC share K_p to verifier.
Proving
After the verifier V receives the commitment, it releases the K_p, finally prover P can construct the full MAC key and validate the authenticity of the (Q’,R’). Then, creates a ZKP to reveal the d. For this, prover P creates two inputs:
- public input w = (Q’, R’, K_{MAC}, d)
- private input x = (Q, R, K_{ENC}, data)
The circuit verifies that the this Q’ is encrypted form of the Q and the d is the redacted form of data.
Normally, this operation is expensive since TLS 1.2 CBC-HMAC mode uses AES which is not ZK friendly due to its binary operations. This is why they applied just 3 blocks of the AES to show that encryption is correct.