Skip to main content

LCP Client (zkDCAP)

Overview​

The LCP Client (zkDCAP) extends the LCP Client (IAS) by supporting DCAP (Data Center Attestation Primitives) Remote Attestation using zkDCAP, a technology to efficiently verify SGX/TDX quotes on-chain using ZKP.

This client is intended to be implemented as a Light Client module in ibc-go or ibc-solidity, conforming to ICS-02.

zkDCAP Overview​

Verifying DCAP quotes directly on Ethereum or other EVM-compatible chains consumes significant gas. To address this issue, we developed zkDCAP, a technology that offloads the DCAP quote verification process off-chain by generating a zero-knowledge proof (ZKP) of the verification results. The zkDCAP Quote Verifier integrates with the RISC Zero zkVM to perform these off-chain verifications and produce ZKPs. Additionally, our design minimizes trust assumptions regarding verification collateral management by eliminating the requirement for additional multi-signature schemes and relying only on the presence of at least one honest operator.

Differences from LCP Client (IAS)​

The primary difference is the addition of the zkDCAPRegisterEnclaveKey function to handle zkDCAP verification. Other functions remain as described in the LCP Client (IAS) documentation.

State Definition​

ClientState​

message ClientState {
  bytes mrenclave = 1;
  uint64 key_expiration = 2;
  bool frozen = 3;
  Height latest_height = 4;
  repeated string allowed_quote_statuses = 5;
  repeated string allowed_advisory_ids = 6;
  repeated bytes operators = 7;
  uint64 operators_nonce = 8;
  uint64 operators_threshold_numerator = 9;
  uint64 operators_threshold_denominator = 10;

  // New fields for zkDCAP
  uint32 current_tcb_evaluation_data_number = 11;
  uint32 tcb_evaluation_data_number_update_grace_period = 12;
  uint32 next_tcb_evaluation_data_number = 13;
  uint64 next_tcb_evaluation_data_number_update_time = 14;
  repeated bytes zkdcap_verifier_infos = 15;
}
  • current_tcb_evaluation_data_number specifies the minimum TCB evaluation data number that the client currently accepts. zkDCAP outputs are accepted only if they are generated using collateral with a TCB evaluation data number equal to or greater than this value.
  • tcb_evaluation_data_number_update_grace_period specifies a grace period (in seconds) allowing operators sufficient time to update their SGX environments when a new TCB evaluation data number is observed.
  • next_tcb_evaluation_data_number holds the upcoming TCB evaluation data number scheduled to replace the current one after the grace period.
  • next_tcb_evaluation_data_number_update_time is the UNIX timestamp when the next_tcb_evaluation_data_number becomes active.
  • zkdcap_verifier_infos contains verifier-specific data required by zkDCAP, including zkVM type identifiers and zkVM-specific information.

Please refer to the the ClientState definition for the details.

ConsensusState​

Remains identical to the existing LCP Client (IAS).

ZKDCAPRegisterEnclaveKey​

ZKDCAPRegisterEnclaveKey is a function that validates a zkDCAP output and its proof and registers an enclave key (EK) generated by an SGX enclave running on a secure platform. Currently, this client supports only the RISC Zero zkVM for proof verification.

The function signature is defined as follows:

function zkDCAPRegisterEnclaveKey(string calldata clientId, ZKDCAPRegisterEnclaveKeyMessage calldata message)

The ZKDCAPRegisterEnclaveKeyMessage contains the necessary data for validating and registering the enclave key. Its structure is defined as:

message ZKDCAPRegisterEnclaveKeyMessage {
  uint32 zkvm_type = 1; // Identifier for the zkVM type generating the proof
  bytes quote_verification_output = 2; // The zkDCAP verification output
  bytes proof = 3; // ZKP generated by zkVM for the verification output
  bytes operator_signature = 4; // Optional EIP-712 operator signature
}

zkDCAP Quote Verification Output​

The quote_verification_output is a structured output produced by the zkDCAP Quote Verifier. It contains the following values required for on-chain verification:

  • sgxIntelRootCAHash: Hash of the Intel Root CA certificate used in collateral verification.
  • tcbStatus: TCB status of the target platform and the enclave
  • advisoryIDs: Security advisory IDs relevant to the target platform or Quoting Enclave (QE).
  • validityNotBefore and validityNotAfter: Validity period for the collateral.
  • min_tcb_evaluation_data_number: The minimum TCB evaluation data number of the collateral used in verification.
  • mrenclave: Enclave measurement identifying the enclave. This value can be extracted from quote_body.
  • enclaveDebugEnabled: Indicates whether the enclave was operating in debug mode. This value can be extracted from quote_body.

