Table of Contents
collective.elections aims to be an electronic voting system based on KOA (Kiezen op Afstand), an Open Source Electronic/Remote/Internet Voting System developed for the Dutch government in 2003. Kiezen op Afstand is literally translated from Dutch as "Remote Voting." A version of the KOA system was used in the European Parliamentary election of June 2004 and was subsequently released under the GNU General Public License.
The first version of this system, ATVotaciones, was developed in 2007 by Alexander Zapata under supervision of Sergio Rajsbaum, a member of the Institute of Mathematics at National Autonomous University of Mexico, and was later updated by Iván Cervantes to be Plone 3 compatible.
collective.elections is a new implementation of the system for Plone 4.1 and above using Dexterity and a custom workflow.
KOA protocol fulfills the following requirements:
- Only authorized voters are able to vote
- No voter's vote can be counted more than once
- Votes are securely stored
- Votes can not be modified/removed without detection
- It is possible to verify that all the votes were counted
- Votes are not lost
- It allows a greater level of confidence among voters
- It is easy to use
collective.elections uses GnuPG for all cryptographic functions. GnuPG is a complete and free implementation of the OpenPGP standard as defined by RFC4880. GnuPG allows to encrypt and sign data, features a versatile key management system as well as access modules for all kinds of public key directories.
The original system was developed using Archetypes and did not used Plone's workflow machinery at all. The system was heavily attached to FacultyStaffDirectory, a personnel directory, and to ATSelectUsers, a product developed by the Institute of Mathematics in order to create subsets of persons inside a staff directory.
The original system defined three user roles:
- Election Administrator (EA)
A member of the portal Administrators group that creates the election and the rolls of nominees and voters.
- Election Officials (EO)
These are the members of the portal that will guarantee the election call is fulfilled; they will also sign documents produced through the election process.
- General Users (GU)
Nominees, candidates and voters.
The EA adds a new election object and fills all the parameters in the general configuration screen. These parameters include the title, description, the username of the user that will act as the Chief Electoral Officer (CEO) and the dates of the process (date to accept nomination, to start voting, to stop voting, to publish results, and so on…). The EA will also include her GPG public key that is going to be used later to sign and encrypt information as the process moves on.
The CEO enters information for other fields like the usernames of the other EO, and the PGP public key used by them. He will also generate a human-readable PDF file with all the information relative to the general configuration and will sign it with their own GPG private key. This information will be available at any time of the process.
The EA creates the nominees roll and the voters roll using ATSelectUsers. This product allows to create a subset of members of the portal that fulfill certain requirements (like "being females over 40 years with at least 5 years of experience").
Human readable PDF files with the list of nominees and voters are created and these files are also signed by anyone of the EO. After this, nobody can change these rolls without detection and everybody can check to see if all, nominees and voters, really fulfill the requirements published in the call for the election.
Users of the system can check their status as nominees and/or voters and they can accept/reject/cancel their nomination to become candidates. Any claim must be done to the EO.
Before the voting process starts, the system generates a set of random numbers for each pair of voter/candidate (if we have 2 candidates and 10 voters the system will generate 20 random numbers) to avoid duplicate votes. This set of numbers is encrypted with the public key used by the EO, and is used to create ballots for each voter:
Candidates | A | B |
---|---|---|
Voter 1 | 9095 | 7613 |
Voter 2 | 9211 | 8291 |
Voter 3 | 522 | 4640 |
Voter 4 | 5988 | 4415 |
Voter 5 | 8489 | 4730 |
Voter 6 | 9416 | 1940 |
Voter 7 | 877 | 8033 |
Voter 8 | 3028 | 487 |
Voter 9 | 8875 | 1164 |
Voter 10 | 7854 | 2642 |
Each ballot can only be accessed by the voter associated with it when she is about to cast her vote.
After the voting has finished (the end date arrives), the vote counting process starts. First, the EO has to decrypt the ballots, to check that no vote has been modified, and then the counting is done automatically by the system.
Now the results can be published. The EO creates and signs a PDF with the results of the election and the information is made available to the public.
collective.elections will use Dexterity-based content types to describe an election. The election object will move across an election workflow in which different actions will be available to different users with different roles. We want to keep this as simple as we can, so we will try not to implement more roles or permissions unless necessary.
We will maintain the three roles mentioned before:
- EA (probably mapped as Manager or Site Administrator)
- EO (probably mapped as Editor)
- GU (probably mapped as Contributor)
We visualize a workflow with, more or less, the following states:
- Private
- Initial state of the election; the EA fills all the parameters and submit the election to be reviewed by the EO's (Trans. 1).
- Internal revision
- In this state the election configuration is reviewed by the CEO; if everything is correct, a PDF file with this information gets exported.
- The CEO signs the file locally with his GPG private key and adds the signed PDF and signature to the election.
- Only the PDF and signature fields are writable in this state.
- The election can be sent back to the Private state (Trans. 2) or be submitted for public review (Trans. 3).
- The CEO is the only role allowed to call Trans. 3.
- Public revision
- In this state, none of the fields of the election are writable by anybody.
- It can be sent back to the Private state (Trans. 4) in case of some error.
- Transition to the Nominees state is done automatically in a given date (Trans. 5).
- Nominees
- In this state, the electoral and nominations roll are filled by the EA.
- Only these 2 fields are writable by anybody in this state.
- This state cannot be sent back.
- The EA can submit to the Nominee revision state (Trans. 6)
- Nominee revision
- In this state, the electoral and nominations roll are reviewed by the CEO; if everything is correct, then a second PDF file with the rolls gets exported.
- The CEO signs it locally with his GPG private key and adds the signed PDF and signature to the election.
- Only the PDF and signature fields are writable in this state. (2 additional fields, separate from the 2 fields used in state Internal revision).
- The election can be sent back to the Nominees state (Trans. 7) or be submitted for public review (Trans. 8).
- The CEO is the only role allowed to call Trans. 8.
- Public
- In this state, none of the fields of the election are writable by anybody.
- It can be sent back to the Nominees state (Trans. 9) in case of some error Transition to the Voting state is done automatically in a given date (Trans. 10).
- Voting
- Votes are allowed to be entered. No fields are writable by anybody.
- This state cannot be sent back.
- Voting will end in a previously given date automatically and the election be moved to the Vote Counting state (Trans. 11).
- Vote Counting
- Votes are counted.
- In a previously given date, the election will automatically be moved to the Results state (Trans. 12).
- Results
- Results of the election are available to everybody.
- In this state, the EO's can validate valid signatures and finally, the CEO can close the election (Trans. 13).
- Closed
- No one can make further changes to the election object.
- Trans. 1
- Private -> Internal revision
- Manually triggered transition. Only the EA is allowed to call it
- Trans. 2
- Internal revision -> Private
- Manually triggered transition. EA and EO's are allowed to call it
- Trans. 3
- Internal revision -> Public revision
- Manually triggered transition.
- This transition cannot be triggered, unless the PDF and signature fields of the election are populated. Only the CEO is allowed to call it.
- Trans. 4
- Public revision -> Private
- Manually triggered transition. EA and EO's are allowed to call it
- When this transition is triggered, the PDF and signature fields are wiped out.
- Trans. 5
- Public revision -> Nominees
- Automatically triggered transition when a specific date is reached
- Trans. 6
- Nominees -> Nominee revision
- Manually triggered transition. Only the EA is allowed to call it
- Trans. 7
- Nominee revision -> Nominees
- Manually triggered transition. EA and EO's are allowed to call it
- Trans. 8
- Nominee revision -> Public
- Manually triggered transition.
- This transition cannot be triggered, unless the second PDF and signature fields of the election are populated. Only the CEO is allowed to call it.
- Trans. 9
- Public -> Nominees
- Manually triggered transition. EA and EO's are allowed to call it
- When this transition is triggered, the second PDF and signature fields are wiped out.
- Trans. 10
- Public -> Voting
- Automatically triggered transition when a specific date is reached.
- In this transition, hashes with electors and voters are generated
- Trans. 11
- Voting -> Vote Counting
- Automatically triggered transition when a specific date is reached.
- Trans. 12
- Vote Counting -> Results
- Automatically triggered transition when a specific date is reached.
- Trans. 13
- Results -> Closed
- Manually triggered transition. Only the CEO is allowed to call it