NeSC Edinburgh

1
Socio-technical Trade-offs in Cryptographic
Voting Schemes

Peter Y A Ryan University of Newcastle
2
Introduction

• Designing dependable, trustworthy e-voting
  systems is vastly challenging
• Want high-assurance of accuracy whilst
  maintaining ballot secrecy.
• Minimal trust in components, officials, suppliers
  etc.
• Ideally, trust should ultimately rest on the
  electorate themselves.
• Must be useable and understandable by the
  electorate at large.
• Probably impossible to achieve all of these
  simultaneously, hence trade-offs need to be
  investigated and evaluated.
• Tension between making the system as simple as
  possible for voters (vote and go) on the one
  hand and ensuring that trust rests ultimately on
  the voters.

3
Outline

• Overview of Prêt à Voter Classic.
• Outline of some vulnerabilities with Prêt à Voter
  Classic.
• Enhancements to counter these vulnerabilities.
• Trade-offs.
• Conclusions.

4
Typical Prêt à Voter Classic Ballot Sheet
5
Voter marks their choice
6
Voters Ballot Receipt
7
Remarks

• Order of candidates is randomised for each ballot
  form, hence the receipt reveals nothing about the
  vote.
• Vote is not directly encrypted, rather the frame
  of reference, i.e., the candidate list, is
  randomised and information defining the frame is
  encrypted.
• Voter does not need to communicate their vote to
  the device.
• Vote casting (of the receipt) could be in the
  presence of an official.
• Signatures (digital and physical?) could be
  applied.
• A paper audit trail mechanism could be
  incorporated (similar to VVPAT but recording
  encrypted receipts).
• Works for ranked, approval, STV etc.

8
Tabulation

• All cast receipts are posted to a secure Web
  Bulletin Board (WBB). A sort of virtual sports
  hall.
• A set of tellers now perform an anonymising
  mix/decryption on the posted receipts.
• Outputs of each phase of the mix are also posted
  to the WBB.
• Final column shows decrypted votes.

9
What can go wrong

• For the accuracy requirement
• Ballot forms may be incorrectly constructed,
  leading to incorrect encoding of the vote.
• Ballot receipts could be corrupted before they
  are entered in the tabulation process.
• Tellers may perform the mix/decryption
  incorrectly.
• In this talk I will concentrate on the first of
  these.

10
Auditing ballot forms

• Authority generates and prints a large number
  of ballot forms.
• Random audits before, during and after the
  election period by independent authorities (and
  possibly the voters themselves).
• To check the construction of the ballot forms the
  values on the form, onion and candidate ordering,
  can be reconstructed if the seed value is
  revealed.
• Use the tellers in an on-demand mode to reveal
  the secret seed value buried in the onion. Avoids
  problems with storing and selectively revealing
  seeds.

11
Advantages of Prêt à Voter

• Voter experience simple and familiar.
• No need for voters to have personal keys or
  computing devices.
• Ballot form commitments and checks made before
  election opens ? neater recovery strategies.
• Votes are not directly encrypted, just the frame
  of reference in which votes encoded. Hence
• The vote recording device doesnt get to learn
  the vote.
• No need for ZK proofs of correctly formed
  encrypted receipts or cut-and-choose protocols.
  (but onus of proof shifts to the well-formedness
  of the ballot forms).
• Avoids subliminal channels, side channels and
  social engineering attacks.

12
Vulnerabilities

• Need to trust The Authority (for secrecy).
• Need to trust the auditors (absence of
  collusion).
• Need to protect ballot form information (chain of
  custody).
• Chain voting.
• Enforcing the destruction of LH strips.
• Need to constrain the WBB audits, i.e., reveal
  only L or R links.
• Separation of teller modes, i.e., ensure that
  each ballot form is processed only once.

13
Distributed creation of ballot forms

• We would like to set things up so only the voters
  gets to see the onion/candidate list association.
  No single entity knows or controls the entropy.
• On-demand printing of ballot forms.
• This can be achieved with a pre-mix that
  mirrors the tabulation mixes of PàV Classic.
• Mixing is done under an extra layer of encryption
  that can be stripped off at the last moment.
• Can be adapted for remote variants.

14
Distributed generation of (ElGamal) onions

• An initial clerk generates a set of pairs of
  onions. Each pair has the same initial plaintext
  seed s
• ((?x, ?Rx.s), (?y, ?T y.s))
• These pairs are put through a set of
  re-encryption anonymising mixes
• ((?x?, ?Rx?.s?), (?y?, ?T y?. s?))
• i.e. a re-encryption and injection of fresh
  entropy to the seed value s.
• After a number of mixes
• ((?x?????, ?R x?????. s?????)), (?y?????, ?T
  y?????. s?????))
