Fraud Resistant Electronic Voting

Fraud resistant electronic voting: system requirements
Introduction
Currently, electronic voting systems are viewed with scepticism because of the multitude of ways they can be compromised. Although voting machines are in common use, there are reports on methods for compromising these commonly used voting machines In that document, related documents were found to be of less value. However the complexity of the article is overwhelming for all but computer experts. Since the purpose of this article is meant to be readable by a general audience, the important ideas have been presented in a non technical way.
First thing for the reader to realize is that the programming processes that will be required by this article are well established and well known in the world of professional programmers. Dozens upon dozens of computer companies exist that are qualified to implement the system requirements that will be set forth in this document.
The second thing to realize is that, precinct administrator will need to review and confirm the work of administrators from the other political parties. The system will provide an "audit" file that will keep a record of all actions performed by all administrator. All system actions by precinct administrators are fully transparent to all precinct administrators.
Hardware requirements
* A local area network (LAN) with a central processing node and one or more voter nodes. Standard commercial components such as those used with PCs can be utilized to build the two types of network nodes.
* The chassis on all network components will be impervious to internal penetration If a network component fails, it must be replaced by a new unit. This unusual feature is crucial for security
* Imbedded in the central node’s chassis will be a data input touch screen, a power switch with power cable port, two input/output ports, a printer port , "burned in" machine identity tag. Voter nodes will not have i/o ports or printer ports in this design.
*External storage devices having the “write once” property. After the data is written, it cannot be modified by any computing device.
* Printer
*Input screen. This screen will NOT provide any capabilities for programming or file access. A touch screen is the preferred option. This interface will display “mode buttons” to invoke screen displays for data entry and system commands, and a “keyboard” for the basic set of alphanumeric characters and simple text editing controls such as delete character or backspace.
Sequenced flow of actions by precinct administrators
# Power up electronic voting system.
#Assign administrators by self assignment.
# Setup candidates and political parties and precincts identifiers.
# Print paper ballots for ancillary use.
# Create voter roll for current election cycle.
# Official confirmation of voter roll by all parties.
# Activate voting mode for election day.
# De activate voting mode at end of election day
# Enter paper ballots from all sources.
# Review and confirm all administrator actions since the close of the election day.
# Review all election results
# Official confirmation of election results by all parties.
# Upon acceptance of results by all parties, disable administrator input modes for the current election cycle
# Create election results as unalterable exports devices for archive storage and for disbursement.
# Shutdown election cycle as a irreversible action. The next power up of the system will start a new election cycle.
Overview of data structures
#Administrators. All administrators will have the exact same capabilities and permissions, there will no special administrators thereby avoiding any complaints of favoritism among parties. After being added, administrators cannot be deleted. This no delete rule avoids loss of information in the audit trail of administrator actions. Administrators will select party affiliation from a list.
#Voter Roll: The voter list, with requisite identity information, will be entered by the administrators. All entries will require identity uniqueness as defined by the state authority. The enforcement of uniqueness will be done by standard database methods ( unique key constraint) . All administrators can view or print the entire voter list at will. Administrators can add / edit voters in their own party or those unaffiliated. Periods of time are to be scheduled when all administrators meet to resolve challenges to each other’s voter list. All parties must be in agreement with the role before the voting mode is enabled on election day. Problem cases on election day will be handled by paper ballots to be entered on days following the election day and subject to subsequent confirmation by all parties.
#Audit File This file resides on the central node and will contain sufficient data to fully identify and characterize all administrator actions. Automatic insert date, automatic system ID number, administrator identity, action code , update value when applicable, status code, substatus when applicable and optional comment area to be used by an auditor. Later sections will provide more details about the audit file.
Operating modes
* Candidate setup mode - On the initial activation of the network when starting a new election cycle, this functionality is made available on the central unit. The administrator enters candidate information to be displayed on the ballot. All candidate information must be finalized before proceeding. All other modes become available only after the candidate setup is marked as finalized. After finalization, Candidate setup is disabled until the start of a new election cycle.
* Testing mode. This mode is always available after Candidate setup is finalized. This mode is used for training practice and, if desired, to confirm that input and output functions will behave properly..
* Voters mode provides a data entry window in which to enter the identity information of all voters. Ballots can be submitted only once after a qualified voter can be identified uniquely in the voter roll. Voter nodes should be able to provide double duty as an entry platform for the voter roll, because there could be multiple administrators spending much time creating entries to the voter roll.
*Voting mode is activated by any administrator right before the polls open on the day of elections. This activation causes the voter nodes to become functional. Public voting is disabled at the close of the election day and the voter nodes cannot be activated again for public voting until the next election cycle. The input screens appear as ballots generated from the Candidate descriptions entered in Candidate setup mode.
*Ballot mode is used by administrators to enter mail-in ballots and paper ballots from other possible sources. The paper ballots entries must be confirmed by a second ballot independently entered by a second Administrator from another political party. If the two ballot entries match identically, the second entry is deleted automatically, otherwise a error message displays the differences between the two entries and both entries are deleted. Also blank paper ballots can be printed from this mode.
* Reporting mode. Vote counts will include typical “slice and dice” capabilities with further specifications to be done.
* Audit. A viewable / printable detail record of all administrator actions. An audit of voter choices is not created because of anonymity requirements. Audit reports can be examined by any administrator (and printed) and administrators can use filters to examine subsets of voters( eg, all voters of unknown status )
* Exports
# A "write once" external storage of the vote counts. Required with the vote count data is a header record that will include an auto generated date/time of export creation, administrator performing the export operation, etc
Election cycle startup
Power up the network s central node. If the network is just installed or if the previous election cycle has been shutdown, a new election cycle is initiated. This action is recorded in the audit file. On initial startup of an election cycle, the names of participating political parties are entered and saved. Parties cannot be deleted after being saved. Administrators are registered and receive a password, administrators cannot be deleted. Audit reports and voting reports are enabled until the election cycle is shutdown prior to the start of next election cycle. Voter nodes are powered up on election day by command from the central node. When work on the next election cycle is to begin, the current cycle is shutdown as a irreversible action. .
Election cycle shutdown
At some time after the election day, all input will be officially finalized by all party administrators and the input modes will be disabled. Paper ballot copies are printed and securely stored in secured physical storage. After shutdown, the next startup of the network will begin a new cycle and require the assignment of new administrators and the political parties.
System failure scenarios
Because of the above design, a failure of a voter node only means that the network has one less voting node. A new voter node can be replaced seamlessly. If the central node fails before election day, it is replaced by a second central node and another central node is ordered from the manufacturer. The backups must be able to restore data collected up to the time of failure. If the central node fails during the election day, it should be replaced by the backup central node and restored from the backup data store. This failure is very unlikely, but a second central unit should be available just in case. Restore from the backup of the failed central node must be done immediately with downtime 15 minutes or less. This requirement is absolutely necessary to minimize the possibility a dispute.
Implementation notes
Development of a prototype for production should require not more than 18 months by a small team of software developers. Microsoft NET language will do the job but there may be better options depending on developer preferences. Full scale manufacturing of the prototype can be outsourced to a company specializing in that type of work. Manufacturing should be a simple job using already well established methods.
System manual
A short system manual is to be included with the prototype and should NOT contain procedures for operating the software. All input interfaces should be fully intuitive, straight forward, without explanatory screen text, and operable by all precinct administrators after a brief training. This requirement protects against misinterpretations that can be managed with fraudulent intent <ref name=":0" />. The manual contains basics like how to contact the manufacturer, network schematics, how to handle node failures, locating the machine identity, etc.
State tabulation system
The manufacturer of precinct voting systems will need to produce a state tabulation system to read and process the will be used by the state central election authority for a compilation of results from all precincts. The hardware requirements are consistent with those of the precinct system. The manufacturer of the precinct systems will provide this system for state use utilizing program code from the same code base as used by the precinct systems. Inputs of voting results to the state system will be derived strictly from the unalterable vote count export of the precinct system.
Precinct testing
The manufacturer of a voting system will have done basic testing before it releases a system to its customers. Therefore precinct testing is not technically necessary. However, precinct testing is recommended so that administrators can gain familiarity with the system features before working with live voter and voting data. The structure of the testing data is identical to the live data so that the test programs are physically the same as the production programs.
Future for electronic voting systems
A fair voting system can be achieved by the methods described in this article. We emphasize that fair voting systems are not technically difficult to put together. However there is emerging evidence that the Federal government is seeking voting systems that can be controlled by government security agents. The argument for Federal government control over voting systems will be based in the idea that Russia "hacked" the 2016 presidential election. We will continue to work on this truly challenging aspect of the fraud resistant voting system problem.

Main Menu

See Also

Main Menu