Civitas Toward a Secure Voting System

Document Sample
Civitas Toward a Secure Voting System Powered By Docstoc
					                             Civitas
    Toward a Secure Voting System


Michael Clarkson, Stephen Chong, Andrew Myers
               Cornell University

       IEEE Symposium on Security and Privacy
                   May 21, 2008




     Coin Crawford 413, ca. 63 B.C., commemorates secret ballot introduced 137 B.C.
State of Secure Electronic Voting

    • Major commercial voting systems are
      insecure
         – California top-to-bottom reviews [Wagner,
           Wallach, Blaze, et al.]


    • Much pessimism about secure voting
         – SERVE report [Jefferson et al.]


    • How secure a voting system can we build?

Clarkson: Civitas                                      2
Civitas

    • Civitas: Electronic voting system we built
         – Publicly available
         – 21,000 LOC (Jif, Java, and C)


    • Started with abstract voting protocol<
         – Extended design to improve security and
           performance
         – Implemented in security-typed language (Jif)
         – Evaluated security and performance


Clarkson: Civitas                                         3
Caveat

    • This work is about advancing the science<
         – Not about selling a particular system


    • Civitas isn’t suitable for running a national
      election (yet)




Clarkson: Civitas                                     4
               Civitas Security Requirements




Clarkson: Civitas                              5
Security Model
    • No trusted supervision of polling places
         – Including voters, procedures, hardware, software
         – Voting could take place anywhere
         – Thus, remote voting
              • Generalization of “Internet voting” and “postal voting”

    • Interesting problem to solve:
         – More general than supervised voting
         – Trusted supervision is the source of many
           vulnerabilities
         – Trend toward remote interactions
              • Public elections (absentee ballots, Oregon, Washington,
                Estonia)
              • Organizational elections (Debian, ACM, IEEE—all on Internet)



Clarkson: Civitas                                                              6
Security Model
    • Adversary
         – May corrupt all but one of each type of election
           authority
              • Agents who conduct the election
         – May coerce voters, demanding secrets or behavior,
           remotely or physically
              • But voter isn’t under constant surveillance
         – May control network
              • With one exception during registration
         – May perform any polynomial time computation

    • Security properties
         – Strong, in tension
         – Confidentiality, integrity, availability<


Clarkson: Civitas                                              7
Integrity
        Verifiability:
            The final tally is correct and verifiable.


        Including:
         – Voter verifiability: Voters can check that their
           own vote is included
         – Universal verifiability: Anyone can check
           that only authorized votes are counted, no
           votes are changed during tallying [Sako and
           Killian 1995]

Clarkson: Civitas                                             8
Confidentiality

    • Voter coercion
         – Employer, spouse, etc.
         – Coercer can demand any behavior
              • Particular vote, random vote, abstain
              • Generalizes vote buying
         – Coercer can observe and interact with voter
           during remote voting


    • Must prevent coercers from trusting their
      own observations

Clarkson: Civitas                                        9
Confidentiality

        Coercion resistance:
           The adversary cannot learn how voters vote,
            even if voters collude and interact with the
                             adversary.



        Stronger than receipt-freeness, which is
        stronger than anonymity
         – [Delaune, Kremer, and Ryan]
         – Which are too weak for remote voting
Clarkson: Civitas                                          10
Availability

        Tally availability:
              The final tally of the election is produced.



    • We assume that this holds
    • To guarantee, would need to make system components
      highly available
         – Use reliable systems techniques
              • Byzantine fault tolerance, threshold cryptography
         – Civitas designed, but not implemented, with this in mind
    • We do not assume that votes remain available


Clarkson: Civitas                                                     11
                    Civitas Voting Scheme




Clarkson: Civitas                           12
JCJ Scheme
    • Civitas is based on JCJ scheme
         – [Juels, Catalano, and Jakobsson, WPES 2005]
    • JCJ:
         – Formally defined coercion resistance and verifiability
         – Constructed voting scheme
              • Not implemented
         – Proved scheme satisfies coercion resistance and
           verifiability
              • I won’t discuss why it works in this talk
    • Verified in ProVerif [Backes, Hritcu, and Maffei,
      CSF 2008]


