Unlocking Exploration: Self-Motivated Agents Thrive on Memory-Driven Curiosity
Helios 2.0
1. 2.0
A Summation of the Real World Use of Helios in the
Université Catholique de Louvain’s
2009 Presidential Election
Alexandria Farár
2. What is Helios?
• Helios is a web-based open-audit voting system.
The first publicly accessible open-audit voting system.
Anyone can
create elections
Anyone
can audit the
election process
Public Auditability
3. What is Helios?
• Helios is a web-based open-audit voting system.
Cryptographic end-to-end verifiability ensures integrity.
Version 1.0
Released 2008
Low Coercion
Elections
Proof of Concept
5. Université Catholique de Louvain’s
Presidential Election
Elections Open to All
25,000 eligible voters
Helios – Just in time…
Challenges:
Trustworthy Results + Try Something New
Motivation:
Cryptography Dept. Involvement + Absence of Precedence
2009
6. Helios 1.0 Issues
• The current version of Helios was lacking
Based on Mixnets
Google Engine Required
Not Scalable
Single Key Encryption
Votes receive
different weights
Integration +
Privacy Laws
Could not tally
thousands of votes
One person trusted not
to decrypt indiv. votes
Helios 1.0 was not designed to solve voter complaints.
7. Helios 2.0
• Mixnet to Homomorphic Tallying
Mixnet Homomorphic
• Trustees anonymize ballots
• Trustees decrypt all shuffled
ballots
- more info. revealed
- computation grows with number
of voters
• Validity checked after
decryption
- no validity proof needed
- universal ballot format ,
- invalid ballots hard to trace
• Public aggregation of ballots
into election outcome
• Trustees decrypt outcome only
- little info. Revealed
- little computation needed
• Zero-knowledge proofs of ballot
validity
- heavy computation
- need changes depending on
election rules
- validity can be checked
8. Helios 2.0
• Homomorphic Tallying
Homomorphic
Tallying
Easy
Implementation
Single cipertext
for each election
question
Exponential
El Gamal
Encrypt gm
not m
9. Helios 2.0
• Homomorphic Tallying
Ballot
Ciphertext for each available answer to
each election question
Disjunctive ZK Proof – each ciphertext encodes 0 or 1
Disjunctive ZK Proof – sum of all cipertexts for a question is the
encryption of one out of 0, 1,…max for a preset maximum
High Security with efficient modular exponentiation
q of Zp* where p and q are 2048 and 256 bit primes
10. Helios 2.0
• Tallying and Election Verification
in the Browser
Web-based Election
Tallying
Web-based
Election
Verification
HTML
JavaScript
Ballot Verification
Program
XScalability
UCL Custom
High speed
Offline
tallier /verifier
11. Helios 2.0
• Distributed Decryption
DistributedKeyGeneration Ensures multiple trustees
required for encryption
Only homomorphic tally
of all votes decrypted
Each trustee generates a El-
Gamal public key using same
(p,q,g) parameters
+
Combining public keys using
simple multiplications
13. Helios 2.0
• Machine Interface for Modular Authentication
Helios
2.0
UCL
Custom
Auth
Mia
Encrypted vote +
“Mia” + HMAC
Encrypted vote +
UCL credentials
Trusted server submits ballots for voters
Performs voter authentication
Submits results to Helios 2.0
oAuth protocol – 2-legged mode
1.0
14. Helios 2.0
• Standalone Open-Source Distribution
• Software independent of proprietary platform
Security Policies Non-US Based Self-install codebase
Free – Open Source software stack:
Python, Django Web Toolkit for Python, PostgreSQL DB
15. Improved User Interface
Helios 1.0 UI difficult to use
• Progress bar along top of interface
• Layman’s terms
• “Please wait message” for long operations
• Comprehensive testing across browser platforms –
JavaScript compatibility
16. Tweaks
• Notable enhancements
Standalone Static
HTML / JS
Ballot Verifier
Deployed on any
webserver
Harvard, E ́cole Normale
Supe ́rieure de Cachan
Document digitally signed
by voting server:
- registration
- before web bulletin
board auditing phase
Proof
Formal Verification Specs
To facilitate 3rd party tool
creation
Verification procedures
Data models & algorithms
17. Organization of
the UCL Election
Key Generation
Registration & Voter
Authentication
Voting Phase
Web Bulletin Board Audit
Tally
Universal Verification
18. UCL Election
Key Generation
Election private
key distributed
Distribute trust –
multiple parties
Election identifiers
published;
available in signed
PDF docs
Registration
& Voter
Authorization
Registration Phase
mitigates
Ballot Stuffing
Voter Aliases
(ER+6 digits)
UCL Bylaws
require
confidentiality
Voting Phase
Internet voting
not common in
Belgium
Election highly
publicized
Public
demonstrations
Test election
Registration /
voting office
locations
19. UCL Election
Web Bulletin
Board Audit
Full day BB audits
File complaints to
Election
Commission
Separate
authentication
method for
complaints
Vote quarantined
Signed receipt
Vote hash
Tally
Voter imbalance
Sub-tally weighted
before final tally
Tally phase:
Verify ZK proofs
Discrete logarithm
extraction provides
election result after
decryption
Implemented in C
Universal
Verification
All audit data
publicly available +
specs
Independent
company wrote 2nd
instance of audit
code - Python
Proved correctness
of decryption
process
20. Trial Election
Test election run during registration
Vote for 1/5 student projects (cast blank votes)
3000 voters participated
Detected incompatibilities in voting system
and computer configurations
Suggestions for improving UI
Linux, Mac OSX, Windows
Firefox 2/3, Internet Explorer 6/7/8, Safari 2/3, Chrome I
21. Official Election
• Election ran 2 days from 8am-7pm
1%
Revote
97%
Voted Remotely
5000
Registered Voters
4000
Participated R1/2
Peak 17 Votes Min
3%
Polling Stn2 Days
30%
Checked vote on Bulletin Board
7
Complaints
-Voted on audit day
-Test the system
-Switched vote
receipts
22. Official Election
Candidates:
1. Pr. Vincent Blondel
2. Pr. Bruno Delvaux
Two rounds of Elections (weighted votes)
1st
Vincent Blondel – 477.33
Bruno Delvaux – 555.44
2nd
Vincent Blondel – 465.74
Bruno Delvaux – 590.48
78.23
40.78
Independent company audited the tally – no recount.
24. Conclusion
• The first UCL Open Audit Election was a success
• Only received minor complaints
• Trustees still require some understanding of cryptography.
• Running an open-audit election is easier and more predictable
than traditional
• Helios must be customized per organization
25. References
Ben Adida, Olivier De Marneffe, Olivier Pereira, and Jean-
Jacques Quisquater. 2009. Electing a university president using
open-audit voting: analysis of real-world use of Helios. In
Proceedings of the 2009 conference on Electronic voting
technology/workshop on trustworthy elections
(EVT/WOTE'09). USENIX Association, Berkeley, CA, USA, 10-10.
Ben Adida. 2008. Helios: web-based open-audit voting. In
Proceedings of the 17th conference on Security symposium
(SS'08). USENIX Association, Berkeley, CA, USA, 335-348.
Editor's Notes
Homomorphic - easier to implement efficiently, therefore easier to verify.
UCL used a notary public to handle backups of keys to ensure robustness
By Default – Helios authenticates users by email address and an election specific password. Password is generated by Helios upon voter registration and sent by email to each voter.
UCL and other large institutions with an institution wide authentication infrastructure should use existing authentication infrastructure.
Used the standard oAuth protocol [19] (in so-called “2-legged mode”) to authenticate a call from the UCL authentication system to the Helios backend server. The use of oAuth effectively sends an HMAC [15] of the request using a shared secret between the two servers.
Security implications: we expected the set of Helios servers not to stuff the ballot, and we verify this during the audit phase and after the election results are published by publishing the voter list.
Users needed knowledge of cryptographic voting to use the Helios 1.0 interface
Can be deployed on any web server with a given election’s parameters wired directly into the verifier file. This allows a number of parties to publish a web-accessible verifier, so that voters have their choice of trusted entity to verify the proper encryption of their ballot. In the UCL election, Harvard and the E ́cole Normale Supe ́rieure de Cachan hosted such verification programs
Complaints - Helios 1.0 provided an unauthenticated web bulletin board, which might open the path for unsubtantiated complaints by voters who either did not correctly record their vote receipt, or would like to raise suspicions about the validity of the bulletin board content. Therefore, we decided to provide voters with a document digitally signed by the voting server for each important stage of the election: at registration time, and before the web bulletin board audit phase. These documents would provide each voter a way to prove to the election commission, if it is ever needed, that she actually register for the election, but that this registration was lost by the registration server, or that a vote that was verified during the web bulletin board phase was modified in the tallying phase.
Key generation. In an election based on homomorphic tallying, the confidentiality of the votes fundamentally relies on the secrecy of the private key that is used to decrypt the tally, but that could also maliciously be used to decrypt individual votes. In order to improve the control of the decryption process, the election private key was generated and stored in a distributed way, by trustees selected from various voter groups (students, administrative staff, . . . ), but also from the invited external experts from the election commission.
Solution to distribute the trust between multiple parties without requiring trustees to become experts themseles. A meeting with the election commission was organized, together with several experts in computer science. Several laptops were brought, from which the hard disk drives were removed and wireless network cards disabled. Then, those laptops were boot up using standard linux live-CDs, and the key generation code, kept as simple as possible, was loaded on the machines through USB sticks, after inspection by the external experts. Keys were then generated and stored on the USB sticks, the laptops shut down, and the linux live-CDs destroyed. A similar procedure was followed when those keys were used for decryption.
Registration Phase - ensures that only the eligible voters who are active in the process got a credential to vote, while providing time to audit the registration phase before the voting phase begins.
Aliases – Voting server hosted outside of UCL contained no meaningful list of election participants; voters can only check their own vote and the global verification is delegated to the election commission.
After publication of the signed receipts, a full day was devoted to the bulletin board audit. Voters were invited to consult the bulletin board and to produce a new ballot and introduce a complain to the election commission in case of disagreement with the signed data. At least two reasons could cause this disagreement: (i) the voting server was hacked (or the election organizers were cheating), and the signed vote was indeed incorrect, or (ii) the voter did not take proper care of her credentials, and a third party stole them and used them to submit a vote.
A voter in the UCL President Election belongs to a category: faculty, staff, researcher or student. Because of the huge difference in the number of voters of those categories, i.e. twenty times fewer faculty members than students the sub-tally from each category is weighted before the final tally. According to the by-laws of the election, the weighting is a function of the turnout of each category, computed according to a fairly sophisticated formula. A candidate needs to obtain the strict majority of the weighted votes, including the blank votes, to be elected.
he use of two independently produced election tally and verification codes, written in two different programming languages, relying on different arithmetic libraries, provided strong evidence of the correctness of the decryption process.