• These pairs can now be distributed in this form.
  The candidate list is hidden in this form. These
  could be randomly audited at this stage.

15
Revealing the ballot form

• The booth device can then decrypt the LH onion to
  give the candidate permutation ?
• (?, (?y?????, ?T y?????. s?????))
• Can be adapted to remote versions (use the
  Cornell protocol to convert the LH onion to be
  encrypted under the voter Vis PK.
• ((?x?????, ?Vi x?????. s?????)), (?y?????, ?T
  y?????. s?????))
• A similar construction is possible original RSA
  onions.
• ElGamal construction is suitable for
  re-encryption mixes during the tabulation/anonymis
  ing mix.

16
On-demand printing

• We can minimise chain voting and chain of custody
  problems by arranging the print ballot forms at
  the last moment, i.e., in the booth.
• Note subtle distinction between creating and
  printing.
• Use fresh, additional sources of entropy, e.g.,
  fibres in the paper, the voters themselves etc.
• The problem now is that we cant pre-audit
  pre-committed forms.

17
Post-auditing

• A possible solution is to re-introduce
  cut-and-choose element to the protocol along with
  post-auditing.
• Note Chaums original scheme suggested devices
  available at the polling station to check
  receipts. Probably retain this, in particular to
  check digital signatures and to spot problems
  early, but additionally perform checks on WBB
  posted data.

18
2 sided ballot forms
19
Vote selection

• Forms can be printed in the booth.
• Voter makes an arbitrary choice as to which side
  to use.
• They mark their cross (or ranking etc) against
  the candidate of choice as before.
• The other side is left blank.

20
Vote selection
21
Receipts
22
Discussion

• The unused side can now be checked for
  well-formedness (at the time of casting and later
  in the WBB).
• This avoids some of the vulnerabilities of PaV
  Classic but at the cost of re-introducing the
  social engineering Chaum/Neff vulnerabilities
  noted by Karlof et al.
• Note still no need for the voter to communicate
  their vote to the device, hence no
  subliminal/side channels etc.
• Also counters klepographic attacks.
• Note symmetry between the two sides!

23
Post-auditing

• Receipts could be checked again on exit from the
  polling stations.
• In addition, all the info would be posted to the
  WBB. The slip, unused side could be checked for
  well-formedness.
• Seeds revealed for the unused sides.
• Need mechanisms to prevent leakage of seeds for
  used sides, e.g., authorisation code on LHS?

24
Discussion

• This solution avoids a lot of the vulnerabilities
  of Classic, e.g., no need to trust the auditing
  authorities, but makes the protocol a little more
  complex for the voter. And may re-introduce the
  possibility of social-engineering attacks.

25
assisting the voter

• We could envisage a device to help the voter mark
  the form and destroy the LHS.
• But then we need to trust this to cheat in some,
  e.g., scanning the candidate list before
  destruction.

26
Conclusion

• Ideally we would like the trust to rest
  ultimately with the electorate.
• This seems to be impossible without involving the
  voters in the verification process.
• Compromisers and trade-offs are inevitable.
• Verify the election not the system.

27
Part II Remote Prêt à Voter

• Joint work with Michael Clarkson and Andrew
  Myers, Cornell.

28
Coercion resistance

• The voter should have no way to prove to the
  coercer which way they voted, even if they are
  prepared to cooperate with the coercer.
• Coercer can observe virtually all steps of the
  protocol, the WBB and even demand the voter to
  reveal keys, choose randomness etc, but the voter
  should be able to lie undetected.
• Need to postulate at least a window in which the
  voter can interact with the voting system
  unobserved.
• Need to assume that the voters private
  (authentication) key remains secret during
  registration phase?

29
Remote Prêt à Voter

• Naïve approach casting vote by just submitting
  an onion and index value. Open to coercion.
• More sophisticated, coercion resistant version (à
  la Juels et al and Clarkson, Myers) supply
  voters with a capability, onion and encrypted
  candidate list.
• Capabilities constructed like onions but with
  valid flag at the centre.
• Casting voter sends off a triple
• (index, onion, capability)
• Coerced voter can corrupt their capability.
  Invalidity only revealed after the anonymising
  mixes.
• Designated verifier proof (DVP) to convince the
  voter, and only the voter, of the validity of
  their capability.

30
Capabilities

• Construction similar to ElGamal onions, but
  with registrar signature on a valid string
  along with a nonce
• ?x(SigReg(valid, nonce))
• Delivered to the voters along with a
  non-interactive, designated verifier proof (DVP)
  of validity.
• Designed to go through the mix and be decrypted
  along with the associated ballot.