Clarkson: Civitas                                                   13
JCJ Protocol Architecture

 Issue credentials

       registrar                        tabulation teller

                                                             Tabulate,
                             bulletin   tabulation teller
                              board
                                                             using mix
                                                             network
              voter
              client                    tabulation teller


     Verifiability:                          Coercion resistance:
     Tellers post zero-knowledge              Voters can undetectably
     proofs during tabulation                         fake credentials


Clarkson: Civitas                                                        14
Problem #1



       registrar                  tabulation teller


                       bulletin   tabulation teller
                        board
              voter
              client              tabulation teller




Clarkson: Civitas                                     15
Problem #1: Trusted Registrar

    • JCJ: Trusts single agent to issue credentials
      to voters
         – Could violate coercion resistance
         – Could vote on behalf of voters


    • Civitas: Distributes trust over set of
      registration tellers
         – We extended JCJ security proof to prove
           Civitas is still coercion resistant


Clarkson: Civitas                                     16
Distributed Registrar


 registration
  registration
    teller
   registration
      teller                      tabulation teller
       teller

                       bulletin   tabulation teller
                        board
              voter
              client              tabulation teller




Clarkson: Civitas                                     17
Civitas Registration Protocol


           registration       registration          registration
              teller             teller                teller



   credential share


                                  voter
                                  client

                                             also: designated-verifier ZK
                                               proof to convince voter
                          credential          without allowing transfer
                                                     of credential
Clarkson: Civitas                                                       18
Problem #2


 registration
  registration
    teller
   registration
      teller                      tabulation teller
       teller

                       bulletin   tabulation teller
                        board
              voter
              client              tabulation teller




Clarkson: Civitas                                     19
Problem #2: Vote Storage
    • JCJ: Trusts single bulletin board to store all the
      votes
         – Could lose votes
              • Unavailable votes not universally verifiable
              • So implement with BFT<?
         – Could scale poorly


    • Civitas: Distributes vote storage over set of ballot
      boxes

        Vote availability:
                    Votes are available for tabulation.
Clarkson: Civitas                                              20
Distributed Vote Storage


 registration
   registration
      registration
    teller
       teller                         tabulation teller
          teller

                       ballot box     tabulation teller   bulletin
                        ballot box
                         ballot box                        board
              voter
              client                  tabulation teller




Clarkson: Civitas                                                    21
Civitas Vote Storage Protocol


                                                       tabulation teller
                           ballot box


     voter                 ballot box
     client                                            tabulation teller
                                          Transmit
                                          all votes
                           ballot box   using simple
                                        commitment     tabulation teller
                                          protocol



                    Win: Vote availability, scales easily
Clarkson: Civitas                                                      22
Problem #3


 registration
   registration
      registration
    teller
       teller                         tabulation teller
          teller

                       ballot box     tabulation teller   bulletin
                        ballot box
                         ballot box                        board
              voter
              client                  tabulation teller




Clarkson: Civitas                                                    23
Problem #3: Tabulation Scalability

    • JCJ: Tabulation protocol is quadratic in
      number of voters

    • Civitas: Divide voters into blocks
         – Block is a “virtual precinct”
              • Each voter assigned to one block
              • Each block tallied independently of other blocks,
                even in parallel




Clarkson: Civitas                                                   24
Blocks

    Tabulation time is:

         – Quadratic in block size

         – Linear in number of voters
              • If using one set of machines for many blocks


         – Or, constant in number of voters
              • If using one set of machines per block



Clarkson: Civitas                                              25
Blocks
    • Coercion resistance
         – Voters no longer anonymous within whole population
         – But still anonymous within block
         – Also true in real precincts


    • Assignment to blocks
         – Based on physical location
              • Leads to risk of reprisal, as in real precincts
         – Based on random assignment
              • Mitigates risk
              • Made possible by remote voting



