Notes on programability and TEE/SGX-based smart contracts

Greetings zeal,

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.

15 Likes

Awesome write-up sir. :heart_on_fire: I have used Secret in the past, including minting SSCRT but must admit I’m not an expert on most of this information. The potential UX for ZSA’s would probably be similar. Looking forward to digest this.

Screenshot_2022-12-14_14-02-11

1 Like

I think in the event of a TEE failure the adresses must not be leaked. If I remember correctly from the Taiga presentation at Zcon the who part is not difficult to hide in the context of smart contracts, it is the what.

I think it would make sense to use ZSAs for everything you can, such as holding ZEC or a plain fungible token, and only rely on TEEs/MPC for apps that need it. For example in a Compound-like lending application, your collateral deposit inherently needs to be “viewable” to the TEEs in order to carry out liquidation when necessary. ZSAs alone wouldn’t be good for that… no one can view your zsa unless you authorize it. This way a TEE break would have the least impact, and no impact directly on the “ordinary” coins.

taiga presentation from zcon

3 Likes

I agree, TEEs should only be used when necessary, and they need to know which assets you have and how much, but they don’t need to know your address. What I am saying is that any TEE layer should not have your real address visible to even the TEE, so users don’t need to worry about sending their assets through a burner account (stealth address) to the smart contract.