Maci Threat Modeling - DRAFT #2788
Conversation
AronisAt79
requested review from
0xmad,
JohnGuilding,
NicoSerranoP and
vplasencia
as code owners
|
@AronisAt79 is attempting to deploy a commit to the Privacy and Scaling Explorations Team on Vercel. A member of the Team first needs to authorize it. |
| 1. Generate MACI keypair (distinct from Ethereum key). | ||
| 2. Call `signUp()` on the MACI contract with the **public key**. | ||
| - This key becomes the voter’s MACI identity. | ||
| - The gatekeeper policy enforces Sybil resistance (e.g., NFT, EAS attestation, proof-of-personhood). |
There was a problem hiding this comment.
| - The gatekeeper policy enforces Sybil resistance (e.g., NFT, EAS attestation, proof-of-personhood). | |
| - The gatekeeper policy enforces Sybil resistance (e.g., NFT, EAS attestation, proof-of-personhood). | |
| - This key is registered in the `leanIMTData` state tree variable on the MACI contract. In this step, anyone could link the user's gatekeeper-passing address (aka real address) with the user's MACI public key |
I am not sure if this distinction should go in this section or maybe in Data artifacts created:
There was a problem hiding this comment.
@NicoSerranoP is this condition potentially breaking linkability? aka, do we leak participation info for the user's onchain identity? and if so, is this a weakness - correlating poll participation with other onchain activity, or correlating participation across different polls (user X has participated in polls x,y and z?. Is this a potential threat/vulnerability/weakness?
Maybe we could consider extending the privacy/linkability invariant statingt that linkability of maci key to users EOA is not covered and also add a known weakness section (unless we do not consider it a weakness?). What about possible mitigations? Use relayer for signup ?
There was a problem hiding this comment.
I am not sure if this distinction should go in this section or maybe in Data artifacts created:
yes, i agree it makes sense to add this as a step artifact
| | **Relayer ↔ IPFS** | Batch persistence | If IPFS batches are missing or corrupted, poll finalization is blocked. | | ||
| | **Coordinator ↔ Blockchain** | Proof publication | Coordinator can halt or censor proof publication (affecting liveness). | | ||
| | **Coordinator ↔ Verifier** | Proof checking | Assumes verifier contract and circuits match and are sound. | | ||
| | **Coordinator ↔ IPFS** | Message retrieval | Coordinator depends on IPFS data integrity to decrypt and process votes. | |
There was a problem hiding this comment.
| | **Coordinator ↔ IPFS** | Message retrieval | Coordinator depends on IPFS data integrity to decrypt and process votes. | | |
| | **Coordinator ↔ IPFS** | Message retrieval | Coordinator depends on IPFS data integrity to decrypt and process votes. | | |
| | **User ↔ Briber** | Anti bribery | User might sell his own MACI keypair and not perform a key change to the briber's keypair. | |
There was a problem hiding this comment.
@NicoSerranoP this is nice and i think reveals good system design! first, i think a briber should not be classified as a trust boundary as it does not represent a subsystem for which we are relying on trust assumptions against. Maybe more proper to frame as an adversary.
My understanding is that our anti collusion invariant (I2) still holds. We have an opt-in key rotation option. This alone renders bribery unreliable, at least statistically speaking; briber has no solid evidence that the voter did not override their previous vote eventually, even if the voter promises to the briber that they act in bad faith, correct?
I think what we are missing here is the key change flow documentation, as pointed in other comment, plus listing a briber as an adversary for the model?
|
|
||
| - [x] **Network observer / manipulator** — may monitor, reorder, or delay transactions. | ||
| - [x] **Sybil farm** — may register many fake identities if gatekeeping fails. | ||
| - [x] **Rogue coordinator** — can censor or withhold processing but cannot falsify proofs. |
There was a problem hiding this comment.
| - [x] **Rogue coordinator** — can censor or withhold processing but cannot falsify proofs. | |
| - [x] **Rogue coordinator** — can censor or withhold processing but cannot falsify proofs. If colluding with a briber, may reveal how specific MACI keys voted — breaking privacy and enabling credible bribery. | |
| - [x] **Briber** - can buy the MACI keypair and not ask user to perform a key change to the briber's keypair. |
There was a problem hiding this comment.
@NicoSerranoP i suggest we do not add another adversary class, for clluded coordinator; we can extend the rogue coordinator to include the collusion scenario? wdy think?
There was a problem hiding this comment.
We need to add the key change flow in this diagram. It is super important because it gives the receipt freeness feature to MACI and therefore prevents bribery: a briber could ask the user to change the public key to his public key but he will never know if his bought vote was the one accounted for.
More info: https://maci.pse.dev/docs/core-concepts/key-change
There was a problem hiding this comment.
will do, thanks for finding this
There was a problem hiding this comment.
@NicoSerranoP would you mind cross checking correctness?
Co-authored-by: Nico Serrano <[email protected]>
Co-authored-by: Nico Serrano <[email protected]>
Co-authored-by: Nico Serrano <[email protected]>
Co-authored-by: Nico Serrano <[email protected]>
Co-authored-by: Nico Serrano <[email protected]>
Co-authored-by: Nico Serrano <[email protected]>
Co-authored-by: Nico Serrano <[email protected]>
Co-authored-by: Nico Serrano <[email protected]>
Co-authored-by: Nico Serrano <[email protected]>
Co-authored-by: Nico Serrano <[email protected]>
Co-authored-by: Nico Serrano <[email protected]>
Co-authored-by: Nico Serrano <[email protected]>
Co-authored-by: Nico Serrano <[email protected]>
Co-authored-by: Nico Serrano <[email protected]>
Co-authored-by: Nico Serrano <[email protected]>
2 participants
Description
This PR introduces a preliminary approach to a maci threat model, with supporting documentation. Consists of a threat model that follows the structure of https://github.com/privacy-ethereum/pse-security-hub/blob/tm-alpha/threat-modeling/templates/THREAT_MODEL.md, system level specification with system roles/components, data flows and trust boundaries, plus a mermaid diagram representing system flows and sequences. We also provide an extension of the threat model for L2 based maci deployments
Additional Notes
This is just a draft aiming to kick off discussions around the threat model content and overall process optimizations. Not intended to be merged at this point.
Related issue(s)
None
Confirmation
Important
We do not accept minor grammatical fixes (e.g., correcting typos, rewording sentences) unless they significantly improve clarity in technical documentation. These contributions, while appreciated, are not a priority for merging. If there is a grammatical error feel free to message the team.