Clarkson: Civitas                                                 26
                    Civitas Implementation




Clarkson: Civitas                            27
Protocols

    • JCJ: Un- or partially-specified
         – Implementation requires concrete protocols


    • Civitas: Full protocol details, and code
         – Uses many protocols from the literature:
              •     El Gamal; distributed [Brandt]; non-malleable [Schnorr and Jakobsson]
              •     Proof of knowledge of discrete log [Schnorr]
              •     Proof of equality of discrete logarithms [Chaum & Pederson]
              •     Authentication and key establishment [Needham-Schroeder-Lowe]
              •     Designated-verifier reencryption proof [Hirt & Sako]
              •     1-out-of-L reencryption proof [Hirt & Sako]
              •     Signature of knowledge of discrete logarithms [Camenisch & Stadler]
              •     Reencryption mix network with randomized partial checking [Jakobsson, Juels & Rivest]
              •     Plaintext equivalence test [Jakobsson & Juels]




Clarkson: Civitas                                                                                           28
Secure Implementation
    • Civitas implemented in Jif
        Java + Information Flow [Myers 1999, Chong and Myers 2005, 2008]
         – Security-typed language
         – Types contain information-flow policies
              • Policies express confidentiality and integrity requirements on
                information
         – Jif compiler and runtime enforce policies


    • If policies in code express correct requirements<
         – (And Jif compiler is correct<)
         – Then code is secure w.r.t. requirements


Clarkson: Civitas                                                                29
Civitas Policy Examples
    • Confidentiality:
         – Information: Voter’s credential share
         – Policy: “RT permits only this voter to learn this information”
         – Jif syntax: RT  Voter

    • Confidentiality:
         – Information: Teller’s private key
         – Policy: “TT permits no one else to learn this information”
         – Jif syntax: TT  TT

    • Integrity:
         – Information: Random nonces used by tellers
         – Policy: “TT permits only itself to influence this information”
         – Jif syntax: TT  TT



Clarkson: Civitas                                                           30
Civitas Policy Examples
    • Declassification:
         – Information: Bits that are committed to then revealed
         – Policy: “TT permits no one to read this information
           until all commitments become available, then TT
           declassifies it to allow everyone to read.”
         – Jif syntax: TT  [TT commAvail  ]

    • Erasure:
         – Information: Voter’s credential shares
         – Policy: “Voter requires, after all shares are received
           and full credential is constructed, that shares must be
           erased.”
         – Jif syntax: Voter  [Voter credConst T ]


Clarkson: Civitas                                                    31
Civitas LOC
    Component                    Approx.
                                   LOC
    Tabulation teller              5,700

    Registration teller            1,300   Policy            Distinct
                                                             annota-
    Bulletin board, ballot box       900                       tions
                                           Confidentiality        20
    Voter client                     800

    Other (incl. common code)      4,700
                                           Integrity              26
    Total Jif LOC                 13,400

    Low-level crypto and I/O       8,000
    (Java and C)
    Total LOC                     21,400

Clarkson: Civitas                                                       32
                    Evaluation: Civitas Security




Clarkson: Civitas                                  33
Civitas Trust Assumptions
    1.     DDH, RSA, random oracle model.

    2.     The adversary cannot masquerade as a voter during
           registration.

    3.     At least one of each type of authority is honest.

    4.     Each voter has an untappable channel to a trusted
           registration teller.

    5.     Voters trust their voting client.

    6.     The channels from the voter to the ballot boxes are
           anonymous.


Clarkson: Civitas                                                34
Civitas Trust Assumptions
    1.     DDH, RSA, random oracle model.

    2.     The adversary cannot masquerade as a voter during
           registration.

    3.     At least one of each type of authority is honest.

    4.     Each voter has an untappable channel to a trusted
           registration teller.

    5.     Voters trust their voting client.

    6.     The channels from the voter to the ballot boxes are
           anonymous.


