OpenVote

3,104 views

Published on

The most advanced technology virtual trip has ever developed - still a failure story from a business point of view

0 Comments
0 Likes
Statistics
Notes
  • Be the first to comment

  • Be the first to like this

No Downloads
Views
Total views
3,104
On SlideShare
0
From Embeds
0
Number of Embeds
856
Actions
Shares
0
Downloads
20
Comments
0
Likes
0
Embeds 0
No embeds

No notes for slide

OpenVote

  1. 1. OpenVote™ Secure Internet Voting System By VIRTUAL TRIP
  2. 2. Contributors <ul><li>Periklis Akritidis </li></ul><ul><ul><li>Institute of Computer Science – FORTH </li></ul></ul><ul><ul><li>[email_address] </li></ul></ul><ul><li>Vangelis Mihalopoulos, Nikos Ventouras, Yiannis Hatzikian, Dimitris Tsigos </li></ul><ul><ul><li>VIRTUAL TRIP </li></ul></ul><ul><ul><li>{mihalop, venturas, hatzikia, tsigos}@vtrip.net </li></ul></ul><ul><li>Manos Dramitinos </li></ul><ul><ul><li>Athens University of Economics and Business </li></ul></ul><ul><ul><li>[email_address] </li></ul></ul>
  3. 3. Background <ul><li>Project started in 1999 as a personal research project by Periklis Akritidis </li></ul><ul><li>VIRTUAL TRIP funded the project since September 2000 </li></ul><ul><ul><li>New architecture, new implementation </li></ul></ul><ul><li>First version released in April 2001 </li></ul><ul><li>Final version published under GPL in May 2003 </li></ul>
  4. 4. Synopsis
  5. 5. What: <ul><li>Secure Internet voting </li></ul><ul><li>Computerized analog to traditional absentee voting </li></ul><ul><li>Not exact analog to traditional paper ballot voting with booths </li></ul>
  6. 6. Why: <ul><li>Secure </li></ul><ul><ul><li>Traditional absentee voting is insecure </li></ul></ul><ul><li>Convenient </li></ul><ul><ul><li>Vote from home or work </li></ul></ul><ul><li>Cost effective </li></ul><ul><ul><li>Geographically distributed elections </li></ul></ul><ul><ul><li>Long running elections </li></ul></ul>
  7. 7. Certificates: <ul><li>Identification is a requirement for all elections </li></ul><ul><li>E-voting users must obtain digital certificates </li></ul>
  8. 8. Interoperability: <ul><li>The system understands the PKCS#12 key storage format </li></ul><ul><li>Both popular browsers export keys in this format </li></ul>
  9. 9. Talliers: <ul><li>Talliers are participants responsible for tabulating the votes without compromising privacy </li></ul>
  10. 10. Vote Privacy: <ul><li>No single party other than the voter can compromise it </li></ul><ul><li>Maintained against collusions of talliers up to a threshold </li></ul>
  11. 11. Receipts: <ul><li>Disputes over message delivery are resolved using receipts </li></ul>
  12. 12. Universal Verifiability: <ul><li>Even passive observers can verify the results long after the election </li></ul>
  13. 13. Operator: <ul><li>Responsible for service availability </li></ul><ul><li>Cannot compromise vote privacy </li></ul><ul><li>Cannot forge the results without being detected </li></ul><ul><li>Can be a service provider </li></ul>
  14. 14. Multiple Elections:
  15. 15. Flexible Custom Ballots:
  16. 16. The OpenVote platform
  17. 17. Java plugin <ul><li>The programming platform used for OpenVote is the Java plugin by Sun </li></ul><ul><ul><li>Allowing multiple experts who have individually evaluated the code to sign it </li></ul></ul><ul><ul><ul><li>increasing trust in that code </li></ul></ul></ul><ul><li>Support for PKCS12 keystores </li></ul><ul><ul><li>Used by Internet Explorer and Netscape Navigator for their exported private keys </li></ul></ul><ul><ul><ul><li>Simplifies the use of the existing public key infrastructure (PKI) </li></ul></ul></ul>
  18. 18. Relational database <ul><li>A relational database is used at the back end for data storage </li></ul><ul><ul><li>The system is loosely coupled to the underlying database, however transactional capabilities are required </li></ul></ul>
  19. 19. Protocols <ul><li>An important component of an internet voting system is the underlying cryptographic secure voting protocol </li></ul><ul><li>A voting protocol is defined as a set of sub-protocols that allow a set of voters to cast their votes securely and with privacy, while enabling a set of talliers to compute and communicate the final tally that is verified by a set of observers </li></ul><ul><ul><li>These sets need not be disjoint sets </li></ul></ul><ul><li>These fundamental requirements of privacy and integrity must be addressed by the protocol. </li></ul>
  20. 20. Protocol types
  21. 21. Mixing protocols <ul><li>Mixing protocols are based on voters mixing each other's votes so that no one can associate a vote with a voter </li></ul><ul><li>There are no separate talliers or observers </li></ul><ul><li>These protocols are impractical for elections with more than a handful of voters </li></ul>
  22. 22. Blind signatures <ul><li>Use of an anonymous channel to cast ballots preventing association of votes and voters </li></ul><ul><li>Authentication is preserved through the use of blind signatures </li></ul><ul><li>Blind signatures allow a document to be signed without revealing its contents and were originally used for untraceable digital cash </li></ul><ul><li>These protocols are very flexible and even allow write-in options </li></ul>
  23. 23. Protocols based on homomorphism <ul><li>Protocols where individual votes are split up among different tallying authorities so that no single one of them can compromise the privacy of an individual voter </li></ul><ul><li>These protocols are based on homomorphic encryption and homomorphic secret sharing and allow for universal verifiability </li></ul><ul><li>Used by OpenVote </li></ul>
  24. 24. The Protocol Used by OpenVote <ul><li>OpenVote uses a protocol based on homomorphism </li></ul><ul><ul><li>introduces publicly verifiable secret sharing </li></ul></ul><ul><ul><li>makes it more robust and convenient than earlier protocols </li></ul></ul><ul><li>The protocol used assumes the availability of a so-called bulletin board </li></ul><ul><ul><li>in which each entity can post a message exclusively to its own section </li></ul></ul><ul><ul><li>cannot erase or overwrite previously posted messages </li></ul></ul>
  25. 25. The OpenVote voting process <ul><li>Voters cast their votes by posting ballots to the bulletin board </li></ul><ul><li>The ballot does not reveal any information on the vote itself </li></ul><ul><ul><li>its validity is ensured by an accompanying proof that the ballot contains a valid vote </li></ul></ul>
  26. 26. Talliers <ul><li>Talliers compute the final tally from an accumulation of the valid ballots </li></ul><ul><li>Privacy of individual votes is ensured against coalitions of talliers up to a configurable threshold t </li></ul><ul><li>Robustness against n-t faulty talliers is also maintained </li></ul>
  27. 27. Observers <ul><li>The final tally can be verified by any observer against the accumulation of the valid ballots </li></ul><ul><ul><li>the protocol provides for universal verifiability </li></ul></ul>
  28. 28. Multi-way extensions <ul><li>The chosen protocol performs yes/no elections </li></ul><ul><li>Virtual Trip has extended the protocol to support multi-way elections by encoding A-out-of-Q options into Q, 1-out-of-2 options and tallying the votes for each option separately </li></ul><ul><li>To restrict voting for more than A options, the Q encrypted votes are accompanied by an appropriate proof of validity </li></ul>
  29. 29. The OpenVote bulletin board implementation
  30. 30. Bulletin board model <ul><li>All communication through the bulletin board is public and can be read by any entity </li></ul><ul><ul><li>including passive observers </li></ul></ul><ul><li>No entity can erase any information from the bulletin board </li></ul><ul><ul><li>but all active participants can append messages to their own designated section </li></ul></ul>
  31. 31. Digital signatures <ul><li>Digital signatures are used to control access to the various sections of the bulletin board </li></ul><ul><li>This realises the requirement of limiting each entity's messages to its own section </li></ul>
  32. 32. Replicated servers <ul><li>By postulating that all participants can append messages only to their section, it is implicitly assumed that denial-of-service attacks are excluded </li></ul><ul><li>This, together with the write-once requirement can be realised by designing the bulletin board as a set of replicated servers implementing Byzantine agreement </li></ul><ul><li>Such a system is described in M. Reiter: The Rampart toolkit for building high-integrity services. We do not use this approach. </li></ul>
  33. 33. Receipts <ul><li>We approximate the ideal bulletin board by using receipts </li></ul><ul><li>The bulletin board issues digital signatures for each transaction </li></ul><ul><li>The transaction is considered committed by the entity performing it only after the receipt and verification of a digital signature of the exchanged messages </li></ul><ul><li>Thus failure to post a message can be immediately detected and dealt with </li></ul><ul><li>In the case of a dispute about the delivery of a message (e.g. vote dropping), the involved entity can present the receipt and challenge the bulletin board to present the corresponding messages. </li></ul>
  34. 34. Malicious voters <ul><li>A malicious voter may pretend to lose his or her vote, and claim it was the server's fault in order to ‘frame’ the server </li></ul><ul><li>However, it would take a co-ordinated effort among many voters to truly cast suspicion on the voting process in this manner, which is unlikely </li></ul><ul><li>The amount of complaints can be used as an indication of the validity of the election </li></ul>
  35. 35. The OpenVote Voter/Tallier implementation
  36. 36. Client model <ul><li>Both the voters and the talliers are implemented as client programs accessing the bulletin board, which acts as a server </li></ul><ul><li>A party must completely trust the system on which these programs are executing on his behalf as well as their code </li></ul><ul><li>Sensitive information is never leaked outside these programs unencrypted </li></ul>
  37. 37. TCB <ul><li>Trust in the system is achieved by using the user's own computer to execute the client programs </li></ul><ul><li>It is the responsibility of the user to maintain the security of his computer </li></ul>
  38. 38. Private keys <ul><li>The client program has access to the user's private key in order to post messages to the bulletin board server </li></ul><ul><li>The key is stored in password protected PKCS12 format on the client machine, as exported by the user's browser </li></ul><ul><li>To allow this kind of access one must either deploy the program as a signed applet, or install it locally on the client machine </li></ul>
  39. 39. Sensitive input <ul><li>Care must be taken for sensitive input such as a vote </li></ul><ul><li>Applet input is not considered a privileged operation by the Java plugin and this could be exploited if regular use of the system was through an applet </li></ul><ul><ul><li>A malicious (even unsigned) applet could disguise as a voting client program </li></ul></ul><ul><li>To prevent this we use a special way to deploy the client program </li></ul>
  40. 40. Deployment <ul><li>To enable the use of the system on a machine, the user invokes a signed applet that will install the client program on the user's machine </li></ul><ul><li>This operation is considered privileged and the signers of the applet are clearly indicated to the user while asked for permission </li></ul><ul><li>For regular use, the user invokes the program directly from his or her machine. This ensures that the executed program is the intended one </li></ul>
  41. 41. Multiple code signers <ul><li>To increase trust in the code of the client program, multiple experts have evaluated and digitally signed the code </li></ul><ul><li>Recall that this is possible using the Java plugin's applet signing mechanisms </li></ul>
  42. 42. Deployment as a service
  43. 43. System structure <ul><li>Both talliers and voters are clients of the bulletin board </li></ul><ul><li>The bulletin board is the only component that is required to be constantly online </li></ul>
  44. 44. Business model <ul><li>This leads to a straightforward model for the deployment of the system as a service: </li></ul><ul><ul><li>The bulletin board will provide its services for groups of voters and talliers recognised by those voters, to perform remote internet elections </li></ul></ul>
  45. 45. Thank you 

×