HackMD
Overheard at TEE Salon
- The image was uploaded to a note which you don't have access to
- The note which the image was originally uploaded to has been deleted
Attestation allows us to verify that a Trusted Execution Environment is running on trusted hardware. Ergo, any computation performed within the secure enclave inherits properties of integrity and confidentiality secured by the TEE. In this post, we talk about:
- What exactly is verifying an attestation report
- A better interface for composable attestation verification
- How we already have a Web3-based TEE attestation framework today
Bottlenecks so far
Currently, blockchain systems that deploy TEEs run into the same set of problems. Attestation is often thought of as a monolithic thing, which makes it hard to use. There is a shortfall in the documentation and work being done to build in the space not only around how TEEs can be applied to Web3, but in relation to TEE themselves. In our own experience building Automata DCAP v3, a Solidity verifier, we encountered the following problems:
- Customized logic tailored to specific workloads
- Each project having to deploy their own verification contracts
- Attestation collaterals not maintained in a distributed manner
TEE attestation moves (entirely!) on-chain
The good news is that:
- Attestation verification can be composable
- Decentralized repository ease attestation overheads
- Solutions today are already live
To understand what exactly we did, let’s take a look at the anatomy of how what attestation looks like: verify(quote) -> bool
- The image was uploaded to a note which you don't have access to
- The note which the image was originally uploaded to has been deleted
This forces us to perform all verification and validation in the same step, and requires us to have the collateral maintained in one place (mostly). Which places significant stress and constraints on how projects can work with TEEs. Therefore we need to understand what we mean by verifying the remote attestation:
- Establishing the authenticity of the attestation report
- Validating that the content specific to a particular workload
The attestation report has both information that proves the authenticity of the report and information about the workload (that it is valid). By extending the same logic, we can break the verification process down into two steps:
verify(quote) -> verified_resultdownstream(verified_result) -> bool
Now we are now able to do far more interesting things. The overlapping constraints between both steps can be addressed by having the bulk of the attestation workflow be handled in the first step. Downstream users take it further by customizing the business logic based on their own needs.
In such a way attestation verification becomes composable:
verifyAndAttest(quote)
ZK for attestation aggregation
Having broken down the attestation workflow, this flexibility allows for a far better interface and more intuition around the developer experience. But even with these advantages, attestation verification is still held back by the hefty costs of its on-chain environment.
That was a problem we set out to fix using ZK. By our own measurements, we spent about 3 million gas verifying a single DCAP quote. Using RISC Zero, we reduced that amount to 350K gas for a single quote verification. Which is great!
Therefore, we now expect the attestation workflow to look like:
verifyAndAttestOnChain(quote)
verifyAndAttestFromZkProof(journal, seal)
- The image was uploaded to a note which you don't have access to
- The note which the image was originally uploaded to has been deleted
On-chain PCCS to complete workflow
The DCAP attestation verification workflow for Intel SGX relies on the Provisioning Certification Caching Service (PCCS), which caches attestation collaterals for access. In its current state, each project has to configure their own caching service each time they run the attestation workflow. Quote generation and verification remains on the local platform, maintenance is a constant challenge, and the process is painfully inefficient.
Over time it was clear that we can afford to be more thoughtful about how we implement PCCS infrastructure.
We therefore made a decision to bring PCCS on-chain.
A decentralized repository means projects now have a common library where collaterals can be reused and stored on-chain for quote generation/verification. Going forward, we hope for on-chain PCCS to form a shared base for all projects when interacting with TEEs on attestation verification. On-chain PCCS is:
- Transparent; workflow is recorded and managed on-chain by smart contracts
- Collaborative; contributors can upload collaterals to update missing or expired ones
- Composable; Collaterals are reusable. Developers don’t have to reconfigure their tech stack for each single attestation/verification
Image Not Showing Possible Reasons- The image was uploaded to a note which you don't have access to
- The note which the image was originally uploaded to has been deleted
Many thanks to the Flashbots team for organizing TEE Salon and for the invite, even if intern wasn't actually invited.
