Overview

Beyond the zkFHE core technique, PADO already created a cryptographic attestation solution based on MPC-TLS and IZK techniques, to attest any web data from any Internet data sources, and enable sharing the data value with zero-knowledge proofs. The objective of the solution is to overcome the challenges of data silos, expand smart contract capabilities, and facilitate secure monetization of personal data within privacy-preserving data flows.

PADO's MPC-TLS network is maintained by cryptographic attestors. Attestors are fiduciary entities that verify data authenticity for end users in light of diverse data sources.

To attest the personal data from an Internet data source, a user operates on PADO-enabled clients, e.g., the PADO extension, or the dApps which leverage PADO's cryptography SDKs. Note the attestations are generated in an interactive way, by cryptographically communicating with attestors from the MPC-TLS network. Also for applications that want to use attestations, 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. In some situations, the computation should be performed on a third-party evaluator that is beyond the user's device, either because of the limited computational capacities or due to the privacy concern on the application inputs. Such computations are called outsourced computing, which uses (fully) homomorphic encryptions to perform specific computations on encrypted inputs as mentioned in PADO's main framework.

The attestations are shared with attestation registries like Verax, EAS and BAS. Attestation registries are attestation infrastructures, that allow to creation of arbitrary attestation schemas and support users to generate and share on-chain/off-chain attestations with other on-chain entities. An attestation registry is essentially a group of smart contracts that are deployed on a blockchain like Ethereum and its layer2 chains. Non-EVM blockchains are also adapted to attestation registry if they support the programmability of smart contracts.

Technical Insights of MPC-TLS

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

In general, PADO uses two cryptographic techniques to combine everything 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 to simulate an original TLS client, i.e., an attestor will work together with the TLS client to:

  • establish the TLS channel to simulate a handshake sub-protocol 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-related 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), 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 PADO's MPC-TLS technique brings the reliable value of user's data to Web3 in a compliant and trustless way. Note the optional evaluator is the node executing the out-sourced computation with the zkFHE technique to process with additional computation logic.

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 normal communications at the TLS layer when engaged with a third party (attestor) as a witness, MPC-TLS is applied throughout the whole process. In general, the attestor and the client jointly play the role of a normal client in the original two-party handshake sub-protocol in 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 on the other side, 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 blindly 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 attestation is essentially the attestor's signature on the result of the IZK execution, which includes the information about the data source and the possible application logic's satisfiability. The application verifier will accept and process the attestation after successfully verifying the signature of the attestor network.

3. In some scenarios, the data will be first received and confirmed with the authenticity, and then be used by a Web3 dApp through zkFHE computation. To adapt to that case, the client will first generate a Pederson commitment after the decryption, and then prove the consistency in the IZK execution with the attestor. The attestor blindly generates the signature on a succeeded verification. Then if the client is unable to process the data computation, either because of the limited computational power or the privacy issue of the application inputs, the client could initiate an outsourced computing task with an evaluator. This is where zkFHE applies. Once the zkFHE computation completes, the verifier can verify the validity of both data authenticity from the attestor's signature, plus the correctness of the result.