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.

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. 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. 22/01/2019 - Page 3
Outline
Context
Security properties and challenges
Federal requirements
Protocol overview
State of the project
Conclusion

4. 22/01/2019 - Page 4
Outline
Context
Security properties and challenges
Federal requirements
Protocol overview
State of the project
Conclusion

5. 22/01/2019 - Page 5
The past of CHvote
First generation E-Voting system
• 2001: start of project
• 2003: first use
• Partners

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. 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. 22/01/2019 - Page 8
Outline
Context
Security properties and challenges
Federal requirements
Protocol overview
State of the project
Conclusion

9. 22/01/2019 - Page 9
Security properties
Target security properties
Vote secrecy Result integrity
No early tallyAvailability Voter authentication
Enfranchisement

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. 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. 22/01/2019 - Page 12
Outline
Context
Security properties and challenges
Federal requirements
Protocol overview
State of the project
Conclusion

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. 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. 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. 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. 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. 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. 22/01/2019 - Page 19
Outline
Context
Security properties and challenges
Federal requirements
Protocol overview
State of the project
Conclusion

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. 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/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. 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. 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. 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. 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. 22/01/2019 - Page 27
Outline
Context
Security properties and challenges
Federal requirements
Protocol overview
State of the project
Conclusion

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. 22/01/2019 - Page 29
Outline
Context
Security properties and challenges
Federal requirements
Protocol overview
State of the project
Conclusion

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. 22/01/2019 - Page 31

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. 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