I’ve been spending my time the past months studying TEE-based smart contracts, especially Secret Network. This is relevant to Zcash since a TEE/SGX-based execution layer could be a good path for adding programability to Zcash, so I want to file my report here. There are a bunch of blockchain projects that use SGX as an extra defense in a mostly-cryptographic protocol but don’t essentially depend on it, like the Avalanche bridge and Mobilecoin. My focus has been on smart contracts specifically, which means Secret, Oasis, Phala, and Obscuro are the open source projects to look at today.
Most discussions about SGX get bogged immediately on the basic trust model, which is heavily bottlenecked on Intel, not just a) to design the (closed-source) hardware and microcode, and not even b) just to manufacturer them according to that spec, but also c) to run an ongoing provisioning service and not to leak their keys or certify rogue enclaves. I’m not an architecture/microcode expert so the details of aepicleak, foreshadow, cacheout, load value injection (there’s more but i’m out of breath) are largely beyond me (folks who actually study this point out that the SGX parts seem to be the buggiest part of the entire cpu design). I’ve been looking at these at the next level up… assuming the SGX works as intended, how do you avoid introducing other problems? And how can you mitigate or reduce the attack surface to suffer the least damage when the next vulnerability comes?
Basically my findings so far are that even if you decide to accept the basic SGX trust model, there’s plenty of design pitfalls that are more basic:
- sgx.fail: the story is pretty interesting imo, basically both houses of Zcash ended up capturing Secret’s master decryption key using xAPIC while exploring the same security issue (Christina Garman, from the 7S Zcash founders and Bootstrap board was part of a team working separately from me, but we joined up to report it).
- sealing with MRSIGNER. This post summarizes the above, draws comparisons with the other three upcoming projects, and explains how an easily misunderstood SGX feature leads to an unwanted decryption backdoor.
These are posted publicly about these elsewhere so none of this is a Zcash exclusive, but wanted to share it here for comments. I’m interested especially in starting a technical discussion on what range of tradeoffs (musts and shoulds, etc.) would the Zcash community find acceptable for a TEE-based smart contract execution layer.