Questions about how E2E-V would work in deployments

[vteague]

Hi @kiniry, and all, I’ve started (but not finished) reading the docs, and I have a few high-level questions to make sure that I understand the threat model / trust model. I have mostly been reading https://github.com/FreeAndFair/VoteSecure/blob/main/docs/conops/conops.md

I understand that this is an SDK, not a voting system, but since the concept of operations seems relatively advanced it seems fair to ask about it. Of course, it’s the complexities of input and output that make Internet voting so hard.

1. It looks like no receipt-freeness claim is being made. From a receipt-freeness perspective it’s very similar to Helios: a minor client-side modification could retain randomness and hence allow voters to prove how they voted. Am I understanding that right?

2. Is there a verification spec somewhere?

3. Cast-as-intended verification. It looks like the adversary may compromise the voting client, and I see in Conops - Environment there’s an assumption that malicious apps on the voter’s phone may leverage their presence to compromise the voting application. That makes sense. However, it also looks as if the Ballot Check application runs on the same phone. So I have three questions.
   a. What exactly is the threat model?
   b. Why is it reasonable to assume that the adversary can leverage cross-app security issues to compromise the voting application but not the checking application?
   c. Is there an easy way for voters to verify from another device?

4. Are the mixing and decryption proofs published on the public BB?
   a. If not, would you still claim E2E-V?
   b. If so, why does the data need to be transferred via USB stick to the Trustee Servers rather than letting the Trustees read the data off the BB?

5. What exactly is the trust assumption on the Trustee servers? Obviously they must be trusted (on a threshold basis) for privacy. Is there also an integrity trust assumption? (This relates to whether the decryption proofs are on the public BB or not.)

6. Conops - Environment says “It is assumed that advanced persistent threats (APTs) have access to all environments.” Does that include the printer? To put it another way, if the printer substituted a ballot, what part of the verification process would detect the substitution?

7. How does the threat model, in terms of both privacy and verifiability, compare with those of the Swisspost system, Belenios, Helios, or others?

[dmzimmerman]

I (or somebody else) will address all of these questions in detail at some point in the near future (and probably also add them, and their answers, to the project FAQ), but I wanted to quickly say that with respect to (3), the ballot check can be run from any device. Voters might only have one device, and thus might choose to run the ballot check from a web browser or separate app (depending on how it ends up being distributed) on the same device, but verification should ideally take place on an independent device (or more than one such device).

[dmzimmerman]

My apologies for the amount of time it took (holidays in the U.S., various other things), but here are some more detailed answers:

1. Indeed, we make no claim of receipt-freeness. We decided to not even attempt to make VoteSecure formally receipt-free. Our reasoning was that since mobile voting (like mail-in voting) is unsupervised, modern technology makes the receipt-freeness property significantly less useful in practice than it is in theory; when you can easily record video (either via screen recording or with a second device) of your entire voting session and use that to demonstrate how you voted and that you cast the ballot, including showing sufficient information to allow the ballot to be found on the public bulletin board by a vote buyer or coercer, any additional receipt (such as the randomizers) has little value.

2. We need to write a detailed verification spec. I believe the bits and pieces of it (in terms of what information is posted to the public bulletin board, etc.) are scattered about the documentation, but we should really collect it in one place. We'll try to do that soon.

3. As I noted previously, there is no assumption that the ballot check application runs on the same device, and indeed if the entire device is compromised, running it on the same device is of little use. The intent is that another device is used for ballot checking.

4. Yes, the mixing and decryption proofs get posted to the public bulletin board. The trustees cannot read the data directly off the public bulletin board because they don't have access to the public bulletin board inside their air gapped environment. They could read the data off the public bulletin board before entering the air gapped environment, bringing it in with them on USB sticks or other storage.

5. No, trustees are not trusted for integrity (unless that includes availability). As mentioned above, all the proofs are posted to the public bulletin board.

6. Yes, it includes the printer. The only way the entire process is end-to-end verifiable is if the tally of the printed ballots that come out of the air gap is compared to, and matches, the tally of the decrypted ballots, which are posted to the bulletin board with the decryption and mixing proofs. If this is not done - for whatever reason - the "end" of the end-to-end verifiability in the current protocol is the set of decrypted ballots on the bulletin board, not the paper ballots.

7. At the protocol level, the privacy and verifiability of the system is intended to be roughly equivalent to the SwissPost and Belenios systems. All three systems involve different groups of participants and direct comparison is not possible, however the following general remarks hold:

   • Universal Verifiability: We achieve universal verifiability using the same techniques (with the same limitations) as Helios and Belenios; this is better than SwissPost because public verification is possible.
   • Privacy: The core techniques (and limitations) for privacy are equivalent to Helios, Belenios, and SwissPost though the current implementation requires an honest majority of trustees for privacy; this can be strengthened by changing the distributed key generation protocol.
   • Eligibility Verifiability: We provide stronger eligibility verifiability than SwissPost but weaker than Belenios because ballots are authorised by a single credential.
   • Individual Verifiability: We provide cast-as-intended verifiability using a similar mechanism to the Estonian IVXV system.