• Need to ensure that each voter gets exactly one
  valid capability.

31
Capabilities

• Ideally we would like to construct these
  capabilities in such a way that no single entity
  knows their values or the association with voter
  ids.
• We would also like to have the voters participate
  in their construction to counter official ballot
  stuffing, whilst preserving anonymity.
• At the moment it is not clear how to achieve this
  without some level of trust in a (distributed)
  registrar and some secure (e.g., anonymous)
  channel.
• Need to assume voters have private/public key
  pairs.

32
Capabilities

• Possible approach have a number of registrars
  generate fragments of the capability under a
  layer of encryption along with DVP proofs.
• Use suitable algebraic features to enable to
  voter to assemble these into a full capability in
  such a way that the sub DVPs entail the proof of
  the full capability.

33
ElGamal

• ElGamal encryption
• let ? be a generator of cyclic group, e.g., Zp,
  p a large prime. Choose k (2?k?p-2) and let ?
  ?k (mod p).
• p, ? and ? made public, k kept secret.
• (Randomised encryption) of m in 0, , p-1
• (?x, ?x.m) (y1, y2)
• Re-encryption
• (?xy, ?xy.m)
• Note same as directly encrypting m with
  randomisation xy.
• Decryption
• m y2 /y1k

34
Absorbing the index value

• The special form of Prêt à Voter receipts is
  slightly tricky. Could leave index values
  unchanged through the mixes, but the adversary
  can partition the mix.
• Alternative
• For simplicity consider just random cyclic shifts
  of the candidate list and single choice voting.
• Let s be the candidate list offset. For some
  suitable ?, encrypt ?, to form the onion
• (?x, ?x. ?-s) (y1, y2)
• A receipt pair can be transformed into a pure
  ElGamal form
• (r, ?x, ?x. ?-s) ? (?x, ?x. ?r-s)
• This can be put through a conventional
  re-encryption mix and the final (threshold)
  decryption yields the vote value directly.
• Need slightly more elaborate coding for full
  permutations.
• Note for STV, ranked etc, we can mix the ballot
  cells separately.

35
Well-formedness of ballot forms

• Pre-auditing of publicly committed ballot forms.
• Multiple onion ballot forms to allow for post
  auditing.

36
Future work

• On the current model
• Determine exact requirements.
• Formal analysis and proofs.
• Construct threat and trust models.
• Investigate error handling and recovery
  strategies.
• Develop a full, socio-technical systems analysis.
• Develop prototypes and run trials, e.g., e-voting
  games!
• Investigate public understanding, acceptance and
  trust.

37
Future work

• Beyond the current scheme
• Finalise remote, coercion resistant version
  (using capabilities).
• Re-encryption mixes.
• Establish minimal assumptions.
• Alternative sources of seed entropy Voters,
  optical fibres in the paper, quantum?
• Alternative robust mixes, e.g., ZK shuffle
  proofs.
• Quantum variants.

38
References

• David Chaum, Secret-Ballot receipts True
  Voter-Verifiable Elections, IEEE Security and
  Privacy Journal, 2(1) 38-47, Jan/Feb 2004.
• J W Bryans P Y A Ryan A Dependability Analysis
  of the Chaum Voting Scheme, Newcastle Tech
  Report CS-TR-809, 2003.
• J W Bryans P Y A Ryan, Security and Trust in a
  Voter-verifiable Election Scheme, FAST 2003.
• P Y A Ryan J W Bryans A Simplified Version of
  the Chaum Voting Scheme, Newcastle TR 2004
• P Y A Ryan, Towards a Dependability Case for the
  Chaum Voting Scheme, DIMACS June 2004.
• P Y A Ryan, E-voting, presentation to the
  Caltech/MIT workshop on voting technology, MIT
  Boston 1-2 October 2004.
• P Y A Ryan, A Variant of the Chaum
  Voter-verifiable Election scheme, WITS, 10-11
  January 2005 Long Beach Ca.
• D Chaum, P Y A Ryan, S A Schneider, A Practical,
  Voter-Verifiable Election Scheme, Newcastle TR
  880 December 2004, Proceedings ESORICS 2005, LNCS
  3679.
• B Randell, P Y A Ryan, Trust and Voting
  Technology, NCL CS Tech Report 911, June 2005,
  to appear IEEE Security and Privacy Magazine.
• P Y A Ryan, T Peacock, Prêt à Voter, A Systems
  Perspective, NCL CS Tech Report 929, September
  2005, submitted to IEEE Security and Privacy
  Symposium 2006.
• Clarkson and Myers, Coercion-resistant Remote
  Voting using Decryption Mixes, at FEE 2005.
  http//www.win.tue.nl/berry/fee2005/