This is a great time to discuss a bunch more topics, now that we have a whole concrete example running in an enclave that’s easy to modify.
- The Validator Collusion problem mentioned in the post is for me the most surprising issue, which I think deserves more awareness since it does apply to every existing TEE-based smart contract blockchain. A quorum of validators could collude to decrypt all the data. So this isn’t any better as a trust model than MPC… just tidier and more efficient. But we could do better if validators ran TEEs as well, using TEEs as an Anti-Collusion mechanism. So this is interesting to discuss.
- Expanding on the key manager. This is the simplest possible key manager, it would be interesting to make Solidity contracts that more resemble the features from Oasis or Phala. They have a whole “council of gatekeepers” that multisig vote on mrenclaves. Things like notice periods are interesting too. It’s just Solidity, anyone could jump in here
- Side channels. I really want to see what this looks like running in SGX-Step to see what kind of memory access pattern it leaks. Lmk if interested in helping
- Bailing out of the TEE. How could you take one of these applications and pass the confidential data to an External TEE application, like with an entirely different enclave? You shouldn’t need to modify any precompiles to do this, just use the same DCAP attestation or something. Just a subversive idea
Am I right that the flow for contract specific keys you have in mind is that a contract key is derived from one TEEs sealing key and then distributed to all other relevant TEEs? In principle, we could implement more complex logic like secret sharing just with contracts right
as a non-cryptographer looking at the code, I’m a little confused by the boostrapping process. localRandom() seems to be generating random bytes as the contract key. Is that a kind of one-time pad or just some filler code? Also, you’re storing xPriv in volatile memory so a restarted TEE would lose access to the key (?). In future flows, what do you think is a better way of persisting the key? We could encrypt and write to chain or propagate to other TEEs.
Also, we could trade liveness guarantees for additional security by creating two committees required for a suave chain block to be valid. One set of TEE gatekeeper nodes and one set of validator running on untrusted servers. If one of these went down we would lose liveness at least for a while. What we get from this in comparison to all suave chain validators running TEEs may be improved performance and costs (fewer TEEs), but this may not be significant at all.
The key that’s distributed to all relevant TEEs is the bootstrap key created with localRandom rather than the sealing key, but I think both work about as well
This localRandom is the key shared by all contracts. At bootstrap time it’s stored in volatile memory yes, but the point is that as a result of register/onboarding, each Kettle can use it’s sealing key to decrypt xPriv even if it restarts
RAM would also be wiped, but the idea is after restarting you can rerun “finish_Onboard” again, reusing the same ciphertext from the previous time, and decryption will work because of the sealing key being the same
Regarding Validator collusion: how do validators decrypt the data if the private key is generated inside the TEE? I feel in MPC collusion comes from validators commicating off-chain to reconstruct the keys. How would validators get access the the TEE private key?
Here the issue is that validators could collude to create a “private fork” of the chain where critical state is different from the real fork… in particular, validators could create a private fork where the contract code for a given contract is malware that outputs all the sensitive data. This is an issue because the light client in the enclave is relying on Validator signatures to authenticate contract code, storage, etc.