​
MPC-TLS (Multi-Party Computation over Transport Layer Security)

Verity employs the MPC-TLS primitive to generate authenticity and integrity proofs for TLS-enabled HTTP requests (i.e., HTTPS). This ensures that data sourced from Web2 services can be cryptographically verified as authentic and untampered.

​
How MPC-TLS Works

In standard TLS communication, a handshake establishes a secure connection between a client and a server, using cryptographic keys to encrypt and authenticate the session. MPC-TLS modifies this process by incorporating a third-party Notary into the session:

  1. Handshake Inclusion: During the handshake, the Notary receives encrypted data packets from both the Prover (client) and the Source (server).
  2. Authenticity Checks: The Notary independently validates the handshake by verifying digital signatures, encryption parameters, and session metadata without accessing raw session data.
  3. Proof Generation: The Notary co-signs the handshake and creates a proof of authenticity and integrity for the session. This proof includes verifiable information about the session, such as the source domain and cryptographic parameters, without exposing private data.

TLSNotary Whitepaper explains the foundations of MPC-TLS and its use cases.

​
Applications

Examples of TLS-enabled requests secured by MPC-TLS include:

  1. API calls to Web2 services, such as government or financial data platforms.
  2. Web page requests retrieving sensitive information (e.g., viewing banking data via HTTPS).

​
Verity’s Adoption

Verity extends the open-source TLSNotary Protocol with enhancements:

  1. Server-reactive state: Verity monitors server timeouts and error-prone scenarios to decide whether to terminate or maintain an MPC session. This necessitates slight adjustments to the MPC state machine.
  2. Collusion Prevention:
    • TLSNotary assumes Provers and Notaries are non-collusive.
    • Verity ensures this through Verifiers, which enforce non-collusion via TEE attestation and operational oversight.
  3. Authorised Notary Selection:
    • Provers interact with Verifiers to identify authorised Notaries.
    • Verifiers cross-reference inputs from Provers and Notaries, ensuring that the proof’s integrity is maintained.
  4. Portability:
    • TLSNotary proofs are inherently non-portable, limiting their use to specific contexts.
    • Verity decomposes these proofs into sub-proofs to enable compatibility with zkVMs and decentralised replicated compute platforms.

​
Why It Matters

  1. API Agnosticism: MPC-TLS allows existing APIs to produce cryptographically verifiable data without server modifications.
  2. Transparency in Data Lineage: Verity provides an immutable cryptographic audit trail for sourced data, ensuring transparency and trust.
  3. Cross-Blockchain Compatibility: Sub-proof decomposition enables TLS proofs to integrate seamlessly into various blockchain ecosystems and computational environments.

In summary, Verity extends MPC-TLS to create portable, verifiable data proofs, bridging Web2 data sources with Web3 applications. By launching a general-purpose core Verifier, Verity enables secure data pipelines across diverse blockchain networks and ecosystems.

​
TEE (Trusted Execution Environment)

A Trusted Execution Environment (TEE) is a hardware-based enclave designed for secure and tamper-resistant execution of code. TEEs isolate sensitive operations from the rest of the system, ensuring that computations and data remain confidential and secure.

​
How TEEs Work

  1. Secure Memory Isolation:
    • All data within the TEE is encrypted in memory, preventing unauthorised access from external processes or the host operating system.
    • This isolation ensures that sensitive computations remain shielded, even in the presence of compromised system components.
  2. CPU Lockdown:
    • The CPU enforces strict policies to only execute approved code within the TEE.
    • This eliminates the risk of unauthorised instructions interfering with enclave operations.
  3. Remote Attestation:
    • TEEs generate cryptographic attestations that prove the integrity of the environment to external verifiers.
    • These attestations confirm that the TEE is running trusted software on authorised hardware.

​
Risks

While TEEs provide strong security guarantees, they are not invulnerable. Common risks include:

  1. Physical Attacks: Side-channel attacks can extract sensitive information by analysing power consumption, electromagnetic signals, or other physical characteristics of the TEE.
  2. Software Exploits: Vulnerabilities in TEE firmware or software can be exploited to gain unauthorised access to the secure enclave.
  3. Supply Chain Risks: Compromised hardware or firmware during manufacturing or distribution could undermine TEE security.

​
Mitigation in Verity

