Se ha denunciado esta presentación.
Utilizamos tu perfil de LinkedIn y tus datos de actividad para personalizar los anuncios y mostrarte publicidad más relevante. Puedes cambiar tus preferencias de publicidad en cualquier momento.

The road towards verifiable internet voting

Slides for my talk @EPFL on Jan 18th 2019:..

Abstract
The voting and election processes are the backbone of Swiss democracy and threats to those processes are not to be taken lightly. For this reason, the Federal Chancellery introduced new rules and requirements on Internet Voting systems back in 2014, defining thresholds on the availability of Internet Voting, subjected to three increasing compliance levels.
This talk will introduce some of the security properties defined in the federal requirements, and summarize the work done in collaboration between the eVoting group at the Berner Fachhochschule and the State of Geneva.
We will conclude with a brief overview of the state of the project and of the work that still remains to be done, focusing on the cryptographic protocol.

  • Inicia sesión para ver los comentarios

The road towards verifiable internet voting

  1. 1. 22/01/2019 - Page 1 Improvements to CHvote The road towards an end-to-end verifiable internet voting system Office cantonal des systèmes d'information et du numérique Département des infrastructures
  2. 2. 22/01/2019 - Page 2 Short Bio • EPFL MSc in IT • IT / Java consultant • Now Internet voting cryptography @ State of Geneva Java DEV & AppSec • Outside from work OWASP-Geneva co-chapter leader Married, 2 kids Thomas Hofer / @thhofer / thomas.hofer@etat.ge.ch
  3. 3. 22/01/2019 - Page 3 Outline Context Security properties and challenges Federal requirements Protocol overview State of the project Conclusion
  4. 4. 22/01/2019 - Page 4 Outline Context Security properties and challenges Federal requirements Protocol overview State of the project Conclusion
  5. 5. 22/01/2019 - Page 5 The past of CHvote First generation E-Voting system • 2001: start of project • 2003: first use • Partners
  6. 6. 22/01/2019 - Page 6 Context New Federal Requirements Version «1.5»: - Remove java applet - Add individual verifiability 12.2013 09.2015 06-09.2016 01.2017 V2.0: project preparation Project start 11.2018 Project terminated 04-05.2019 Expected publication date Timeline
  7. 7. 22/01/2019 - Page 7 Context Challenges Exigences fédérales de sécurité Protocole cryptographique Software as a service Federal requirements Individual and universal verifiability End-to-end encryption Independent control components Symbolic and cryptographic proofs Common Criteria EAL 2 et EAL 4 OWASP Code review SMSI, ISO 27001 Certification Internal and public penetration test Source code publication Cryptography Bespoke cryptographic protocol Strong performance requirements Several academic partners Implementation of less common cryptographic primitives Massively parallel computations Control Components Hardware 6x 26 cores x86 256 Go 2x 16 cores IBM Power 256 Go 30 TB «live» data 4 distinct OS + 3 distinct JRE implementations + 2 distinct CPU architectures BDD PostgreSQL high-availability Encrypted and signed communications 0-loss tolerance No remote access, dedicated physical access control 4 independent pairs of administration teams Open Source AGPL v3 License Publication forbidden before audits and certification Documentation targeted at external contributors Image risks (cherry-picking of issues) Software as a service Multi-tenant (cantons, languages, legal frameworks) Autonomous ballot organisation High-availability 24/7 usage, limited windows for maintenance Integrity and authenticity of data
  8. 8. 22/01/2019 - Page 8 Outline Context Security properties and challenges Federal requirements Protocol overview State of the project Conclusion
  9. 9. 22/01/2019 - Page 9 Security properties Target security properties Vote secrecy Result integrity No early tallyAvailability Voter authentication Enfranchisement
  10. 10. 22/01/2019 - Page 10 Security challenges • Vote secrecy vs. result integrity Cryptographically challenging (but feasible) • Enfranchisement vs. authentication Typically opposed But: in CH, voting legitimation cards are sent to voters (Swiss Post is trusted) For mail-in ballots / polling station voting: − Voting card + signature + DOB For internet voting: − Secrets printed on voting card + DOB Partially contradicting requirements and other challenges
  11. 11. 22/01/2019 - Page 11 Security challenges • Availability OK, but… DDOS?? Standard technical counter-measures Internet voting closes 24 hours before polling stations • DNS-cache poisoning (nov. 2018 news) Impacts everyone Some technical counter-measures in place, others coming Most importantly: certificate fingerprint printed on voting material Partially contradicting requirements and other challenges (ctd.)
  12. 12. 22/01/2019 - Page 12 Outline Context Security properties and challenges Federal requirements Protocol overview State of the project Conclusion
  13. 13. 22/01/2019 - Page 13 Federal requirements • Published in 2013, enacted 2014 Collaborative work between lawmakers, academia and operating staff • Compliance levels The higher the compliance, the more voters allowed • Reference https://www.bk.admin.ch/themen/pore/evoting/07979/index.html New Ordinance on Electronic Voting
  14. 14. 22/01/2019 - Page 14 Federal requirements Individual Verifiability Voters must receive proof that the server system has registered the vote as it was entered by the voter on the user platform – VEleS, art. 4
  15. 15. 22/01/2019 - Page 15 Federal requirements End-to-End Encryption Votes must not be stored or transmitted in unencrypted form at any time from being entered to tallying. – Technical and administrative requirements, section 3.3.4
  16. 16. 22/01/2019 - Page 16 Federal requirements Universal Verifiability For universal verification, the auditors receive proof that the result has been ascertained correctly. They must evaluate the proof in a observable procedure. – VEleS, art. 5 paragraph 4
  17. 17. 22/01/2019 - Page 17 Federal requirements Control Components The trustworthy part of the system includes either one or a small number of groups of independent components secured by special measures (control components). Their use must also make any abuse recognisable if per group only one of the control components works correctly and in particular is not manipulated unnoticed. – VEleS, art. 5, par. 6
  18. 18. 22/01/2019 - Page 18 Federal requirements • First level Individual verifiability Internet voting for up to 30% of voters • Second level Add certifying audit Internet voting for up to 50% of voters • Third level Add universal verifiability, control components and end-to-end encryption New certifying audit Internet voting for up to 100% of voters Compliance levels
  19. 19. 22/01/2019 - Page 19 Outline Context Security properties and challenges Federal requirements Protocol overview State of the project Conclusion
  20. 20. 22/01/2019 - Page 20 Protocol actors Stakeholders from the perspective of the cryptographic protocol Election officer Control components Bulletin Board Voting client VoterPrinting Authorities
  21. 21. 22/01/2019 - Page 21 Key cryptographic primitives • El Gamal homomorphic encryption • Oblivious Transfer for individual verifiability Cast-as-Intended Verification in Electronic Elections Based on Oblivious Transfer • Pedersen Commitments • Non-interactive Zero-Knowledge Proofs (ZKP) • Wikström’s Proof of a Shuffle A brief overview
  22. 22. 22/01/2019 - Page 22 Homomorphic encryption • Principles Operations performed on cipher texts Result visible on recovered plain texts Example: − Encrypt 2 − Multiply cipher text by 3 − Decrypt − Result is 6 • For this project: El Gamal encryption What is it?
  23. 23. 22/01/2019 - Page 23 Homomorphic encryption • Used for voter credentials Voter authentication • Used for encrypting the ballots Vote secrecy • Allows re-encryptions Useful for anonymizing when shuffling Vote secrecy • Allows for key sharing Control components each hold a key share Vote secrecy & result integrity How and why?
  24. 24. 22/01/2019 - Page 24 Oblivious Transfer • In short Server knows n secret messages Client allowed to retrieve k secret messages Server cannot know which messages the client asked for Perfect match for the verification codes issue! Vote secrecy & Result integrity • In detail Cast-as-Intended Verification in Electronic Elections Based on Oblivious Transfer What does it mean and why is it useful?
  25. 25. 22/01/2019 - Page 25 Commitments and ZKPs • “public” commitments for the secrets Share a value computed from secret, without leaking info • ZKPs relative to those commitments Prove that − Secret value used in computation = secret value used for commitment Chain of truth from key generation to ballot decryption • Combination yields Universal verifiability Result integrity How and why?
  26. 26. 22/01/2019 - Page 26 Wikström’s Proof of a Shuffle • Re-encrypting mix-net Each component re-encrypts each ballot and shuffles them • Since shuffled, simple pre-image proofs would not work • Since re-encrypted, ciphertexts are not equal Vote secrecy • Need for a specific proof that the cryptographic shuffle is valid Result integrity Why?
  27. 27. 22/01/2019 - Page 27 Outline Context Security properties and challenges Federal requirements Protocol overview State of the project Conclusion
  28. 28. 22/01/2019 - Page 28 State of the Project (those figures represent estimates by the team) 67% 33% Development Done To Do 40% 60% Infrastructure Done To Do 20% 80% Audits and certification Done To Do
  29. 29. 22/01/2019 - Page 29 Outline Context Security properties and challenges Federal requirements Protocol overview State of the project Conclusion
  30. 30. 22/01/2019 - Page 30 Further reading • Published protocol specification https://eprint.iacr.org/2017/325 • Published PoC code https://github.com/republique-et-canton-de-geneve/chvote- protocol-poc • Federal requirements https://www.bk.admin.ch/bk/fr/home/droits-politiques/groupe- experts-vote-electronique/criteres-pour-les-essais.html And references
  31. 31. 22/01/2019 - Page 31
  32. 32. 22/01/2019 - Page 32 Thank you! Office cantonal des systèmes d'information et du numérique Département des infrastructures Thomas Hofer thomas.hofer@etat.ge.ch @thhofer
  33. 33. 22/01/2019 - Page 33 This work is licensed under https://creativecommons.org/licenses/by/4.0/ Please attribute Republique et Canton de Genève with a link to https://republique-et-canton-de-geneve.github.io/chvote-1-0

×