Clarkson: Civitas                                                35
Registration Trust Assumptions
    • One way to discharge is with in-person registration
         – Not an absolute requirement
              • Though for strong authentication, physical presence (“something you
                are”) is reasonable
         – Need not register in-person with all tellers

    • Works like real-world voting today:
         – Registration teller trusted to correctly authenticate voter
         – Issue of credential must happen in trusted “registration booth”
         – But doesn’t need to happen on special day

    • Con: System not fully remote
    • Pro: Credential can be used remotely for many elections

    • Insight: Reusing real-world mechanism, can bootstrap
      into a system offering stronger security

Clarkson: Civitas                                                                     36
Civitas Trust Assumptions
    1.     DDH, RSA, random oracle model.

    2.     The adversary cannot masquerade as a voter during
           registration.

    3.     At least one of each type of authority is honest.

    4.     Each voter has an untappable channel to a trusted
           registration teller.

    5.     Voters trust their voting client.

    6.     The channels from the voter to the ballot boxes are
           anonymous.


Clarkson: Civitas                                                37
Voting Client Trust Assumption
    • Civitas voting client is not a DRE
         – Voters are not required to trust a single (closed-
           source) implementation
         – Civitas allows open-source
           (re)implementations of the client
         – Voters can obtain or travel to implementation
           provided by organization they trust


    • Possibility to discharge:
         – Distribute trust in client
            *Benaloh, Chaum, Joaquim and Ribeiro, Kutyłowski et al.,
            Zúquete et al., <+

Clarkson: Civitas                                                      38
                        Evaluation:
               Civitas Cost and Performance




Clarkson: Civitas                             39
Real-World Cost
    • Society makes a tradeoff on
         – Cost of election, vs.
         – Security, usability, <

    • Current total costs are $1-$3 / voter
        [International Foundation for Election Systems]

    • We don’t know the total cost for Civitas
         – But with our implementation, we can
           investigate one piece:
              • Computational cost of employing cryptography

Clarkson: Civitas                                              40
Tabulation Time vs. Anonymity




                            # voters = K, # tab. tellers = 4,
                    security strength ≥ 112 bits *NIST 2011–2030]
Clarkson: Civitas                                                   41
Tabulation Time vs. # Voters


                              sequential




                               parallel




                    K = 100
Clarkson: Civitas                          42
CPU Cost for Tabulation

    • CPU time is 39 sec / voter / authority
         – If CPUs are bought, used (for 5 hours), then
           thrown away:
              • $1500 / machine = $12 / voter
         – If CPUs are rented:
              • $1 / CPU / hr = 4¢ / voter


    • For this extra cost, we get increased
      security


Clarkson: Civitas                                         43
                    Ranked Voting




Clarkson: Civitas                   44
Ranked Voting Methods
    • Voters submit ranking of candidates
         – E.g. Condorcet, Borda, STV
         – Help avoid spoiler effects
         – Defend against strategic voting

    • Tricky because rankings can be used to signal
      identity (“Italian attack”)

    • Civitas implements coercion-resistant Condorcet,
      approval and plurality voting methods
         – Could do any summable method
         – New construction [in TR] for efficient Condorcet
           tabulation
              • Based on homomorphic encryption

Clarkson: Civitas                                             45
                    Conclusion




Clarkson: Civitas                46
Summary
    • Civitas is an implemented remote voting system

    • Civitas contributes to:
         – Protocols (theory of voting):
              • Distributed trust in registration for confidentiality
              • Distributed vote storage for availability
              • Introduced blocks (virtual precincts) for scalability
              • Articulated and analyzed trust assumptions
              • Efficient coercion-resistant Condorcet voting
         – Systems (practice of voting):
              • Developed full protocols
              • Implemented system
              • Studied performance

