MACI Coordinator in a TEE

[ctrlc03]

Recently, while discussing potential ways of removing the role of a coordinator in MACI, or at least how to make it more permissionless and trusted, the topic of trusted execution environments came up.

A trusted execution environment (TEE) is a secure area within a main processor. It guarantees that the code and data loaded inside the TEE are protected with respect to confidentiality and integrity. A TEE provides a level of security by ensuring that the code and data inside the TEE cannot be tampered with by the normal operating system, and it can securely host applications and their data. (thx Chat GPT).

I am just reading now of how TEE work, so disclaimer that some of the facts below might very well be wrong, and I do encourage any pushback + suggestions on how this would work.

Advantages

• Increase anti-collusion: users can be assured that the briber is not going to collude because we trust (and verify) that the program does what is supposed to do
• Messages will always be private as long as the tee is not compromised
• Security: risk of coordinator key compromise decreases
• Can relax the constraints of the circuits (for instance no need to calculate path indices for merkle proof inclusions within the circuit, because we can trust the code to submit the correct data and not censor votes like this issue describes)
• Attestation that the process was done correctly i.e. prove that the audited coordinator code was run (on top of zk proofs of processing and tallying)

Drawbacks

• Seems solutions like Intel SGX have been hacked quite a few times, though we live and learn so recent improvements might have led to more secure solutions
• Costs? might be > than a normal EC2/other cloud instance for coordinator processing
• What happens if the program execution fails? Can it be restarted with the same guarantees?
• We still would be relying on a centralized party to manage a specific poll, and they could still decide to never complete a round

How do I think this would work

1. Coordinator keypair k1 is generated in the TEE
2. Poll is started by submitting a tx to the Maci contract (Maci.deployPoll(args)) with the k1pk (pub key) of the coordinator
3. Users use MACI as usual by submitting messages via a frontend/cli to the Poll contract on chain
4. The poll ends
5. The code within the TEE merges the state and message tress
6. The code then processes messages and tallies them, while generating zk proofs in batches and submitting them on chain
7. The TEE posts proofs that the correct code was executed (though this might not be needed as we already have the zk proofs, an user might verify that the verifying keys on chain match the audited version of the circuits/zkeys on github)

[kittybest]

maybe we could consider this: https://docs.aws.amazon.com/enclaves/latest/user/nitro-enclave.html

[ctrlc03]

yea I was looking into trying out running an instance and playing with it

[ctrlc03]

I'm looking into this and it looks like the code that can run into the enclave must be a binary compiled from languages such as c/c++/rust - so the coordinator code would need to be rewritten in either of these languages. Out of the enclave we need some data which needs to be posted on chain, but none of that is sensitive so that can work out quite well, and that would be getting the coordinator public key to post on chain when deploying a poll, the proofs/commitments and the tally file. To transfer data securely between the enclave and the host there's vsock, which we can use to get this data to our ts code that would be used to deploy a poll and submit on chain proofs/commitments

[baumstern]

It sounds like the point of using TEE is to process unencrypted ballots within a secure area, so this mechanism ensures the operator cannot read the plain ballot data.

Attestation that the process was done correctly i.e. prove that the audited coordinator code was run (on top of zk proofs of processing and tallying)

I think this is a critical point, and it seems a bit tricky to prove. It should be able to distinguish whether the output was actually computed inside the TEE, rather than externally using the same cryptographic keys or methods.

[ctrlc03]

It sounds like the point of using TEE is to process unencrypted ballots within a secure area, so this mechanism ensures the operator cannot read the plain ballot data.

Totally! and also the fact that the key would be generated within the TEE itself, and never make out of it or be exportable/printable, so that the operator would not have any knowledge of it.

I think this is a critical point, and it seems a bit tricky to prove. It should be able to distinguish whether the output was actually computed inside the TEE, rather than externally using the same cryptographic keys or methods.

Yes that is the tricky part for sure! Is it possible for the TEE to post some execution trace and hashes of the code that was executed, so that this could be verified? definitely an interesting area to research on, as it could be useful elsewhere too

[baumstern]

I think this apporoach seems like it's shifting the trust assumptions from the coordinator to the TEE vendor, because the security features of the TEE are neutralized if the TEE vendor retains the private keys during the provisioning stage

[ctrlc03]

Totally! though isn't that kinda the same assumption of using a cloud server for generating process messages/tally votes proofs? the coordinator private keys might be leaked/exfiltrated there too.

Curious, have you ever played with TEEs?