Verity leverages TEEs for a specific, narrowly defined purpose: ensuring the integrity and confidentiality of TLS certificate generation by Notaries.

  1. TLS Certificate Protection:
    • The TEE ensures that the cryptographic keys used for TLS certificates are securely generated and remain inaccessible to the host.
    • This prevents any possibility of collusion or tampering between the Prover and the Notary.
  2. Enforcement of Non-Collusion: By confining critical operations within the TEE, Verity ensures that Notaries cannot reveal private cryptographic keys, and Provers cannot access the Notary’s internal operations.
  3. Shift of Trust: Verity shifts trust from individual operators to authorised cloud providers (e.g., AWS Nitro, Azure Confidential Compute, and GCP Shielded VMs) that meet TEE security standards.

The use of Trusted Execution Environments (TEEs) in Verity is crucial for ensuring the integrity and confidentiality of operations. TEEs prevent collusion between Provers and Notaries by securely generating and protecting TLS certificates, thereby maintaining the protocol’s integrity. By limiting TEE reliance to this specific function, Verity minimises the attack surface while leveraging the strongest capabilities of the enclave.

​
Verifiable Compute

Verifiable Compute refers to computational environments that enable data processing with cryptographic guarantees of correctness. This ensures that outputs adhere to predetermined logic while preserving the privacy of sensitive data. Verity employs two core cryptographic primitives for verifiable compute: Zero-Knowledge (ZK) Cryptography and Chain-Key (CK) Cryptography.

​
ZK (Zero-Knowledge) Cryptography

Zero-Knowledge Cryptography (ZK) is a cryptographic technique that enables the validation of a computation without revealing the underlying inputs or outputs. By encapsulating the entire computational process into a succinct proof, ZK ensures privacy and verifiability simultaneously.

​
How ZK Cryptography Works

  1. Circuit Construction: The computational process is expressed as a ZK circuit, representing the inputs, operations, and outputs.
  2. Proof Generation: The computation is executed over the circuit, resulting in a cryptographic proof (e.g., zkSNARK or zkSTARK) that attests to the correctness of the process.
  3. Proof Verification: A verifier can validate the proof without needing to execute the computation or access sensitive input data.

​
zkVMs (Zero-Knowledge Virtual Machines)

Definition: zkVMs are specialised virtual machines that execute computational processes securely within a ZK framework.

Mechanism:

  • Build on ISA-compatible CPU architectures (ie. RISC-V) to mimic conventional computational environments.
  • Aggregate the instruction set into a ZK circuit to produce a proof of correctness.

Advantages: zkVMs enable secure and private computations in conventional programming languages like Rust, producing verifiable, portable, and tamper-proof outputs.

Verity employs zkVMs to process private data within its pipelines, enabling secure transformations and aggregations. ZK proofs ensure that sensitive data can be validated without exposing its content, maintaining end-to-end privacy and integrity.

RISC Zero zkVM Whitepaper explains the foundations and applications of zkVMs in secure, verifiable computation.

​
CK (Chain-Key) Cryptography

Chain-Key Cryptography (CK), developed by the Internet Computer (IC), combines several advanced cryptographic primitives to facilitate distributed verifiable compute. CK integrates Multi-Party Computation (MPC), Threshold Signature Schemes (TSS), and Distributed Key Generation (DKG) to produce portable cryptographic outputs.

Verity integrates Chain-Key cryptography to utilise the IC for efficient, decentralised computation. By generating portable ECDSA signatures, Verity ensures that outputs from its pipelines can be verified across various blockchains and systems, enhancing interoperability.

​
How CK Cryptography Works:

  1. Distributed ECDSA Signatures: A set of IC nodes collaborates to generate an ECDSA signature over specific data, ensuring correctness and provenance.
  2. Portability: These signatures can be verified by external systems and blockchains using standard ECDSA verification methods.
  3. Dynamic Node Participation: CK allows nodes to dynamically join or leave the computation set, overcoming static limitations of traditional MPC-TSS systems.

​
NPVDKGRS Algorithm:

The Non-interactive Publicly Verifiable Distributed Key Generation and Resharing Algorithm (NPVDKGRS) underpins CK cryptography.

Innovation: Enables distributed systems to adapt to changing participants without compromising security or verifiability. Impact: Ensures that multi-party computations remain robust and scalable in dynamic environments.

NPVDKGRS Whitepaper details the advancements in distributed key generation and resharing algorithms critical to CK cryptography​TLSNotary-Review-2409.1…​TLSNotary.

ProtocolVerifiable Data Processing Environment (VDPE)