Clarkson: Civitas                                                       47
Related Work
    • Abstract voting schemes:
             [Adida and Rivest; Baudron et al.; Benaloh; Benaloh and Tuinstra; Boyd; Chaum; Chaum, Ryan, and Schneider Chen and
             Burminster; Cohen and Fischer; Cramer, Gennaro, and Schoenmakers; Fujioka, Okamoto, and Ohta; Hirt and Sako; Iversen; Kiayia s
             and Yung; Magkos et al.; Merrit; Neff; Niemi and Renvall; Sako and Killian; Ohkubo et al.; Ohta; Okamoto; Park et al.; Rivest ]


             <

    • Implemented voting systems:
         –   Adder [Kiayias, Korman, Walluck]
         –   ElectMe [Shubina and Smith]
         –   EVOX [Herschberg, DuRette]
         –   Prêt à Voter [Schneider, Heather, et al.; Ryan; Chaum]
         –   Punchscan [Stanton, Essex, Popoveniuc, et al.; Chaum]
         –   REVS [Joaquim, Zúquette, Ferreira; Lebre]
         –   Sensus [Cranor and Cytron]
         –   VoteHere [Neff]
         –   W-Voting *Kutyłowski, Zagórski, et al.+
         –   Civitas: Strongest coercion resistance, first to offer security
             proofs plus information-flow analysis
Clarkson: Civitas                                                                                                                              48
Web Site
      http://www.cs.cornell.edu/projects/civitas


    • Technical report with concrete protocols
    • Source code of our prototype




Clarkson: Civitas                                  49
                              Civitas
     Toward a Secure Voting System


http://www.cs.cornell.edu/projects/civitas


 Michael Clarkson, Stephen Chong, Andrew Myers
                Cornell University




      Coin Crawford 413, ca. 63 B.C., commemorates secret ballot introduced 137 B.C.
Extra Slides




Clarkson: Civitas   51
Unresolved Issues

    • Distribute trust in voter client
    • Eliminate in-person registration
         – Still need untappable channel
    • Study credential management
         – UI for faking
    • Implement high availability
         – App-level DOS is a problem.
              • Improve performance/anonymity trade-off
              • Replace plaintext equivalence tests with group
                signatures? [Traore and Araujo 2007]

Clarkson: Civitas                                                52
Paper
    • What paper does:
         – Convince voter that his vote was captured correctly
    • What paper does next:
         – Gets dropped in a ballot box
         – Immediately becomes insecure
              • Chain-of-custody, stuffing, loss, recount attacks<
              • Hacking paper elections has a long and (in)glorious tradition
                [Steal this Vote, Andrew Gumbel, 2005]
              • 20% of paper trails are missing or illegible [Michael Shamos,
                2008]
    • What paper doesn’t:
         – Guarantee that a vote will be counted
         – Guarantee that a vote will be counted correctly


Clarkson: Civitas                                                               53
Cryptography

    • “The public won’t trust cryptography.”
         – It already does<
         – Because experts already do


    • “I don’t trust cryptography.”
         – You don’t trust the proofs, or
         – You reject the hardness assumptions




Clarkson: Civitas                                54
Resisting Coercion

    • Key idea:

                    Voters invent fake credentials

    • To adversary, fake  real

    • Votes with fake credentials are removed
      during tabulation


Clarkson: Civitas                                    55
Resisting Coercion
    If the adversary demands    Then the voter…
    that the voter…


    Submits a particular vote   Does so with a fake
                                credential.


    Sells or surrenders a       Supplies a fake credential.
    credential


    Abstains                    Supplies a fake credential to
                                the adversary and votes with
                                a real one.

Clarkson: Civitas                                               56
Selling Votes

        Requires selling credential<
         – Which requires:
              •Adversary tapped the untappable channel,
               or
              •Adversary authenticated in place of voter<
         – Which requires:
              •Voter transferred ability to authenticate to
               adversary; something voter<
                    – Has: too easy
                    – Knows: need incentive not to transfer
                    – Is: hardest to transfer
Clarkson: Civitas                                             57