For further details, refer to the zkDCAP repository.

zkDCAP Output Validation​

  • Proof Verification: Using the RISC Zero zkVM verifier contract, it verifies the provided ZKP against the quote_verification_output.
  • zkDCAP Output Validation: The output is parsed to confirm:
    • The parsed sgxIntelRootCAHash matches the expected Intel Root CA hash stored in the client.
    • mrenclave matches the one stored in ClientState.
    • The tcbStatus is either "UpToDate" or explicitly allowed in the client's allowed_quote_statuses.
    • All security advisories listed in advisoryIDs are explicitly allowed in the client's allowed_advisory_ids.
    • The current block timestamp is within the validity range (validityNotBefore, validityNotAfter).
    • The enclave debug mode (enclaveDebugEnabled) matches the client's configured developmentMode.
    • The min_tcb_evaluation_data_number from the verification output is equal to or greater than the client's current_tcb_evaluation_data_number.
  • EK Expiration Calculation: Calculates the EK expiration timestamp (expiredAt) based on key_expiration:
    • If key_expiration is 0, the EK expires at validityNotAfter.
    • Otherwise, the EK expiration is the minimum between validityNotBefore + key_expiration and validityNotAfter.
  • Operator Signature Verification: If an operator signature (operator_signature) is provided, verify it matches the operator address associated with the enclave key.

Operational Assumptions​

The security and reliability of the LCP client protocol are based on the following assumptions about operators (not limited to those listed in the client state's operators field):

  • TCB Data Synchronization: At least one operator regularly fetches and uses the latest TCB evaluation data from Intel's Provisioning Certification Service (PCS) to ensure synchronization with actual TCB recovery events. Without this assumption, the client could potentially accept attestations evaluated with outdated TCB collateral for up to 12 months (Note: See also the Intel PCS documentation on the update=standard parameter).

  • SGX Platform Upgrade Readiness: Operators must maintain readiness to promptly upgrade their SGX platforms when a new TCB evaluation data number is observed. Operators should set an appropriate grace period allowing sufficient time for these platform upgrades. This grace period represents a trade-off—longer periods can delay adopting the latest TCB data (increasing security risks), while shorter periods could risk availability if operators cannot complete upgrades promptly.

TCB Evaluation Management​

Under the operational assumptions, TCB evaluation data numbers (client's current_tcb_evaluation_data_number and next_tcb_evaluation_data_number, min_tcb_evaluation_data_number from zkDCAP's Quote Verification Output) are managed as follows:

General Cases:

  • Scheduled Update:

    • If the grace period is non-zero, and no next TCB number is reserved, the newly observed min_tcb_evaluation_data_number greater than the current is reserved as next_tcb_evaluation_data_number, scheduled for activation after the defined grace period.

  • Immediate Update:

    • If the grace period is zero, immediately update current_tcb_evaluation_data_number when a higher min_tcb_evaluation_data_number is observed.
    • If the grace period is non-zero and the current time exceeds the scheduled next_tcb_evaluation_data_number_update_time, immediately activate the reserved next_tcb_evaluation_data_number as the current number.

However, the following edge cases may occur:

Edge Cases:

  • Edge case 1 (current < next reserved < newly observed): Immediately activate the reserved next number as the current number, bypassing any remaining grace period, and schedule the newly observed number as next.
  • Edge case 2 (current < newly observed < next reserved): Immediately update the current number to the newly observed number, keeping the existing reserved number unchanged.

We assume that these edge cases represent immediate updates to non-latest TCB numbers, which do not pose issues due to the operational assumption that operators maintain readiness and utilize up-to-date or near-current TCB collateral.

State Management and Events​

  • Upon successful validation:

    • The enclave key (EK) is stored with:
      • expiredAt: Calculated expiration timestamp.
      • operator: Associated operator address (if provided).
    • TCB evaluation data numbers are updated according to the described rules.

  • Events emitted:

    • LCPClientZKDCAPRegisteredEnclaveKey: Emitted upon successful EK registration, containing:
      • clientId: Client identifier.
      • enclaveKey: Ethereum address format of EK.
      • expiredAt: EK expiration timestamp.
      • operator: Associated operator address (if not provided, set to the zero address).
    • LCPClientZKDCAPUpdateCurrentTcbEvaluationDataNumber: Emitted when current_tcb_evaluation_data_number is updated.
    • LCPClientZKDCAPUpdateNextTcbEvaluationDataNumber: Emitted when a new next_tcb_evaluation_data_number is scheduled.

Reference Implementation​