Election Console

From Scantegrity Wiki

Election Console is a java application used to run meetings with multiple wards or ballot styles. It was designed for use in the 2009 Takoma Park Municipal election to meet specific board of election requirements. You can run each meeting (Initialization, pre-eleciton audit, results, and post-election audit) with this software.

Contents 1 Election Initialization (Meeting 1) 2 Pre-Election Audit (Meeting 2) 3 Generating Ballots 3.1 Regular Ballots 3.2 Remotegrity Ballots 3.3 Accessibility Workstation Ballots 4 Helper Scripts

[edit] Election Initialization (Meeting 1)

Initialization generates a digital audit trail for the election which is signed and posted online for the auditors. Before the user can run meeting 1, a number of files must be present as shown in the example test data.

A "private" and "public" folder must be created. These folders are stored on separate flash drives, and backups of the state of each of these folders are made after each meeting. The folders should contain ward folders of the format ward%d, where %d is a digit (e.g. ward1, ward2, and so on). The private folder and its sub-folders start off as blank placeholders for output. The public folder contains helper scripts and each ward folder contains the following files:

1. ElectionSpec.xml—This file specifies the number and type of contests, the number of candidates in each of these contests, and other contest rules.
2. MeetingOneIn.xml—Contains basic election info (number of ballots), and pointers for ElectionSpec and partitions.
3. background.pdf—Contains the ballot template as generated by the Ballot Authoring tool.
4. geometry.xml—Ballot geometry file detailing where each markable position is located and to which contest it belongs. Also generated by the Ballot Authoring tool.
5. partitions.xml—Describes how many partitions (sub-elections) the contests on the ballot should be broken into and to which partition each contest will belong.

Once all of these files are setup, you can start the Election Console to run Meeting 1. The following steps can be followed to run meeting 1 with the Election Console:

1. Start the Election Console and select the public and private folders.
   
2. Select the "Compute Commitments" tab, and click the "Commit to how the ballots are going to be decrypted" checkbox.
   
3. Enter the election trustee passwords, and set the threshhold, which is the number of trustees that must be present to run a meeting.

1. Wait for the meeting to finish.
   
   

At this time, you should have a MeetingOneOut.xml in each public ward folder. Inside of the private folder, under ward1, you will see a keystore.xml and a passwd database. If you lose the private folder, everything can be regenerated if all election trustees show up and use the same names and passwords in the same order. Otherwise, the keystore.xml and passwd files along with the specified threshold number of trustees are required to conduct additional future meetings. The test data files were generated with 5 users (user1, user2, user3, user4, user5) with all users having the same password of "password" and a threshold of 3. Also note that the data has been signed using the gpg_sign_electionfiles.sh bash script.

If meeting 1 fails, it should be re-run.

[edit] Pre-Election Audit (Meeting 2)

To run Meeting 2, you need a MeetingTwoIn.xml file in each public ward directory. You can generate these automatically with the pre_election_audit.sh bash script, which uses stock data to unpredictably select which ballots to audit in a way that is publicly verifiable. This script should be run several hours after stock closing, and the results should, preferably, be checked and validated by an auditor before Meeting 2. The test data show results of this script from september 23rd.

The steps to run Meeting 2 are as follows:

1. Start the Election Console, select the folders, and select the "Compute Commitments" tab.
   
2. Select the top 2 check boxes to respond to and check that each ballot has been formed correctly.
   
3. Wait for the audit.
   
4. This box will appear when the audit completes.
   

The output files are MeetingTwoOut.xml, PrintCodes.xml, and MeetingTwoOutCommitments.xml. The [test data] shows the results with signature files. In the private folders, the user will find a MeetingTwoPrints.xml for each ward, containing the confirmation numbers to create ballots at any time after Meeting 2. Please note that the MeetingTwoPrints.xml file is extremely sensitive and should be securely deleted as soon as possible.

If Meeting 2 fails, the election should start over at the initialization phase.

[edit] Generating Ballots

Ballots should be generated immediately after Meeting 2 has been run successfully. At this time, the MeetingTwoPrints.xml file is manually excerpted to generate ballots for Remotegrity and the Accessibility Workstation components of Scantegrity. Future versions of Election Console will encrypt this file using the public key of each entity that requires it, and will not store the data at rest in an unencrypted format.

The way ballots are generated has changed slightly since 2009. Please pay careful attention to the instructions in the following sections.

[edit] Regular Ballots

[edit] Remotegrity Ballots

[edit] Accessibility Workstation Ballots

[edit] Helper Scripts

1. get_latest_djia_stock_prices.py—Python script to retrieve DJIA stock prices.
2. gpg_sign_electionfiles.sh—Signs any files in the election directory.
3. gpg_verify_electionfiles.sh—Verifies signatures of any signatures in the election directory.
4. pre_election_audit.py/pre_election_audit.sh—A bash script and python script to generate MeetingTwoIn.xml files from stock data.
5. post_election_audit.py/post_election_audit.sh—A bash script and python script to generate MeetingFourIn.xml files from stock data.