As blockchain technology evolves, the need for enhanced privacy, security, and verifiability becomes more critical. Trusted Execution Environments (TEEs) provide a promising solution to these challenges by providing a secure enclave for processing sensitive data. We have seen many combinations of TEEs and other cryptographic primitives, such as:

• Decentralized Block Builder and MEV Supply Chain, projects like Flashbots SUAVE aim to leverage TEE to ensure that block building is both decentralized and secure by placing the block builder within a TEE.

• TEE as a defense-in-depth (2FA) for zkRollups and MPC/FHE, projects like ZAMA, Taiko, Scroll, and IoTeX W3bstream are exploring the use of TEEs to enhance the security of their cryptographic operations by using a TEE as a defense-in-depth mechanism.

• Decentralized AI, by placing an AI model within a TEE, we can ensure that the model's training and inference process remain verifiable and confidential-preserving. A TEE-based decentralized AI system can enable untrusted parties to collaborate, contribute, and monetize open source AI models.

Remote Attestation Enables Verifiable Compute

TEEs are designed to guarantee the confidentiality and integrity of the software running inside them by prohibiting access from the host operating system or even the physical owner. When implemented correctly, the hardware ensures the correctness and confidentiality of the program running inside.

The TEE convinces users that their application is indeed running within a genuine TEE by a protocol called Remote Attestation. It ensures:

• The hardware is a genuine TEE

• The software deployed to the TEE is unmodified

• It’s possible to establish a secure communication channel between the user and the software

With Remote Attestation, complex computing tasks can be offloaded to TEE but verified onchain.

Workflow of Remote Attestation

Attestation is implemented by signing a message with the measurement of the program and the environment, by a special key only known to the hardware. The attestation is verified when the signature of the message is cryptographically verified.

The attestation protocols vary by different processor vendors. In this article, we are going to talk about DCAP, the protocol used by Intel SGX, the most popular TEE. Now, let’s break down the workflow of remote attestation step by step.

0. Report Generation
• When a user sends a remote attestation request to Intel SGX, a report is generated inside the enclave measuring the hash of the program and the hardware information
• The report is then signed by the TEE with the attestation private key
• The report is then sent to the verifier to check

0. Collateral Preparation
• Before verifying the report, the verifier needs to fetch the verification collateral (the information needed to verify the report) from Intel
• The collateral includes the public key to verify the report, as well as other information such as the hardware version and whether the TEE is up-to-date.
• The collateral is signed by Intel. The signature is verified to ensure the integrity of the collateral.

0. Verification
• The verifier then matches the report with the verification collateral to determine whether the report is valid, and if the hardware is bug-free
• When using TEE onchain, the verification should happen onchain

How We Leverage RiscZero zkVM to Make Attestation Trustless

Verifying Remote Attestation is challenging, particularly on Ethereum:

• Lack of Cryptographic Primitives: EVM lacks support for some native cryptographic primitives needed for quote verification, especially P256 signature verification.

• High Gas Costs: Verifying attestation quotes on Ethereum is prohibitively expensive because it requires complex computations, such as parsing X.509 certificates and iterating through collateral data.

How RiscZero zkVM Plays a Role

Instead of verifying the quote directly on Ethereum, we can leverage RiscZero's zkVM to handle the quote verification offchain and only submit the proof onchain. Here’s how it works:

0. Off-Chain Quote Verification:
• RiscZero's zkVM can execute the quote verification process using full Rust libraries. This includes accessing JSON, WebPKI certificate libraries, and cryptographic libraries easily.
• By running the quote verification with DCAP in RiscZero zkVM, we ensure that the process is secure and efficient. The zkVM acts as part of the guest code, handling the complexities of verification.

0. Generating Proof with STARK and SNARK:
• Under the hood, RiscZero zkVM uses a STARK prover to validate the verification program. This is then converted into a SNARK proof, specifically a Groth16 zk proof, which is very cheap to verify onchain.
• This approach significantly reduces the computational burden and gas costs associated with onchain verification, consuming only around 250k gas for proof verification.

0. Onchain Verification by Smart Contracts:
• Once the SNARK proof is generated, it can be submitted to a groth16 verifier deployed by RiscZero on Ethereum for verification.

The Benefits After Moving TEE Verification Onchain

• Reduced Reliance on Intel: While we still rely on Intel Provisioning Certification Service (PCS) to provide certification collateral cache, this does not introduce any trust assumptions for Intel. The PCS can be run anywhere, including onchain, ensuring that the certification process remains decentralized and trustless.

• Trustless Verification: By using RiscZero zkVM and generating SNARK proofs, the verification phases are conducted in a manner that does not rely on any centralized authority. This ensures that the integrity of the TEE attestation is maintained without external dependencies.

Future work

• Currently, the proof is generated locally. We will offer an option for workers to generate proof through RiscZero Bonsai, which will reduce the time cost for proof generation

• Support Remote Attestation V4 with Intel TDX support