Follow Up: Now we have a Solidity-based verifier for DCAP as well!
In the last post I focused on smart contract verification of SGX attestations using RAVE. If you’re following SGX, you may have noticed that we covered EPID attestations, but this will soon be deprecated in favor of DCAP. Fortunately, Automata have just open sourced automata-dcap-v3-attestation, their counterpart to RAVE, a suite of Solidity contracts that verify DCAP attestations.
Exploring this library marked a milestone for me, since it was the first time I’ve gotten an end-to-end verification demo of DCAP to work on my local SGX, despite trying several times before. Because I used the same gramine-dummy-attester enclave from the last post (just switched from dcap to epid), this demonstration also shows off some modularity of the web3 TEE stack: The Automata developers and I used very different enclave frameworks for development (I used Gramine, they only use Teaclave). Regardless, the Solidity code verifies the attestations produced by my enclave just as well (with small changes documented here). Instead of a demonstration on Sepolia, I’m settling for checking in the attestation I generated as a passing test vector, and skipping straight to the insights.
Moving to DCAP reduces reliance on Intel.
The main reason to prefer DCAP over EPID is that it cuts out an unnecessary round trip of interaction with Intel’s IAS service. Besides latency, this would allow Intel to censor individual applications. With DCAP, this interaction is removed. The only remaining interactions with IAS, specifically provisioning a device and fetching TCB Infos, do not involve application identifiers at all so they don’t have this problem.
A Solidity verifier can make switching to DCAP easier.
Almost every prototype demonstration of SGX, if it includes remote attestation at all, stops at EPID before DCAP. Why is this? One reason is that unlike EPID where there are somewhat generic tools like gramine-sgx-ias-verify, there aren’t as readily available tools for verifying DCAP. So, having a Solidity verifier available serves as a portable reference.
DCAP benefits even more from on-chain accountability.
A second reason DCAP is tricky is that verification involves an extra step of dealing with “TCB info” packets. These are signed messages from Intel, indexed by processor family, and that are updated during TCB recoveries (like after vulnerabilities are announced). This process would benefit from being stored on-chain (like Automata’s contract does, or otherwise at least referenced on-chain) in order to keep Intel accountable for these messages (discussed here).
Note that in Automata’s demo, the TCBInfos are posted on chain, but they must be provided by the contract owner. However, the signature from Intel is not checked on-chain. The best way to describe this scenario is that the contract provides accountability for the Automata developers, but skips an opportunity to do proactive checking. The contract owner might be expected to keep such signatures around for inspection off-chain, but whether anyone is paying close enough attention to hold them to it is unclear!
Conclusion: what next?
Support for TEEs in web3 has come a long way. Solidity verifiers for DCAP remote attestation is a great milestone. What else is next to do? The following stood out after finishing this DCAP experiment:
PCCS still needs simplifying.
The most frustrating part of setting up DCAP was the need to sign up with my email address for an Intel API key, this time for the “PCS” service. This is frustrating because it looks like another Intel bottleneck, which would defeat the point of DCAP. But actually this step is entirely unnecessary.
What’s going on? Basically DCAP relies on a certificate chain. The certificates are accessed during attestation, so a high trust system (the quoting enclave) is responsible for fetching them. Similar to TCBInfos, these are indexed by processor type, and are updated periodically. Since they can be authenticated, and they don’t depend on the application or the particular physical processor, these could be mirrored and provided by anyone. However, Intel only gives them out directly if you use an API key. And the default implementation (pccs) only guides you through this path. If we made a lightweight alternative to this caching, bypassing the need for an API key, we would remove another barrier to entry for DCAP demos.
Need for testing under diverse system configurations.
Needing to modify Automata’s code at all was because of my enclave behaving differently than theirs… both of which were within the spec, but the implementation didn’t handle the general case. (this has since been patched) There seems no good replacement for verifying compatibility under a variety of different system configurations. This is an opportunity to coordinate since different teams are likely to have different configurations, and maybe we can exchange continuous integration for coverage.