Overview

Overview

Beyond the zkFHE core technique, Primus already created cryptographic data verification solutions based on MPC-TLS techniques, including two variants, MPC-model and proxy-model, to attest any web data from any Internet sources, and enable sharing the data value with zero-knowledge proofs.

The objective of these verifiable solutions is to overcome the challenges of data silos, expand smart contract capabilities, and facilitate secure monetization of personal data within privacy-preserving data flows.

Primus' attestor network is maintained by cryptographic attestors, which either runs MPC-model or proxy-model denpending on the application choices. Attestors are fiduciary entities that verify data authenticity for end users in light of diverse data sources.

To attest any web data from an Internet data source, a user operates on Primus-enabled clients, e.g., the PADO extension, or a dApp integrated with Primus' data verification SDKs. Note the verified data, a.k.a, attestation, is generated by the client in an interactive way, by cryptographically communicating with attestors. Also for applications that want to use the verified data, there could be additional computations performed on the users' private data, e.g., a zero-knowledge proof of an inequality calculation that proves the person with a specific date of birth is over 18.

Technical Insights of MPC-model

Primus Labs created a cutting-edge lightweight cryptographic data verification protocol together with cryptographers, to authenticate web data with MPC and IZK techniques. The details of the protocols can be found here.

In general, Primus uses two cryptographic techniques to combine pieces together.

• MPC-TLS: TLS stands for transport layer security, which is a security protocol that provides privacy and data integrity for Internet communications. Any client can communicate with an Internet server via TLS protocol to achieve conversation security. A typical example is that, when you explore the website, you usually find there is a "lock" icon and a "HTTPs" header in the website URL, and that means the ongoing access is securely protected by TLS protocol.

Concisely, MPC-TLS is a specific MPC protocol that is executed between the TLS client (prover) and the attestor (verifier) to verify any data from a TLS channel. It includes peforming cryptographic computations during the handshake and query execution phases in a complete TLS conversation.

The client and attestor together simulate an original TLS client, i.e., an attestor will work together with the TLS client to:

• establish the TLS channel to simulate handshake operations in the TLS protocol. This involves the computation of premaster secret, session key, test messages, etc.
• query execution in the TLS channel. This involves the generation of encrypted requests and the decryption of the server response.

Note all the above TLS actions shall be executed in two-party computation (2PC) protocols between the client and the attestor. The design of MPC-TLS protocols relies on a couple of cryptographic primitives, including garbled circuits (GC), oblivious transfer (OT), interactive zero-knowledge proofs(IZK), etc.

• IZK: Interactive zero-knowledge proof is a type of zero-knowledge proof, where the prover and verifier interactively communicate with each other. Within the MPC-TLS protocol, an IZK protocol is equipped between the attestor (verifier) and the TLS client (prover) in the query execution phase, which will output the verifier's result, i.e., an acceptance or a rejection w.r.t. the prover's statement. IZK protocols possess the benefits that succinct NIZKs (zk-STARKs/zk-SNARKs) do not exhibit, e.g., high scalability to very large statements, cheap computation, avoidance of trusted setup, and minimal use of memory.

The following figure describes a general workflow that how Primus' MPC-model works.

1. The user operates on the client, communicating with a data source server to request his personal data from the server's APIs. Normally, the communications and message exchanges are secured within the TLS layer. To simulate all communications at the TLS layer when engaged with an attestor as a witness, MPC-TLS is applied throughout the whole process. the attestor and the client jointly play the role of a normal client in the original two-party handshake sub-protocol of the TLS protocol. This means, the attestor and the client participate together through a series of two-party secure multi-party computations (2PC) to establish a secure channel with the server and negotiate a session key for later conversation. Among them, the session key will be "secretly" split into two halves, with the attestor and the client each holding one half of it. In the view of the server, it still executes the original two-party handshake protocol, so the server will still get the complete session key. Once the TLS secure channel is established, the exchanged messages, i.e., the requests and responses, between the client and the server are encrypted with the session key. Applied by the MPC-TLS technique, this process also requires the attestor to participate in coordination, because the client and the attestor each hold half of the session key. In other words, whenever the client needs to encrypt its request with the session key and send it to the server, the attestor must assist in the completion of the encryption by a two-party computation, i.e., generate the request ciphertext and send it to the server. Similarly, whenever receiving an encrypted response, it needs to be decrypted from another 2PC computation. At this time, the attestor's half of the session key is also required to complete the two-party decryption.

2. In order to ensure the authenticity of the response, the attestor will require the client to submit the encrypted response as a cryptographic commitment, and then send its key slice to the client to recover the complete session key and decrypt the response message by the client. Then, the client will execute an interactive zero-knowledge proof protocol with the attestor, to confirm the consistency of the decrypted data with its committed and encrypted version. In some use cases, the client's data will be directly used by an application. On the other hand, the IZK manuscript could contain an additional statement proving the satisfiability of the application logic. After the IZK execution, the attestor will be convinced and generate a signature to confirm the fact. Note the attestor never knows any bit of the raw data in the whole process. Thus the final verified data is essentially the attestor's signature on the result of the IZK execution, which includes the information about the data source and the optional application logic's satisfiability. The application will accept and process the verified data after successfully verifying the signature of the attestor.

Technical Insights of Proxy-model

Proxy-model, also called "Proxy-TLS" or "zk-TLS", on the other hand, is another cryptographic approach using zero-knowledge proofs to verify web data without sacrificing confidentiality.

Compared to MPC-model, proxy-model offers an alternative approach where the attestor serves as a proxy between the client and the server. eventually the client (prover) runs a ZK protocol with the attestor (verifier) for the proving the authenticity in a zero-knowledge way towards the TLS session data. Note in the MPC-TLS, the attestor is acutally an external entity without sending or receiving any TLS traffics.

A typical proxy-model workflow is like this:

1. a TLS request to access the website, along with its response, passes through an attestor.

2. The Attestor can observe only the encrypted data, without any access to the plaintext. It tracks the encrypted packet exchanges between the cleint and the server.

3. Once the reponse is received by the client, he runs a zero-knowledge proof protocol and selectively reveal part of the response data with the attestor, to proving that the client has certain decryption key to decrypt the encrypted data. Note the client shall follows the data minimization principles in the revealing, e.g., a selective disclosure. For example, you only proves your birth date without revealing other identity information like nationality and gender in your e-passport. In that case, zkTLS uses zk proofs to extract only parts of the data fields that actually contain the requied information.

4. In return, the Attestor issues a signature, validating that the client holds the correct response to a specific request, and that response is indeed from the correct server. This signature acts as proof and can be presented to third parties as needed for verification.

On the other hand, to improve the performance towards both verified data size and communication time, Primus uses IZK techniques to replace NIZK protocol in the implemented proxy-model.

This alternative protocol offers a unique balance between performance and security. It achieves high efficiency by reducing cryptographic operations after the initial handshake. However, it relies on specific network conditions (e.g., consistent connectivity between the proxy and server during the session) and, as a result, is only resilient against less sophisticated network adversaries. Therefore, developers and applications are suggested to pick different techniques through the evaluation of scenarios and comprehensive consideration of performance and security.