Skip to Content

Notice

Technical Guidelines Development Committee (TGDC); Initial Report: Voluntary Voting System Guidelines Version I

Document Details

Information about this document as published in the Federal Register.

Published Document

This document has been published in the Federal Register. Use the PDF linked in the document sidebar for the official electronic format.

Start Preamble Start Printed Page 18926

agency:

United States Election Assistance Commission.

action:

Notice; publication of TGDC recommendations for voluntary voting system guidelines.

summary:

The Help America Vote Act of 2002 (HAVA) Section 221(f) directs the Technical Guidelines Development Committee (TGDC) to publish its recommendations to the Executive Director of the U.S. Election Assistance Commission (EAC) at the time EAC adopts voluntary voting system guidelines. In 2004, the EAC formed the TGDC to create an initial set of recommendations for guidelines as directed by HAVA. The Director of the National Institute of Standards and Technology (NIST) chairs the TGDC and NIST staff provides technical support for the TGDC's work. This committee of fifteen experts began their work in July 2004 and submitted their recommendations, which are published here. These recommendations were used by the EAC in producing the EAC's proposed 2005 Voluntary Voting System Guidelines which were published for public comment in June 2005, 70 FR 37378 (June 29, 2005). Following revision of its proposed guidelines to reflect the comments received, the EAC adopted the final 2005 Voluntary Voting System Guidelines on December 13, 2005. This final document is being concurrently published as required by HAVA.

Start Further Info

for further information contact:

Brian Hancock (Election Research Specialist) Washington, DC, (202) 566-3100, Fax: (202) 566-3127.

Start Signature

Thomas R. Wilkey,

Executive Director, U.S. Election Assistance Commission.

End Signature Start Printed Page 18927

Start Printed Page 18928

Voluntary Voting System Guidelines Version I

Initial Report

May 9, 2005

Product of the Technical Guidelines Development Committee With technical Assistance From the National Institute of Standards and Technology

Overview:
Volume One, Performance Standards:
Section One: Introduction
Section Two: Functional Capabilities
Section Three: Hardware
Section Four: Software
Section Five: Telecommunications
Section Six: Security
Section Seven: Quality Assurance
Section Eight: Configuration Management
Section Nine: Overview of Qualification Testing
Appendix A: Glossary
Appendix B: Applicable Documents
Appendix C: Best Practices
Appendix D: Independent Dual Verification
Volume Two, Testing Standards:
Section 1: Introduction
Section 2: Technical Data Package
Section 3: Functionality Testing
Section 4: Hardware Testing
Section 5: Software Testing:
Section 6: Systems Integration Testing
Section 7: Configuration Management and Quality Assurance
Appendix A: Qualification Test Plan
Appendix B: Qualification Test Report
Appendix C: Qualification Test Design Criteria

Voluntary Voting System Guidelines—Overview

This section provides an overview of the Voluntary Voting System Guidelines (VVSG), Version 1. The VVSG was created in response to the Help America Vote Act (HAVA) of 2002 and is based on the initial set of recommendations of the Technical Guidelines Development Committee (TGDC) mandated by HAVA. The VVSG Version 1 augments the Voting Systems Standard (VSS) of 2002 (VSS-2002), which was promulgated by the Federal Election Commission (FEC). This overview serves as an explanation of how the VVSG Version 1 differs from the VSS-2002 and provides a basis for further improvements. In addition, it provides a high level overview of the major sections of the two volumes that make up VVSG Version 1.

Document Structure

This document presents the voluntary voting system guidelines as a single document consisting of two volumes: Volume I, the performance provisions of the guidelines and Volume II, the testing specification. Sections of this document augment the VSS-2002, by either replacing VSS-2002 sections or adding new sections. New material is indicated by distinct header information on each page. The header information is in a gray shaded box and includes the words “NEW MATERIAL”. The footer information also includes the words “NEW MATERIAL”. Additionally, line numbers have been added to these pages.

In the new sections that contain requirements or informative characteristics, each requirement or characteristic is numbered according to a hierarchical scheme in which higher-level requirements (such as “provide accessibility for blind voters”) are supported by lower level requirements (“provide an audio-tactile interface”). These sections are: Sections 2.2.7, 6.0.1, 6.0.2, 6.0.3, 6.0.4, and Appendix D. Additionally, each requirement or characteristic indicates to whom it applies (i.e., responsible entity) as well as which stage of the voting process (i.e., pre-voting, voting, post-voting) is affected. There are three responsible entities: voting system vendor (V), testing authority (T), and repository (R). To aid the reader, a colored box with the first letter of the responsible entity, i.e., V, T, or R accompanies the name of the entity, as follows:

The three stages of the voting process are indicated by a presenting a box with all three stages and using a strikeout font to indicate the stages that are not applicable, as follows:

Indicates the pre-voting stage is the only stage that applies.

Indicates all three stages apply.

Background

The Help America Vote Act (HAVA) established the Technical Guidelines Development Committee to assist the Election Assistance Commission (EAC) with the development of voluntary voting system guidelines. HAVA directs the National Institute of Standards and Technology (NIST) to chair the TGDC and to provide technical support to the TGDC in the development of these guidelines. The TGDC's initial set of recommendations for these guidelines were presented to the Election Assistance Commission in May 2005, in accordance with HAVA's nine-month deadline.

VVSG Version 1 is intended to assist State election officials in preparing for the 2006 election. This document augments the VSS-2002 to address the critical areas of accessibility, usability and computer security. In addition, the VVSG includes an improved glossary to promote common understanding, a conformance clause, and an updated Appendix on error rates.

It is important to note that the VVSG Version 1 is an interim set of guidelines. The EAC is working with both the TGDC and NIST to create a redesigned VVSG (called VVSG Version 2) that will address a large range of issues including rewriting the requirements, if necessary, to make them more precise and testable and address key human factors and computer security issues. These new requirements will affect the basic design of voting systems to such a degree that these types of changes cannot reasonably be made and tested in time for the 2006 election cycle.

Brief History of Voting Systems Standards and Guidelines

In 1975, the National Bureau of Standards (now the National Institute of Standards and Technology) and the Office of the Federal Elections (the Office of Election Administration's predecessor at the General Accounting Office) produced a joint report, Effective Use of Computing Technology in Vote Tallying. This report concluded that a basic cause of computer-related election problems was the lack of appropriate technical skills at the state and local level to develop or implement sophisticated Standards against which voting system hardware and software could be tested. A subsequent Congressionally-authorized study produced by the FEC and the National Bureau of Standards detailed the need for a federal agency to develop national performance Standards that could be used as a tool by state and local election officials in the testing, certification, and procurement of computer-based voting systems.

In 1984, Congress appropriated funds for the FEC to develop voluntary national Standards for computer-based voting systems. The FEC formally approved the Performance and Test Standards for Punchcard, Marksense and Direct Recording Electronic Voting Systems in January 1990. This document is generally referred to as the Voting Systems Standards, or 1990 VSS.

The national testing effort was developed and overseen by the National Start Printed Page 18929Association of State Election Director's Voting Systems Board, which is composed of election officials and independent technical advisors. NASED's testing program was initiated in 1994 and more than 30 voting systems or components of voting systems have gone through the (NASED's) testing and qualification process. In addition, many systems have subsequently been certified at the state level using the Standards in conjunction with functional and technical requirements developed by state and local policymakers to address the specific needs of their jurisdictions.

As the qualification process matured and qualified systems were used in the field, the Voting Systems Board, in consultation with the testing labs, was able to identify certain testing issues that needed to be resolved. Moreover, rapid advancements in information and personal computer technologies introduced new voting system development and implementation scenarios not contemplated by the 1990 Standards.

In 1997, NASED briefed the FEC on the necessity for continued FEC involvement, citing the importance of keeping the Standards current in its reflection of modern and emerging technologies employed by voting system vendors. Following a Requirements Analysis released in 1999, the Commission authorized the Office of Election Administration to revise the Standards to reflect contemporary needs of the elections community. This resulted in the 2002 Voting Systems Standards.

In 2002, Congress passed HAVA, which created a new process for improving voluntary voting system guidelines. A new federal entity was created, the Election Assistance Commission, to oversee the process. The EAC established the Technical Guidelines Development Committee in accordance with the requirements of section 221 of HAVA pursuant to the Federal Advisory Committee Act, 5 U.S.C. App. 2. The TGDC's objectives and duties were to act in the public interest to assist the EAC in the development of the voluntary voting system guidelines. The membership, as defined by HAVA, includes:

  • The Director of the National Institute of Standards and Technology (NIST) who shall serve as its chair,
  • Members of the Standards Board,
  • Members of the Board of Advisors,
  • Members of the Architectural and Transportation Barrier, and Compliance Board (Access Board),
  • A representative of the American National Standards Institute,
  • A representative of the IEEE,
  • Two representatives of the NASED selected by such Association who are not members of the Standards Board or Board of Advisors, and who are not of the same political party, and
  • Other individuals with technical and scientific expertise relating to voting systems and voting equipment.

The TGDC first met in August, 2004 and delivered the Voluntary Voting System Guidelines in May, 2005. This initial set of recommendations augments the VSS-2002 by including security measures for auditability, wireless communications and software distribution and setup, and improvements to the accessibility and usability design sections of the VSS-2002. The TGDC also recommended that the VSS-2002 be replaced with a far-reaching guideline that would address in-depth security, performance-based guidelines for usability testing, and an overhaul of the standards and test methods to meet today's more rigorous needs for electronic voting systems.

Issues Addressed by the VVSG Version 1

The VVSG Version 1 adds or significantly changes eight technical topics of the VSS-2002. In addition, there are three organizational changes in the new sections. All other material remains the same.

Conformance Clause

The VSS-2002 did not include a conformance clause. One has been written and inserted as Section 1.7. The previous material in Section 1.7, the Outline, has been moved to 1.8.

Conformance is defined as the fulfillment by a product, process, or service of requirements as specified in a standard or specification. Conformance testing is the determination of whether an implementation (i.e., product, process, or service) faithfully satisfies the requirements and thus, conforms.

The conformance clause of a standard specification is a high-level description of what is required of implementers and developers. It, in turn, refers to other parts of the standard. The conformance clause may specify minimal requirements for certain functions and minimal requirements for implementation-dependent values. It may also specify the permissibility of extensions, options, and alternative approaches and how they are to be handled.

Human Factors

In the VSS-2002 Volume 1 Section 2.2.7 addressed Accessibility and Section 3.4.9 addressed Human Engineering—Controls and Displays. The VSS-2002 also contained Appendix C on Usability. The VVSG Version 1 replaces all of these items with a new Section 2.2.7 that addresses Human Factors including accessibility, usability, and limited English proficiency. This new sections incorporates the two NASED Technical Guides (Guide #1 and Guide #2). Future versions of the VVSG will contain performance-based requirements.

Security Overview and Appendix D

A new security section was added as Section 6.0. It contains four parts: an Overview and three topic areas. The overview was added to explain the VVSG approach to security. Future versions of the VVSG will require independent dual verification. There are many ways known today to achieve independent dual verification and more ways may be developed. Current methods include dual process systems, witness systems, cryptographic-based systems, optical scan systems, and paper audit trails. A new Appendix D expands on this overview with an in-depth discussion of independent dual verification systems. Independent dual verification is a new area in voting systems and it is expected to evolve significantly in VVSG Version 2. The Security Overview is an informative (non-normative) section of the VVSG Version 1. Requirements for voter verified paper audit trail systems, which are a type of independent dual verification system, are specified in a separate section. Version 2 of the VVSG will have complete requirements for at least three additional methods.

Voter Verified Paper Audit Trails

The VSS-2002 contained no requirements for voter verified paper audit trails. The VVSG Version 1 is providing requirements for voter verified paper audit trails (VVPAT) so that States that choose to implement VVPAT or States that are considering implementation can utilize these requirements to help ensure the effective operation of these systems. The EAC, TGDC, and NIST are taking no position with respect to the implementation of VVPAT systems and are neither requiring nor endorsing voter verified paper audit trails. Methods other than VVPAT can provide ways to achieve independent dual verification. These other methods are described in the Security Overview.

Wireless Technology

The TGDC concluded that the use of wireless technology introduces risk and Start Printed Page 18930should be approached with caution. Therefore, the VVSG Version 1 includes a new section on wireless that augments the general telecommunications requirements in Volume 1, Section 5. in Section 5. The VVSG Version 1 requires that wireless transmissions be encrypted to protect against a variety of security problems.

Software Distribution and Setup Validation

The VSS-2002 contains many requirements to help voting officials validate the software and the setup of voting system software and hardware. Subsequent to the publication of the VSS-2002, the EAC invited all voting software vendors to submit their software to a national software repository maintained by NIST. This section of the VVSG Version 1 builds on the VSS-2002 to include use of this repository and other validation mechanisms.

Glossary

This glossary contains terms from the VSS-2002 as well as the inclusion of additional terms needed to understand voting and related areas such as security, human factors, and testing. Each term includes a definition and its source as well as an association as to the domain for which the term applies. Having a common set of terminology forms the basis for understanding requirements and for discussing improvements. The glossary is also available in a web-based on-line version at http://www.nist.gov/​votingglossary.

Error Rates

Volume II, Appendix C addresses error rates. This appendix contains revised procedures to test that systems meet the indicated error rates. These apply to errors introduced by the system, defined as a ballot position error rate, and not by a voter's action. Further research on human interface and usability issues is needed to enable the development of Standards for error rates that account for human error.

There were concerns about the VSS-2002 Appendix regarding the numbers listed in the probability ratio sequential test (PRST) of the Mean Time Before Failure (MTBF) that (1) the numbers do not correspond to the numbers for the same table in the 1990 VSS, even though the stated assumptions do not change, and (2) the numbers from neither the 1990 nor the 2002 tables correspond to numbers that would result from standard PRST formulas listed in standard references such as the military handbook MIL-HDBK-781A. To address these concerns, the revised Appendix has replaced the numbers in the table with those that would indicated by the truncated PRST design from MIL-HDBK-781A with the corresponding parameters and made it more clear in the text that a truncated design was chosen. Using standard theoretical formulas leads to somewhat different numbers, but the revised Appendix C uses numbers from the MIL-HDBK-781A because they may be considered more standard and produce a less drastic change. Also, in the 1990 VSS, there was an appendix devoted to the definition and use of “partial failures.” This appendix was eliminated from the VSS-2002. The new version eliminated the paragraph and diagram in Appendix C that used partial failures.

The new version also includes statements reminding users to be cognizant of the assumptions involved in tests that use time-based exponential failure times and constant failure rates. Given the concerns that have been stated about appropriate testing times, note that the given table is appropriate only for the stated parameters, and that officials should assess the appropriateness of whatever parameters are used in testing.

Best Practices for Voting Officials

The VSS-2002 contained requirements for voting systems and for testing entities. However, requirements for human factors, wireless communications, VVPAT, software distribution and setup validation depend not only on voting systems providing specific capabilities but on voting officials developing and carrying out appropriate procedures. Consequently, the VVSG Version 1 contains Best Practices for voting officials. The new sections in VVSG Version 1 define each requirement as pertaining to voting systems, vendor repository, or test authorities, or voting officials. The requirements for voting officials are collected in Appendix C of Volume 1. (Appendix C had previously been Usability.)

Voting Process

The VSS-2002 defined three major stages of voting: pre-voting, voting, and post-voting. The stage for each requirement is marked in the new sections. The VVSG Version 2 will have a more detailed voting process model and will allow for finer granularity.

Summary of Content of Volume I

Volume I contains performance standards for electronic components of voting systems. In addition to containing a glossary (Appendix A), applicable references (Appendix B), Best Practices (Appendix C) and Security Overview (Appendix D). Volume I is divided into nine sections:

Section 1—Introduction: This section provides an introduction to the Standards, addressing the following topics:

  • Objectives and usage of the Standards,
  • Development history for initial Standards,
  • Update of the Standards,
  • Accessibility for individuals with disabilities,
  • Definitions of key terms,
  • Application of the Standards and test specifications,
  • Conformance clause, and
  • Outline of contents.

Section 2—Functional Capabilities: This section contains Standards detailing the functional capabilities required of a voting system. This section sets out precisely what it is that a voting system is required to do. This section also sets forth the minimum actions a voting system must be able to perform to be eligible for qualification. For organizational purposes, functional capabilities are categorized by the phase of election activity in which they are required:

  • Overall Capabilities: These functional capabilities apply throughout the election process. They include security, accuracy, integrity, system auditability, election management system, vote tabulation, ballot counters, telecommunications, and data retention.
  • Pre-voting Capabilities: These functional capabilities are used to prepare the voting system for voting. They include ballot preparation, the preparation of election-specific software (including firmware), the production of ballots or ballot pages, the installation of ballots and ballot counting software (including firmware), and system and equipment tests.
  • Voting Capabilities: These functional capabilities include all operations conducted at the polling place by voters and officials including the generation of status messages.
  • Post-voting Capabilities: These functional capabilities apply after all votes have been cast. They include closing the polling place; obtaining reports by voting machine, polling place, and precinct; obtaining consolidated reports; and obtaining reports of audit trails.
  • Maintenance, Transportation and Storage Capabilities: These capabilities are necessary to maintain, transport, and store voting system equipment.

For each functional capability, common standards are specified. In recognition of the diversity of voting Start Printed Page 18931systems, some of the standards have additional requirements that apply only if the system incorporates certain functions (for example, voting systems employing telecommunications to transmit voting data) or configurations (for example, a central count component). Where system-specific standards are appropriate, common standards are followed by standards applicable to specific technologies (i.e., paper-based or DRE) or intended use (i.e., central or precinct count).

Section 3—Hardware Standards: This section describes the performance requirements, physical characteristics, and design, construction, and maintenance characteristics of the hardware and related components of a voting system. This section focuses on a broad range of devices used in the design and manufacture of voting systems, such as:

  • For paper ballots: Printers, cards, boxes, transfer boxes, and readers,
  • For electronic systems: Ballot displays, ballot recorders, precinct vote control units,
  • For voting devices: Punching and marking devices and electronic recording devices,
  • Voting booths and enclosures,
  • Equipment used to prepare ballots, program elections, consolidate and report votes, and perform other elections management activities,
  • Fixed servers and removable electronic data storage media, and
  • Printers.

The Standards specify the minimum values for the relevant attributes of hardware, such as:

  • Accuracy,
  • Reliability,
  • Stability under normal environmental operating conditions and when equipment is in storage and transit,
  • Power requirements and ability to respond to interruptions of power supply,
  • Susceptibility to interference from static electricity and magnetic fields,
  • Product marking, and
  • Safety.

Section 4—Software Standards: This section describes the design and performance characteristics of the software embodied in voting systems, addressing both system level software and voting system application software. The requirements of this section are intended to ensure that the overall objectives of accuracy, logical correctness, privacy, system integrity, and reliability are achieved. Although this section emphasizes software, the software standards may influence hardware design in some voting systems.

The requirements of this section apply to all software developed for use in voting systems, including:

  • Software provided by the voting system vendor and its component suppliers, and
  • Software furnished by an external provider where the software is potentially used in any way during voting system operation.

The general standards in this section apply to software used to support the broad range of voting system activities, including pre-voting, voting and post-voting activities. System specific Standards are defined for ballot counting, vote processing, the creation of an unalterable audit trail, and the generation of output reports and files. Voting system software is also subject to the security requirements of Section 6.

Section 5—Telecommunications Standards: This section describes the requirements for the telecommunications components of voting systems. Additionally, it defines the acceptable levels of performance against these characteristics. For the purpose of the Standards, telecommunications is defined as the capability to transmit and receive data electronically regardless of whether the transmission is localized within the polling place or the data is transmitted to a geographically distinct location. The requirements in this section represent functional and performance requirements for the transmission of data that are used to operate the system and report official election results. Where applicable, this section specifies minimum values for critical performance and functional attributes involving telecommunications hardware and software components.

This section addresses telecommunications hardware and software across a broad range of technologies such as dial-up communications technologies, high-speed telecommunications lines (public and private), cabling technologies, communications routers, modems, modem drivers, channel service units (CSU)/data service units (DSU), and dial-up networking applications software.

Additionally, this section applies to voting-related transmissions over public networks, such as those provided by regional telephone companies and long distance carriers. This section also applies to private networks regardless of whether the network is owned and operated by the election jurisdiction. For systems that transmit data over public networks, this section applies to telecommunications components installed and operated at settings supervised by election officials, such as polling places or central offices.

Section 6—Security Standards: This section starts with an overview that provides a description of a new approach to securing voting systems called independent dual verification. The overview introduces the concept of independent dual verification and explains several approaches for achieving it. Appendix D further explores independent dual verification. Independent dual verification is not required in VVSG Version 1, but will be required in Version 2. Following the overview are 3 new sections describing requirements for voter verified paper audit trails, wireless technology and software distribution and setup. The remainder of the section is unchanged from VSS-2002 and describes the security capabilities for a voting system, encompassing the system's hardware, software, communications, and documentation. The requirements of this section recognize that no predefined set of security Standards will address and defeat all conceivable or theoretical threats. However, the Standards articulate requirements to achieve acceptable levels of integrity, reliability, and inviolability. Ultimately, the objectives of the security Standards for voting systems are to:

  • Establish and maintain controls that can ensure that accidents, inadvertent mistakes, and errors are minimized,
  • Protect the system from intentional manipulation and fraud,
  • Protect the system from malicious mischief,
  • Identify fraudulent or erroneous changes to the system, and
  • Protect secrecy in the voting process.

These Standards are intended to address a broad range of risks to the integrity of a voting system. While it is not possible to identify all potential risks, the Standards identify several types of risk that must be addressed, including:

  • Unauthorized changes to system capabilities for defining ballot formats, casting and recording votes, calculating vote totals consistent with defined ballot formats, and reporting vote totals,
  • Alteration of voting system audit trails,
  • Altering a legitimately cast vote,
  • Preventing the recording of a legitimately cast vote,
  • Introducing data for a vote not cast by a registered voter,
  • Changing calculated vote totals,
  • Preventing access to vote data, including individual votes and vote totals, to unauthorized individuals, and Start Printed Page 18932
  • Preventing access to voter identification data and data for votes cast by the voter such that an individual can determine the content of specific votes cast by the voter.

Section 7—Quality Assurance: In the Standards, quality assurance is a vendor function with associated practices that confirms throughout the system development and maintenance life-cycle that a voting system conforms with the Standards and other requirements of state and local jurisdictions. Quality assurance focuses on building quality into a system and reducing dependence on system tests at the end of the life-cycle to detect deficiencies.

This section describes the responsibilities of the voting system vendor for designing and implementing a quality assurance program to ensure that the design, workmanship, and performance requirements of the Standards are achieved in all delivered systems and components. These responsibilities include:

  • Development of procedures for identifying and procuring parts and raw materials of the requisite quality, and for their inspection, acceptance, and control.
  • Documentation of hardware and software development processes.
  • Identification and enforcement of all requirements for in-process inspection and testing that the manufacturer deems necessary to ensure proper fabrication and assembly of hardware, as well as installation and operation of software or firmware.
  • Procedures for maintaining all data and records required to document and verify the quality inspections and tests.

Section 8—Configuration Management: This section contains specific requirements for configuration management of voting systems. For the purposes of the Standards, configuration management is defined as a set of activities and associated practices that assures full knowledge and control of the components of a system, beginning with its initial development, progressing throughout its development and construction, and continuing with its ongoing maintenance and enhancement. This section describes activities in terms of their purpose and outcomes. It does not describe specific procedures or steps to be employed to accomplish them—these are left to the vendor to select.

The requirements of this section address a broad set of record keeping, audit, and reporting activities that include:

  • Identifying discrete system components,
  • Creating records of formal baselines of all components,
  • Creating records of later versions of components,
  • Controlling changes made to the system and its components,
  • Submitting new versions of the system to Independent Test Authorities (ITA)s,
  • Releasing new versions of the system to customers,
  • Auditing the system, including its documentation, against configuration management records,
  • Controlling interfaces to other systems, and
  • Identifying tools used to build and maintain the system.

Vendors are required to submit documentation of these procedures to the ITA as part of the Technical Data Package for system qualification testing. Additionally, as articulated in state or local election laws, regulations, or contractual agreements with vendors, authorized election officials or their representatives reserve the right to inspect vendor facilities and operations to determine conformance with the vendor's reported configuration management procedures.

Section 9—Overview of Qualification Tests: This section provides an overview for the qualification testing of voting systems. Qualification testing is the process by which a voting system is shown to comply with the requirements of the Standards and the requirements of its own design and performance specifications. The testing also evaluates the completeness of the vendor's developmental test program, including the sufficiency of vendor tests conducted to demonstrate compliance with stated system design and performance specifications, and the vendor's documented quality assurance and configuration management practices.

The qualification test process is intended to discover errors that, should they occur in actual election use, could result in failure to complete election operations in a satisfactory manner. This section describes the scope of qualification testing, its applicability to voting system components, documentation that is must be submitted by the vendor, and the flow of the test process. This section also describes differences between the test process for initial qualification testing of a system and the testing for modifications and re-qualification after a qualified system has been modified.

Since 1994, the testing described in this section has been performed by an ITA that is certified by NASED. For the future, HAVA provides for EAC-accredited testing authorities. HAVA tasks the Director of NIST to assist the EAC by recommending laboratories for EAC accreditation. NIST's National Voluntary Laboratory Accreditation Program (NVLAP) is developing a program to evaluate competent laboratories. While laboratories are being evaluated for recommendation by the Director, testing will continue to be done by the ITAs previously certified by NASED. The testing may be conducted by one or more ITAs for a given system, depending on the nature of tests to be conducted and the expertise of the certified ITA. The testing process involves the assessment of, but is not limited to:

  • Absolute correctness of all ballot processing software, for which no margin for error exists,
  • Operational accuracy in the recording and processing of voting data, as measured by the error rate articulated in Volume I, Section 3,
  • Operational failure or the number of unrecoverable failures under conditions simulating the intended storage, operation, transportation, and maintenance environments for voting systems, using an actual time-based period of processing test ballots,
  • System performance and function under normal and abnormal conditions, and
  • Completeness and accuracy of the system documentation and configuration management records to enable purchasing jurisdictions to effectively install, test, and operate the system.

Summary of Volume II Content

Section 1—Introduction: This section provides an overview of Volume II, addressing the following topics:

  • Objectives of Volume II,
  • General contents of Volume II,
  • Qualification testing focus,
  • Qualification testing sequence,
  • Evolution of testing, and
  • Outline of contents.

Section 2—Technical Data Package: This section contains a description of vendor documentation relating to the voting system that shall be submitted with the system as a precondition for qualification testing. These items are necessary to define the product and its method of operation; to provide the vendor's technical and test data supporting the its claims of the system's functional capabilities and performance levels; and to document instructions and procedures governing system operation and field maintenance. The content of the Technical Data Package (TDP) shall contain a complete description of the following information about the system: Start Printed Page 18933

  • Overall system design, including subsystems, modules, and interfaces,
  • Specific functional capabilities,
  • Performance and design specifications,
  • Design constraints and compatibility requirements,
  • Personnel, equipment, and facilities necessary for system operation, maintenance, and logistical support,
  • Vendor practices for assuring system quality during the system's development and subsequent maintenance, and
  • Vendor practices for managing the configuration of the system during development and for modifications to the system throughout its life-cycle.

Section 3—Functionality Testing: This section contains a description of the testing to be performed by the ITA to confirm the functional capabilities of a voting system submitted for qualification testing. It describes the scope and basis for functional testing, the general sequence of tests within the overall test process, and provides guidance on testing for accessibility. It also discusses testing of functionality of systems that operate on personal computers.

Section 4—Hardware Testing: This section contains a description of the testing to be performed by the ITAs to confirm the proper functioning of the hardware components of a voting system submitted for qualification testing. This section requires ITAs to design and perform procedures that test the voting system hardware for both operating and non-operating environmental tests. Hardware testing begins with non-operating tests that require the use of an environmental test facility. These are followed by operating tests that are performed partly in an environmental facility and partly in a standard test laboratory or shop environment. The non-operating tests are intended to evaluate the ability of the system hardware to withstand exposure to various environmental conditions incidental to voting system storage, maintenance, and transportation. The procedures are based on test methods contained in Military Standards (MIL-STD) 810D, modified where appropriate, and include such tests as: Bench handling, vibration, low and high temperature, and humidity.

The operating tests involve running the system for an extended period of time under varying temperatures and voltages. This ensures that the hardware meets or exceeds the minimum requirements for reliability, data reading, and processing accuracy contained in Section 3 of Volume I. Although the procedure emphasizes equipment operability and data accuracy, it is not an exhaustive evaluation of all system functions. Moreover, the severity of the test conditions has in most cases been reduced from that specified in the Military Standards to reflect commercial, rather than military, practice.

Section 5—Software Testing: This section contains a description of the testing to be performed by the ITAs to confirm the proper functioning of the software components of a voting system submitted for qualification testing. It describes the scope and basis for software testing, the initial review of documentation to support software testing, and the review of voting system source code.

The software qualification tests encompass a number of interrelated examinations. The examinations include selective review of source code for conformance with the vendor's stated standards, and other system documentation provided by the vendor. The code inspection is complemented by a series of functional tests to verify the proper performance of all system functions controlled by the software.

Section 6—System Level Integration Testing: This section contains a description of the testing conducted by the ITAs to confirm the proper functioning of the fully integrated components of a voting system submitted for qualification testing. It describes the scope and basis for integration testing, testing of internal and external system interfaces, testing of security capabilities, testing of accessibility features, and the configuration audits, including the evaluation of claims made in the system documentation.

System-level qualification tests address the integrated operation of hardware, software and telecommunications capabilities (where applicable) to assess the system's response to a range of both normal and abnormal conditions in an attempt to compromise the system.

Section 7—Examination of Vendor Practices for Configuration Management and Quality Assurance: This section contains a description of examinations conducted by the ITAs to evaluate the extent to which vendors meet the requirements for configuration management and quality assurance. It describes the scope and basis for the examinations and the general sequence of the examinations. It also provides guidance on the substantive focus of the examinations.

In reviewing configuration management practices, the ITAs examine the vendor's:

  • Configuration management policy,
  • Configuration identification policy,
  • Baseline, promotion and demotion procedures,
  • Configuration control procedures,
  • Release process and procedures, and
  • Configuration audit procedures.

In reviewing quality assurance practices, the ITAs examine the vendor's:

  • Quality assurance policy,
  • Parts and materials tests and examinations,
  • Quality conformance plans, procedures and inspection results, and
  • Voting system documentation.

Volume I, Section 1

Table of Contents

1 Introduction

1.1 Objectives and Usage of the Voting System Standards

1.2 Development History for Initial Standards

1.3 Update of the Standards

1.4 Accessibility for Individuals with Disabilities

1.5 Definitions

1.5.1 Voting System

1.5.2 Paper-Based Voting System

1.5.3 Direct Record Electronic (DRE) Voting System

1.5.4 Public Network Direct Record Electronic (DRE) Voting System

1.5.5 Precinct Count Voting System

1.5.6 Central Count Voting System

1.6 Application of the Standards and Test Specifications

1.6.1 Qualification Tests

1.6.2 Certification Tests

1.6.3 Acceptance Tests

1.7 Conformance Clause

1.7.1 Scope and Applicability

1.7.2 Conformance Framework

1.7.2.1 Applicable entities

1.7.2.2 Relationship among entities

1.7.2.3 Conformance designations

1.7.3 Normative Language

1.7.4 Categorizing Requirements

1.7.5 Extensions

1.7.6 Implementation Statement

1.8 Outline of Contents

Introduction

1.1 Objectives and Usage of the Voting System Standards

State and local officials today are confronted with increasingly complex voting system technology and an increased risk of voting system failure. Responding to calls for assistance from the states, the United States Congress authorized the Federal Election Commission (FEC) to develop voluntary national voting systems standards for computer-based systems. The resulting FEC Voting System Standards (“the Start Printed Page 18934Standards”) seek to aid state and local election officials in ensuring that new voting systems are designed to function accurately and reliably, thus ensuring the system's integrity. States are free to adopt the Standards in whole or in part. States may also choose to enact stricter performance requirements for systems used in their jurisdictions.

The Standards specify minimum functional requirements, performance characteristics, documentation requirements, and test evaluation criteria. For the most part, the Standards address what a voting system should reliably do, not how system components should be configured to meet these requirements. It is not the intent of the Standards to impede the design and development of new, innovative equipment by vendors. Furthermore, the Standards balance risk and cost by requiring voting systems to have essential, but not excessive, capabilities.

The Standards are not intended to define appropriate election administration practices. However, the total integrity of the election process can only be ensured if implementation of the Standards is coupled with effective election administration practices.

The Standards are intended for use by multiple audiences to support their respective roles in the development, testing, and acquisition of voting systems:

  • Authorities responsible for the analysis and testing of such systems in support of qualification and/or certification of systems for purchase within a designated jurisdiction;
  • State and local agencies evaluating voting systems to be procured within their jurisdictions; and
  • Designers and manufacturers of voting systems.

1.2 Development History for Initial Standards

Much of the groundwork for the Standards' development was laid by a national study conducted in 1975 by the National Bureau of Standards, now known as the National Institute of Standards and Technology (NIST). This study was requested by the FEC's Office of Election Administrator's predecessor, the Office of Federal Elections of the General Accounting Office. The report, “Effective Use of Computing Technology in Vote-Tallying,” made a number of recommendations bearing directly on the Standards project. After analyzing computer-related election problems encountered in the past, the report concluded that one of the basic causes for these difficulties was the lack of appropriate technical skill at the state and local level for developing or implementing sophisticated and complex standards against which voting system hardware and software could be tested.

Following the release of this report, Congress mandated that the FEC, with the cooperation and assistance of the National Bureau of Standards, study and report on the feasibility of developing “voluntary engineering and procedural performance standards for voting systems used in the United States.” (2 U.S.C. 431 Note) The resulting 1983 study cited a substantial number of technical and managerial problems that affected the integrity of the vote counting process. It also asserted the need for a federal agency to develop national performance standards that could be used as a tool by state and local election officials in the testing, certification, and procurement of computer-based voting systems. In 1984, Congress approved initial funding for the Standards.

The FEC held a series of public hearings in developing the initial Standards. State and local election officials, election system vendors, technical consultants, and others reviewed drafts of the proposed criteria. The FEC considered their many comments and made appropriate revisions. Before final issuance, the FEC publicly announced the availability of the latest draft of the Standards in the Federal Register and requested that all interested parties submit final comments. The FEC meticulously reviewed all responses to the notice and incorporated corrections and suitable suggestions. Ultimately, the final product was the result of considerable deliberation, close consultation with election officials, and careful consideration of comments from all interested parties.

In January 1990, the FEC issued the performance standards and testing procedures for punchcard, marksense, and direct recording electronic (DRE) voting systems. The Standards did not cover paper ballot and mechanical lever systems because paper ballots are sufficiently self-explanatory not to require technical standards and mechanical lever systems are no longer manufactured or sold in the United States. The FEC also did not incorporate requirements for mainframe computer hardware because it was reasonable to assume that sufficient engineering and performance criteria already governed the operation of mainframe computers. However, vote tally software installed on mainframes is covered by the Standards.

1.3 Update of the Standards

Today, over two-thirds of the States have adopted the Standards in whole or in part. As a result, the voting systems marketed today are dramatically improved. Election officials are better assured that the voting systems they procure will work accurately and reliably. Voting system failures are declining and now primarily involve pre-Standard equipment, untested equipment configurations, or the mismanagement of tested equipment. Overall, systems integrity and the election processes have improved markedly.

However, advances in voting technology, legislative changes, and the proliferation of electronic voting systems make an update of the Standards necessary. The industry has been marked by widespread integration of personal computer technology and non-mainframe servers into DRE voting systems.

In addition, voting systems need to be responsive to the Americans with Disabilities Act (ADA) of 1990 and guidelines developed to assist in implementing the ADA.

1.4 Accessibility for Individuals With Disabilities

Voters and election officials who use voting systems represent a broad spectrum of the population, and include individuals with disabilities who may have difficulty using traditional voting systems. In developing accessibility provisions for the Standards, the FEC requested assistance from the Access Board, the federal agency in the forefront of promulgating accessibility provisions. The Access Board submitted technical standards designed to meet the diverse needs of voters with a broad range of disabilities. The FEC has adopted the entirety of the Access Board's recommendations and incorporated them into the Standards. These recommendations comprise the bulk of the accessibility provisions found in Section 2.2.7. Implementing these provisions, however, will not entirely eliminate the need to accommodate the needs of some disabled voters by human interface.

The FEC anticipates that during the lifetime of this version of the Standards increased obligations will be placed upon election officials at every jurisdictional level to provide voting equipment tailored to meet the needs of voters with disabilities. To facilitate jurisdictions in meeting accessibility needs, the Standards mandate that every voting system incorporate some accessible voting capabilities. The Start Printed Page 18935Standards also mandate that systems incorporating a DRE component meet specific technological requirements. To do so, it is anticipated that a vendor will have to either configure all of the system's voting stations to meet the accessibility specifications or will have to design a unique station that conforms to the accessibility requirements and is part of the overall voting system configuration.

Under no circumstances should compliance with requirements for accessibility be viewed as mutually exclusive from compliance with any other provision of the Standards. If a voting system contains a machine uniquely designed to meet the accessibility requirements, such a machine will be tested for compliance with the accessibility requirements, as well as for compliance with all of the DRE standards, in order to ensure that an accessible machine does not unintentionally abrogate the mandates of the Standards.

1.5 Definitions

The Standards contain terms describing function, design, documentation, and testing attributes of equipment and computer programs. Unless otherwise specified, the intended sense of technical terms is that which is commonly used by the information technology industry. In some cases terminology is specific to elections or voting systems, and a glossary of those terms is contained in Appendix A. Nontechnical terms not listed in Appendix A shall be interpreted according to their standard dictionary definitions.

Additionally, the following terms are defined below:

  • Voting system;
  • Paper-based voting system;
  • Direct record electronic (DRE) voting system;
  • Public network direct record electronic (DRE) voting system;
  • Precinct count voting system; and
  • Central count voting system.

1.5.1 Voting System

A voting system is a combination of mechanical, electromechanical, or electronic equipment. It includes the software required to program, control, and support the equipment that is used to define ballots; to cast and count votes; to report and/or display election results; and to maintain and produce all audit trail information. A voting system may also include the transmission of results over telecommunication networks.

Additionally, a voting system includes the associated documentation used to operate the system, maintain the system, identify system components and their versions, test the system during its development and maintenance, maintain records of system errors and defects, and determine specific changes made after system qualification. By definition, this includes all documentation required in Section 9.4.

Traditionally, a voting system has been defined by the mechanism the system uses to cast votes and further categorized by the location where the system tabulates ballots. However, the Standards recognize that as the industry develops unique solutions to various challenges and as voting systems become more responsive to the needs of election officials and voters, the rigid dichotomies between voting system types may be blurred. Innovations that use a fluid understanding of system types can greatly improve the voting system industry, but only if controls are in place to monitor and control integrity through the proper evaluation of the system brought for qualification.

As such, vendors that submit a system that integrates components from more than one traditional system type or a system that includes components not addressed in this Standard shall submit the results of all beta tests of the new system. Vendors also shall submit a proposed test plan to the appropriate independent test authority recognized by the National Association of State Election Directors (NASED) to conduct national qualification testing of voting systems. The Standards permit vendors to produce or utilize interoperable components of a voting system that are tested within the full voting system configuration.

1.5.2 Paper-Based Voting System

A Paper-Based Voting System, (referred to in the initial Standards as a Punchcard and Marksense [P&M] Voting System) records votes, counts votes, and produces a tabulation of the vote count from votes cast on paper cards or sheets. A punchcard voting system allows a voter to record votes by means of holes punched in designated voting response locations. A marksense voting system allows a voter to record votes by means of marks made by the voter directly on the ballot, usually in voting response locations. Additionally, a paper based system may record votes using other approaches whereby the voter's selections are indicated by marks made on a paper ballot by an electronic input device, as long as such an input device does not independently record, store, or tabulate the voters selections.

1.5.3 Direct Record Electronic (DRE) Voting System

A Direct Record Electronic (DRE) Voting System records votes by means of a ballot display provided with mechanical or electro-optical components that can be activated by the voter; that processes data by means of a computer program; and that records voting data and ballot images in memory components. It produces a tabulation of the voting data stored in a removable memory component and as printed copy. The system may also provide a means for transmitting individual ballots or vote totals to a central location for consolidating and reporting results from precincts at the central location.

1.5.4 Public Network Direct Record Electronic (DRE) Voting System

A Public Network Direct Record Electronic (DRE) Voting System is an election system that uses electronic ballots and transmits vote data from the polling place to another location over a public network as defined in Section 5.1.2. Vote data may be transmitted as individual ballots as they are cast, periodically as batches of ballots throughout the Election Day, or as one batch at the close of voting. For purposes of the Standards, Public Network DRE Voting Systems are considered a form of DRE Voting System and are subject to the standards applicable to DRE Voting Systems. However, because transmitting vote data over public networks relies on equipment beyond the control of the election authority, the system is subject to additional threats to system integrity and availability. Therefore, additional requirements discussed in Section 5 and 6 apply.

The use of public networks for transmitting vote data must provide the same level of integrity as other forms of voting systems, and must be accomplished in a manner that precludes three risks to the election process: Automated casting of fraudulent votes, automated manipulation of vote counts, and disruption of the voting process such that the system is unavailable to voters during the time period authorized for system use.

1.5.5 Precinct Count Voting System

A Precinct Count Voting System is a voting system that tabulates ballots at the polling place. These systems typically tabulate ballots as they are cast and print the results after the close of polling. For DREs, and for some paper-based systems, these systems provide Start Printed Page 18936electronic storage of the vote count and may transmit results to a central location over public telecommunication networks.

1.5.6 Central Count Voting System

A Central Count Voting System is a voting system that tabulates ballots from multiple precincts at a central location. Voted ballots are typically placed into secure storage at the polling place. Stored ballots are transported or transmitted to a central counting place. The systems produce a printed report of the vote count, and may produce a report stored on electronic media.

1.6 Application of the Standards and Test Specifications

The Standards apply to all system hardware, software, telecommunications, and documentation intended for use to:

  • Prepare the voting system for use in an election;
  • Produce the appropriate ballot formats;
  • Test that the voting system and ballot materials have been properly prepared and are ready for use;
  • Record and count votes;
  • Consolidate and report results;
  • Display results on-site or remotely; and
  • Maintain and produce all audit trail information.

In general, the Standards define functional requirements and performance characteristics that can be assessed by a series of defined tests. Standards are mandatory requirements and are designated by use of the term “shall.”

Some voting systems use one or more readily available commercial off-the-shelf (COTS) devices (such as card readers, printers, or personal computers) or software products (such as operating systems, programming language compilers, or database management systems). COTS devices and software are exempted from certain portions of the qualification testing process as defined herein, as long as such products are not modified for use in a voting system.

Generally, voting systems are subject to the following three testing phases prior to being purchased or leased:

  • Qualification tests;
  • State certification tests; and
  • State and/or local acceptance tests.

1.6.1 Qualification Tests

Qualification tests validate that a voting system meets the requirements of the Standards and performs according to the vendor's specifications for the system. Such tests encompass the examination of software; the inspection and evaluation of system documentation; tests of hardware under conditions simulating the intended storage, operation, transportation, and maintenance environments; operational tests to validate system performance and function under normal and abnormal conditions; and examination of the vendor's system development, testing, quality assurance, and configuration management practices. Qualification tests address individual system components or elements, as well as the integrated system as a whole.

Since 1994, qualification tests for voting systems have been performed by Independent Test Authorities (ITAs) certified by the National Association of State Election Directors (NASED). NASED has certified an ITA for either the full scope of qualification testing or a distinct subset of the total scope of testing. To date, ITAs have been certified only for distinct subsets of testing. Upon the successful completion of testing by an ITA, the ITA issues a Qualification Test Report to the vendor and NASED. The qualification test report remains valid for as long as the voting system remains unchanged.

Upon receipt of test reports that address the full scope of testing, NASED issues a Qualification Number that indicates the system has been tested by certified ITAs for compliance with the Standards and qualifies for the certification process of states that have adopted the Standards. The Qualification Number applies to the system as a whole, and does not apply to individual system components or untested configurations.

After a system has completed qualification testing, further examination of a system is required if modifications are made to hardware, software, or telecommunications, including the installation of software on different hardware. Vendors request review of modifications by the appropriate ITA based on the nature and scope of changes made and the scope of the ITA's role in NASED qualification. The ITA will determine the extent to which the modified system should be resubmitted for qualification testing and the extent of testing to be conducted.

Generally, a voting system remains qualified under the standards against which it was tested, as long as no modifications not approved by an ITA are made to the system. However, if a new threat to a particular voting system is discovered, it is the prerogative of NASED to determine which qualified voting systems are vulnerable, whether those systems need to be retested, and the specific tests to be conducted. In addition, when new standards supersede the standards under which the system was qualified, it is the prerogative of NASED to determine when systems that were qualified under the earlier standards will lose their qualification, unless they are tested to meet current standards.

Among other things, qualification testing complements and evaluates the vendor's developmental testing and beta testing. The ITA is expected to evaluate the completeness of the vendor's developmental test program, including the sufficiency of vendor tests conducted to demonstrate compliance with the Standards as well as the system's performance specifications. The ITA undertakes sample testing of the vendor's test modules and also designs independent system-level tests to supplement and check those designed by the vendor. Although some of the qualification tests are based on those prescribed in the Military Standards, in most cases the test conditions are less stringent, reflecting commercial, rather than military, practice.

1.6.2 Certification Tests

Certification tests are performed by individual states, with or without the assistance of outside consultants, to:

  • Confirm that the voting system presented is the same as the one qualified through the Standards;
  • Test for the proper implementation of state-specific requirements;
  • Establish a baseline for future evaluations or tests of the system, such as acceptance testing or state review after modifications have been made; and
  • Define acceptance tests.

Precise certification test scripts are not included in the Standards, as they must be defined by the state, with its laws, election practices, and needs in mind. However, it is recommended that they not duplicate qualification tests, but instead focus on functional tests and qualitative assessment to ensure that the system operates in a manner that is acceptable under state law. If a voting system is modified after state certification, it is recommended that States reevaluate the system to determine if further certification testing is warranted.

Certification tests performed by individual states typically rely on information contained in documentation provided by the vendor for system design, installation, operations, required facilities and supplies, personnel support and other aspects of the voting system. States and jurisdictions may define information and documentation requirements additional to those defined in the Start Printed Page 18937Standards. By design, the Standards, and qualification testing of voting systems for compliance with the Standards, do not address these additional requirements. However, qualification testing addresses all capabilities of a voting system stated by the vendor in the system documentation submitted to an ITA, including additional capabilities that are not required by the Standards.

1.6.3 Acceptance Tests

Acceptance tests are performed at the state or local jurisdiction level upon system delivery by the vendor to:

  • Confirm that the system delivered is the specific system qualified by NASED and, when applicable, certified by the state;
  • Evaluate the degree to which delivered units conform to both the system characteristics specified in the procurement documentation, and those demonstrated in the qualification and certification tests; and
  • Establish a baseline for any future required audits of the system.

Some of the operational tests conducted during qualification may be repeated during acceptance testing.

1.7 Conformance Clause

1.7.1 Scope and Applicability

The Voluntary Voting System Guidelines (VVSG) define requirements for conformance of voting systems. Conformance is defined in terms of requirements that voting system vendors claiming conformance to these Guidelines shall meet. The VVSG also provides the framework, procedures, and requirements that testing authorities responsible for the qualification of voting systems shall follow in order to qualify a voting system for EAC certification. The requirements and procedures in the VVSG may also be used by States to certify voting systems. To ensure that correct voting system software has been distributed without modification, the VVSG includes requirements for a national software repository. Finally, the VVSG provides guidance in the form of best practices to voting officials. These best practices are not mandated and are not subject to testing by testing authorities to qualify voting systems. They are provided as adjuncts to the technical requirements for voting systems in order to ensure the integrity of the voting process and to assist States in properly setting up, deploying, and operating voting systems.

The Voluntary Voting System Guidelines define the minimum requirements for voting systems and the process of testing voting systems. The guidelines are intended for use by:

1. Designers and manufacturers of voting systems,

2. Testing authorities responsible for the analysis and testing of voting systems in support of qualification of systems for purchase within a designated jurisdiction,

3. National software repositories, either maintained by the National Institute of Standard and Technology (NIST) or other EAC designated repository,

4. (Optionally) Voting officials, including election judges, poll workers, ballot designers and officials responsible for the installation, operation, and maintenance of voting machines, and

5. (Optionally) testing authorities responsible for the State certification of voting systems.

Minimum requirements specified in these guidelines include:

  • Functional requirements,
  • Performance characteristics,
  • Documentation requirements,
  • Test evaluation criteria, and
  • Procedural requirements.

1.7.2 Conformance Framework

This section provides the framework in which conformance is defined. It identifies the entities for which these guidelines apply, the relationship among the various entities and these guidelines, structure of requirements, and the terminology used to indicate conformance.

1.7.2.1 Applicable Entities

The requirements, prohibitions, options, and guidance specified in these guidelines apply to voting systems, voting system vendors, testing authorities, and repositories.

In general, requirements for designers and manufacturers of voting systems in these guidelines apply to all voting systems, unless prefaced with explanatory narrative describing unique applicability. Other terms in these guidelines shall be construed as synonymous with “all voting systems.” They are:

  • “all systems,”
  • “systems,”
  • “the system,”
  • “the voting system,” and
  • “each voting system.”

The term “voting system vendor” imposes documentation or testing requirements on voting systems, via the manufacturer or vendor. Other terms in these guidelines shall be construed as synonymous with “voting system vendor. They are:

  • “vendors,”
  • “the vendor,”
  • “manufacturer or vendor,”
  • “voting system designers,” and
  • “implementer.”

The terms used to designate requirements and procedural guidelines for testing authorities are indicated by referring to Independent Testing Authority (ITA) and EAC accredited testing authority. Under HAVA, ITAs have been replaced by EAC accredited testing authorities. In these guidelines, EAC accredited testing authority and ITA shall be considered equivalent. In addition, the National Association of State Election Directors (NASED) activities specified in these guidelines shall be performed by the Election Assistance Commission (EAC).

The term “repository” will be used to designate requirements levied on the national software repository maintained at NIST or any other EAC designated repository. The repository maintained at NIST is called the National Software Reference Library (NSRL).

Guidance and best practices for voting officials are indicated by the notation “Best Practices for Voting Officials” preceding the best practice statement.

1.7.2.2 Relationship Among Entities

Although conformance is defined for voting systems, it is the voting system vendor that needs to implement these requirements and provide the necessary documentation with the system. In order to claim conformance to the Voluntary Voting Systems Guidelines, the voting system vendor shall satisfy the minimum requirements specified in the VVSG, including implementation of functionality, prescribed software coding and assurance practices, and preparation of the Technical Data Package (TDP). In order to claim that a voting system is qualified, the voting system vendor shall satisfy the requirements for qualification testing and successfully complete the test campaign with an ITA/testing authority.

An ITA/EAC accredited test authority shall satisfy the requirements for conducting qualification testing. The ITA/EAC accredited test authority may use an operational environment that is derived from the VVSG best practice guidelines for voting officials as part of their testing to ensure that the voting system can be configured and operated in a secure and reliable manner according to the voting system vendor's documentation and as specified by the VVSG. Additionally, the ITA/EAC accredited test authority shall coordinate and deliver the requisite documentation to the EAC and copies of voting system software to the repository. Note that in the VVSG, these Start Printed Page 18938requirements and the relationship between the ITA/EAC accredited test authority and the certification authority is with NASED, not the EAC.

The EAC is assuming the responsibility for certification of voting systems from NASED.

The VVSG provides guidance denoted as “Best Practices for Voting Officials.” This guidance may be used to allow jurisdictions to incorporate appropriate procedures to help ensure that their voting systems are reliable, accessible, usable, and secure. Furthermore, this guidance may be used in training and incorporated into written procedures for properly conducting the election and operating voting systems.

Figure 1 provides an illustration of these relationships.

1.7.2.3 Structure of Requirements

Sections of this document that augment the VSS-2002, by either replacing VSS-2002 sections or adding new sections, are indicated by line numbers, footer information (i.e., New Material, date, etc.) at the bottom of pages with new material, and hierarchically structured requirements. Each requirement is numbered according to a hierarchical scheme in which higher-level requirements (such as “provide accessibility for blind voters”) are supported by lower-level requirements (“provide an audio-tactile interface”). Thus, requirements are contained (i.e., nested) within other requirements. A nested requirement or lower-level requirement is a ‘child’ to its ‘parent’ or higher-level requirement.

Some of these requirements are directly testable and some are not. The latter tend to be higher-level and are included because (1) they are testable indirectly insofar as their lower-level, children requirements are testable, and (2) they often provide the structure and rationale for the lower-level requirements. Satisfying the lower-level requirement will result in satisfying its higher-level ‘parent’ requirement.

1.7.2.4 Conformance Designations

A voting system conforms if all the mandatory requirements that apply to the voting system are fulfilled. An implementation statement (see Section 1.7.6) or similar mechanism is used to describe the capabilities, features and optional functions that have been implemented and are subject to conformance and qualification testing. There is no concept of partial conformance, e.g., a voting system is 80% conforming.

1.7.3 Normative Language

The following keywords are used to convey conformance requirements.

  • Shall—to indicate a mandatory requirement to be followed (implemented) in order to conform. Synonymous with “is required to.”
  • Is prohibited—to indicate a mandatory requirement that indicates something that is not permitted (allowed), in order to conform. Synonymous with “shall not.”
  • Should, Is encouraged—to indicate an optional recommended action, one that is particularly suitable, without mentioning or excluding others. Synonymous with “is permitted and recommended.”
  • May—to indicate an optional, permissible action. Synonymous with “is permitted.”

Normative text is directly applicable to achieving conformance to this document. Informative parts of this document include examples, extended explanations, and other matter that contain information necessary for proper understanding of the VVSG and conformance to it. Some sections in the VSSG have narrative text prefixed by the keywords: Discussion or Best Practices for Voting Officials. This text is informative and has no bearing on conformance. Start Printed Page 18939

1.7.4 Categorizing Requirements

In addition to defining a common set of requirements that apply to all voting systems, the VVSG categorizes some requirements into related groups of functionality to address equipment type, ballot tabulation location, and voting system component (e.g., election management system). Hence, not all requirements apply to all voting systems. Specifically, if a category is not applicable to a voting system, then the requirements in that category are not applicable. For example, requirements categorized as “DRE Systems” (as in Volume I, Section 2.4.9) are not applicable to paper-based voting systems and thus are ignored by paper-based systems.

Among the categories defined in the VVSG are two types of voting systems with respect to mechanisms to cast votes—Paper-Based Voting Systems and Direct Record Electronic (DRE) Voting Systems. Additionally, voting systems are further categorized, in these guidelines, by the locations where ballots are tabulated—Precinct Count Voting Systems, which tabulate ballots at the polling place, and Central Count Voting Systems, which tabulate ballots from multiple precincts at a central location. The VVSG defines specific requirements for systems that fall within these four categories as well as various combinations of these categories.

Other categories for which requirements are defined include: election management systems (EMS), methods of independent verification, and telecommunication components.

1.7.5 Extensions

Extensions are additional functions, features, and/or capabilities included in a voting system that are not required by the VVSG. To accommodate the needs of States that may impose additional requirements beyond those listed in these guidelines and to accommodate changes in technology, these guidelines allow extensions. Thus, a voting system may include extensions and still be conformant to the VVSG. The use of extensions shall not contradict nor cause the nonconformance of functionality defined in the VVSG.

1.7.6 Implementation Statement

An implementation statement provides information about a voting system, by documenting the requirements that have been implemented by the voting system. It can also be used to highlight optional features and capabilities supported by the voting system, as well as to document any extensions (i.e., additional functionality beyond what is required in the standard). An implementation statement may take the form of a checklist, to be completed for each voting system for which a claim of conformance to the VVSG or subset of the VVSG is desired.

An implementation statement provides a concise summary and a quick overview of requirements that have been implemented. The implementation statement may also be used to identify the subset of a test suite that would be applicable to the voting system being tested.

If an implementation statement is provided, it shall include identifying information about the voting system, including at a minimum versioning and date information. Additionally, a narrative description of the voting system shall be included in the implementation statement.

1.8 Outline of Contents

The organization of the Standards has been simplified to facilitate its use. Volume I, Voting System Performance Standards, is intended for use by the broadest audience, including voting system developers, equipment manufacturers and suppliers, independent test authorities, local agencies that purchase and deploy voting systems, state organizations that certify a system prior to procurement by a local jurisdiction, and public interest organizations that have an interest in voting systems and voting systems standards.

  • Section 2 describes the functional capabilities required of voting systems.
  • Sections 3 through 6 describe specific performance standards for election system hardware, software, telecommunications and security, respectively.
  • Sections 7 and 8 describe practices for quality assurance and configuration management, respectively, to be used by vendors, and required information about vendor practices that will be reviewed in concert with system qualification and certification test processes and system purchase decisions.
  • Section 9 provides an overview of the test and measurement process used by test authorities for qualification and re-qualification of voting systems.
  • Appendix A provides a glossary of important terms used in Volume I.
  • Appendix B lists the publications that were used for guidance in the preparation of the Standards. These publications contain information that is useful in interpreting and complying with the requirements of the Standards.
  • Appendix C addresses issues of usability of voting systems, commonly referred to as “human factors.” This appendix does not represent mandates that voting systems will be tested against, but rather contain recommendations and best practices on usability issues designed to provide vendors and election officials with guidance on designing and procuring systems that are easy and intuitive to use by voters.

Volume II, Voting System Qualification Testing Standards describes the standards for the technical information submitted by the vendor to support testing; the development of test plans by the ITA for initial system testing and testing of system modifications; the conduct of system qualification tests by the ITA; and the test reports generated by the ITA. This volume complements the content of Volume I and is intended primarily for use by ITAs, state organizations that certify a system, and vendors.

Volume I, Section 2

Table of Contents

2 Functional Capabilities

2.1 Scope

2.2 Overall System Capabilities

2.2.1 Security

2.2.2 Accuracy

2.2.2.1 Common Standards

2.2.2.2 DRE System Standards

2.2.3 Error Recovery

2.2.4 Integrity

2.2.4.1 Common Standards

2.2.4.2 DRE Systems Standards

2.2.5 System Audit

2.2.5.1 System Audit Purpose and Context

2.2.5.2 Operational Requirements

2.2.5.3 COTS General Purpose Computer System Requirements

2.2.6 Election Management System

2.2.7 Human Factors

2.2.7.1 Accessibility

2.2.7.2 Limited English Proficiency

2.2.7.3 Usability

2.2.7.4 Privacy

2.2.8 Vote Tabulating Program

2.2.8.1 Functions

2.2.8.2 Voting Variations

2.2.9 Ballot Counter

2.2.10 Telecommunications

2.2.11 Data Retention

2.3 Pre-Voting Functions

2.3.1 Ballot Preparation

2.3.1.1 General Capabilities

2.3.1.2 Ballot Formatting

2.3.1.3 Ballot Production

2.3.2 Election Programming

2.3.3 Ballot and Program Installation and Control

2.3.4 Readiness Testing

2.3.4.1 Common Standards

2.3.4.2 Paper-Based Systems

2.3.5 Verification at the Polling Place

2.3.6 Verification at the Central Location

2.4 Voting Functions

2.4.1 Opening the Polls

2.4.1.1 Opening the Polling Place (Precinct Count Systems)Start Printed Page 18940

2.4.1.2 Paper-Based System Standards

2.4.1.3 DRE System Standards

2.4.2 Activating the Ballot (DRE Systems)

2.4.3 Casting a Ballot

2.4.3.1 Common Standards

2.4.3.2 Paper-Based Systems Standards

2.4.3.3 DRE Systems Standards

2.5 Post-Voting Functions

2.5.1 Closing the Polling Place (Precinct Count)

2.5.2 Consolidating Vote Data

2.5.3 Producing Reports

2.5.3.1 Common Standards

2.5.3.2 Precinct Count Systems

2.5.4 Broadcasting Results

2.6 Maintenance, Transportation, and Storage

Functional Capabilities

2.1 Scope

This section contains standards detailing the functional capabilities required of a voting system. This section sets out precisely what it is that a voting system is required to do. In addition, this section sets forth the minimum actions a voting system must be able to perform to be eligible for qualification.

For organizational purposes, functional capabilities are categorized by the phase of election activity in which they are required:

Overall Capabilities: These functional capabilities apply throughout the election process. They include security, accuracy, integrity, system auditability, election management system, vote tabulation, ballot counters, telecommunications, and data retention.

Pre-voting Capabilities: These functional capabilities are used to prepare the voting system for voting. They include ballot preparation, the preparation of election-specific software (including firmware), the production of ballots or ballot pages, the installation of ballots and ballot counting software (including firmware), and system and equipment tests.

Voting Capabilities: These functional capabilities include all operations conducted at the polling place by voters and officials including the generation of status messages.

Post-voting Capabilities: These functional capabilities apply after all votes have been cast. They include closing the polling place; obtaining reports by voting machine, polling place, and precinct; obtaining consolidated reports; and obtaining reports of audit trails.

Maintenance, Transportation and Storage Capabilities: These capabilities are necessary to maintain, transport, and store voting system equipment.

In recognition of the diversity of voting systems, the Standards apply specific requirements to specific technologies. Some of the Standards apply only if the system incorporates certain optional functions (for example, voting systems employing telecommunications to transmit voting data). For each functional capability, common standards are specified. Where necessary, common standards are followed by standards applicable to specific technologies (i.e., paper-based or DRE) or intended use (i.e., central or precinct count).

2.2 Overall System Capabilities

This section defines required functional capabilities that are system-wide in nature and not unique to pre-voting, voting, and post-voting operations. All voting systems shall provide the following functional capabilities:

  • Security;
  • Accuracy;
  • Error recovery;
  • Integrity;
  • System auditability;
  • Election management system;
  • Accessibility:
  • Vote tabulating;
  • Ballot counters; and
  • Data Retention.

Voting systems may also include telecommunications components. Technical standards for these capabilities are described in Sections 3 through 6 of the Standards.

2.2.1 Security

System security is achieved through a combination of technical capabilities and sound administrative practices. To ensure security, all systems shall:

a. Provide security access controls that limit or detect access to critical system components to guard against loss of system integrity, availability, confidentiality, and accountability.

b. Provide system functions that are executable only in the intended manner and order, and only under the intended conditions.

c. Use the system's control logic to prevent a system function from executing if any preconditions to the function have not been met.

d. Provide safeguards to protect against tampering during system repair, or interventions in system operations, in response to system failure.

e. Provide security provisions that are compatible with the procedures and administrative tasks involved in equipment preparation, testing, and operation.

f. If access to a system function is to be restricted or controlled, the system shall incorporate a means of implementing this capability.

g. Provide documentation of mandatory administrative procedures for effective system security.

2.2.2  Accuracy

Memory hardware, such as semiconductor devices and magnetic storage media, must be accurate. The design of equipment in all voting systems shall provide for the highest possible levels of protection against mechanical, thermal, and electromagnetic stresses that impact system accuracy. Section 3 provides additional information on susceptibility requirements.

2.2.2.1 Common Standards

To ensure vote accuracy, all systems shall:

a. Record the election contests, candidates, and issues exactly as defined by election officials;

b. Record the appropriate options for casting and recording votes;

c. Record each vote precisely as indicated by the voter and be able to produce an accurate report of all votes cast;

d. Include control logic and data processing methods incorporating parity and check-sums (or equivalent error detection and correction methods) to demonstrate that the system has been designed for accuracy; and

e. Provide software that monitors the overall quality of data read-write and transfer quality status, checking the number and types of errors that occur in any of the relevant operations on data and how they were corrected.

2.2.2.2 DRE System Standards

As an additional means of ensuring accuracy in DRE systems, voting devices shall record and retain redundant copies of the original ballot image. A ballot image is an electronic record of all votes cast by the voter, including undervotes.

2.2.3 Error Recovery

To recover from a non-catastrophic failure of a device, or from any error or malfunction that is within the operator's ability to correct, the system shall provide the following capabilities:

a. Restoration of the device to the operating condition existing immediately prior to the error or failure, without loss or corruption of voting data previously stored in the device;

b. Resumption of normal operation following the correction of a failure in a memory component, or in a data processing component, including the central processing unit; and

c. Recovery from any other external condition that causes equipment to become inoperable, provided that catastrophic electrical or mechanical damage due to external phenomena has not occurred. Start Printed Page 18941

2.2.4 Integrity

Integrity measures ensure the physical stability and function of the vote recording and counting processes.

2.2.4.1 Common Standards

To ensure system integrity, all systems shall:

a. Protect, by a means compatible with these Standards, against a single point of failure that would prevent further voting at the polling place;

b. Protect against the interruption of electronic power;

c. Protect against generated or induced electromagnetic radiation;

d. Protect against ambient temperature and humidity fluctuations;

e. Protect against the failure of any data input or storage device;

f. Protect against any attempt at improper data entry or retrieval;

g. Record and report the date and time of normal and abnormal events;

h. Maintain a permanent record of all original audit data that cannot be modified or overridden but may be augmented by designated authorized officials in order to adjust for errors or omissions (e.g. during the canvassing process.)

i. Detect and record every event, including the occurrence of an error condition that the system cannot overcome, and time-dependent or programmed events that occur without the intervention of the voter or a polling place operator; and

j. Include built-in measurement, self-test, and diagnostic software and hardware for detecting and reporting the system's status and degree of operability.

2.2.4.2 DRE Systems Standards

In addition to the common standards, DRE systems shall:

a. Maintain a record of each ballot cast using a process and storage location that differs from the main vote detection, interpretation, processing, and reporting path; and

b. Provide a capability to retrieve ballot images in a form readable by humans.

2.2.5 System Audit

This section describes the context and purpose of voting system audits and sets forth specific functional requirements. Additional technical audit requirements are set forth in Section 4.

2.2.5.1 System Audit Purpose and Context

Election audit trails provide the supporting documentation for verifying the correctness of reported election results. They present a concrete, indestructible archival record of all system activity related to the vote tally, and are essential for public confidence in the accuracy of the tally, for recounts, and for evidence in the event of criminal or civil litigation.

The following audit trail requirements are based on the premise that system-generated creation and maintenance of audit records reduces the chance of error associated with manually generated audit records. Because most audit capability is automatic, the system operator has less information to track and record, and is less likely to make mistakes or omissions.

The sections that follow present operational requirements critical to acceptable performance and reconstruction of an election. Requirements for the content of audit records are described in Section 4 of the Standards.

The requirements for all system types, both precinct and central count, are described in generic language. Because the actual implementation of specific characteristics may vary from system to system, it is the responsibility of the vendor to describe each system's characteristics in sufficient detail that ITAs and system users can evaluate the adequacy of the system's audit trail. This description shall be incorporated in the System Operating Manual, which is part of the Technical Data Package (TDP).

Documentation of items such as paper ballots delivered and collected, administrative procedures for system security, and maintenance performed on voting equipment are also part of the election audit trail, but are not covered in these technical standards. Future volumes of the Standards will address these and other system operations practices. In the interim, useful guidance is provided by the Innovations in Election Administration #10, Ballot Security and Accountability, available from the FEC's Office of Election Administration.

2.2.5.2 Operational Requirements

Audit records shall be prepared for all phases of elections operations performed using devices controlled by the jurisdiction or its contractors. These records rely upon automated audit data acquisition and machine-generated reports, with manual input of some information. These records shall address the ballot preparation and election definition phase, system readiness tests, and voting and ballot-counting operations. The software shall activate the logging and reporting of audit data as described in the following sections.

2.2.5.2.1 Time, Sequence, and Preservation of Audit Records

The timing and sequence of audit record entries is as important as the data contained in the record. All voting systems shall meet the following requirements for time, sequence and preservation of audit records:

a. Except where noted, systems shall provide the capability to create and maintain a real-time audit record. This capability records and provides the operator or precinct official with continuous updates on machine status. This information allows effective operator identification of an error condition requiring intervention, and contributes to the reconstruction of election-related events necessary for recounts or litigation.

b. All systems shall include a real-time clock as part of the system's hardware. The system shall maintain an absolute record of the time and date or a record relative to some event whose time and data are known and recorded.

c. All audit record entries shall include the time-and-date stamp.

d. The audit record shall be active whenever the system is in an operating mode. This record shall be available at all times, though it need not be continually visible.

e. The generation of audit record entries shall not be terminated or altered by program control, or by the intervention of any person. The physical security and integrity of the record shall be maintained at all times.

f. Once the system has been activated for any function, the system shall preserve the contents of the audit record during any interruption of power to the system until processing and data reporting have been completed.

g. The system shall be capable of printing a copy of the audit record. A separate printer is not required for the audit record, and the record may be produced on the standard system printer if all the following conditions are met:

(1) The generation of audit trail records does not interfere with the production of output reports;

(2) The entries can be identified so as to facilitate their recognition, segregation, and retention; and

(3) The audit record entries are kept physically secure.

2.2.5.2.2 Error Messages

All voting systems shall meet the following requirements for error messages:

a. The system shall generate, store, and report to the user all error messages as they occur; Start Printed Page 18942

b. All error messages requiring intervention by an operator or precinct official shall be displayed or printed unambiguously in easily understood language text, or by means of other suitable visual indicators;

c. When the system uses numerical error codes for trained technician maintenance or repair, the text corresponding to the code shall be self-contained, or affixed inside the unit device. This is intended to reduce inappropriate reactions to error conditions, and to allow for ready and effective problem correction;

d. All error messages for which correction impacts vote recording or vote processing shall be written in a manner that is understandable to an election official who possesses training on system use and operation, but does not possess technical training on system servicing and repair;

e. The message cue for all systems shall clearly state the action to be performed in the event that voter or operator response is required;

f. System design shall ensure that erroneous responses will not lead to irreversible error; and

g. Nested error conditions shall be corrected in a controlled sequence such that system status shall be restored to the initial state existing before the first error occurred.

2.2.5.2.3 Status Messages

The Standards provide latitude in software design so that vendors can consider various user processing and reporting needs. The jurisdiction may require some status and information messages to be displayed and reported in real-time. Messages that do not require operator intervention may be stored in memory to be recovered after ballot processing has been completed.

The system shall display and report critical status messages using unambiguous indicators or English language text. The system need not display non-critical status messages at the time of occurrence. Systems may display non-critical status messages (i.e., those that do not require operator intervention) by means of numerical codes for subsequent interpretation and reporting as unambiguous text.

Systems shall provide a capability for the status messages to become part of the real-time audit record. The system shall provide a capability for a jurisdiction to designate critical status messages.

2.2.5.3 COTS General Purpose Computer System Requirements

Further requirements must be applied to COTS operating systems to ensure completeness and integrity of audit data for election software. These operating systems are capable of executing multiple application programs simultaneously. These systems include both servers and workstations (or “PCs”), including the many varieties of UNIX and Linux, and those offered by Microsoft and Apple. Election software running on these COTS systems is vulnerable to unintended effects from other user sessions, applications, and utilities, executing on the same platform at the same time as the election software.

“Simultaneous processes” of concern include unauthorized network connections, unplanned user logins, and unintended execution or termination of operating system processes. An unauthorized network connection or unplanned user login can host unintended processes and user actions, such as the termination of operating system audit, the termination of election software processes, or the deletion of election software audit and logging data. The execution of an operating system process could be a full system scan at a time when that process would adversely affect the election software processes. Operating system processes improperly terminated could be system audit or malicious code detection.

To counter these vulnerabilities, three operating system protections are required on all such systems on which election software is hosted. First, authentication shall be configured on the local terminal (display screen and keyboard) and on all external connection devices (“network cards” and “ports”). This ensures that only authorized and identified users affect the system while election software is running.

Second, operating system audit shall be enabled for all session openings and closings, for all connection openings and closings, for all process executions and terminations, and for the alteration or deletion of any memory or file object. This ensures the accuracy and completeness of election data stored on the system. It also ensures the existence of an audit record of any person or process altering or deleting system data or election data.

Third, the system shall be configured to execute only intended and necessary processes during the execution of election software. The system shall also be configured to halt election software processes upon the termination of any critical system process (such as system audit) during the execution of election software.

2.2.6 Election Management System

The Election Management System (EMS) is used to prepare ballots and programs for use in casting and counting votes, and to consolidate, report, and display election results. An EMS shall generate and maintain a database, or one or more interactive databases, that enables election officials or their designees to perform the following functions:

a. Define political subdivision boundaries and multiple election districts as indicated in the system documentation;

b. Identify contests, candidates, and issues

c. Define ballot formats and appropriate voting options;

d. Generate ballots and election-specific programs for vote recording and vote counting equipment;

e. Install ballots and election-specific programs;

f. Test that ballots and programs have been properly prepared and installed;

g. Accumulate vote totals at multiple reporting levels as indicated in the system documentation;

h. Generate the post-voting reports required by Section 2.5; and

i. Process and produce audit reports of the data indicated in Section 4.5.

2.2.7 Human Factors

The importance of human factors in the design of voting systems has become increasingly apparent. It is not sufficient that the internal operation of these systems be correct; in addition, voters and poll workers must be able to use them effectively. There are some special difficulties in the design of usable and accessible voting systems:

  • The voting task itself can be fairly complex; the voter may have to navigate an electronic ballot, choose multiple candidates in a single race or decide on abstrusely worded referenda.
  • Voting is performed infrequently, so learning and familiarity are lower than for more frequent tasks, such as use of an ATM.
  • Jurisdictions may change voting equipment, thus obviating whatever familiarity the voter might have acquired.
  • Once the voting session has been completed by the voter, there is never a chance for later correction.
  • Voting must be accessible to all eligible citizens, whatever their age, physical abilities, language skills, or experience with technology.

The challenge, then, is to provide a voting system and voting environment that all voters can use comfortably, efficiently, and with justified Start Printed Page 18943confidence that they have cast their votes correctly. The requirements within this section are intended to serve that goal.

Although there are many detailed requirements, three broad principles motivate this section on human factors:

1. All Eligible and Potentially Eligible Voters Shall Have Access to the Voting Process Without Discrimination.

The voting process shall allow eligible voters of whatever age, condition, or background to be able to go through the entire voting process with the same degree of independence, privacy, and confidence, insofar as technology will allow. Note that the voting process includes access to the polling place, instructions on how to vote, initiating the voting session, choosing candidates, getting help as needed, review of the ballot, VVPAT, if applicable, and final submission of the ballot.

2. Each Cast Ballot Shall Capture the Intent of the Voter Who Cast That Ballot.

Voters have the right to have the ballot presented to them in a manner that is clear and usable. Voters should encounter no difficulty or confusion in recording their choices.

3. The Voting Process Shall Preserve the Secrecy of the Ballot.

The voting process shall preclude anyone else from determining the content of a voter's ballot, with or without the voter's cooperation. If such a determination is made against the wishes of the voter, then his or her privacy has been violated. The process must also preclude the voter from disclosing the content of the ballot to anyone else.

All the requirements within Section 2.2.7 have the purpose of improving the quality of interaction between voters and voting systems.

  • Requirements that are likely to be relevant only to those with some disability are listed under Section 2.2.7.1, although they may also assist those not usually described as having a disability, e.g. voters with poor eyesight or somewhat limited dexterity.
  • Requirements that are likely to be relevant only to those with limited English proficiency are listed in Section 2.2.7.2.
  • Finally, requirements for general usability make up Section 2.2.7.3 and those for privacy, Section 2.2.7.4.

Certain abbreviations and terms are used extensively throughout Section 2.2.7:

  • CIF: Common Industry Format: Refers to the format described in ANSI/INCITS 354-2001 “Common Industry Format (CIF) for Usability Test Reports.”
  • Acc-VS: Accessible Voting Station—the voting station equipped for individuals with disabilities referred to in HAVA 301(a)(3)(B).
  • ATI: Audio-Tactile Interface—a voter interface designed so as not to require visual reading of a ballot. Audio is used to convey information to the voter and sensitive tactile controls allow the voter to convey information to the voting system.
  • ALVS: Alternative Language Voting Station—a voting station designed to be usable by voters who have limited English proficiency.

This section also uses common terms as defined in the updated Glossary. Note in particular, the distinctions among “voting system,” “voting station,” and “voting process.”

1. The Voting Process Shall Be Accessible to Voters With Disabilities. As a Minimum, Every Polling Place Shall Have at Least One Voting Station Equipped for Individuals With Disabilities, as Provided in HAVA 301 (a)(3)(B). A Station So Equipped Is Referred to Herein as an Accessible Voting Station (Acc-VS)

HAVA Section 301(a)(3) reads in part:

ACCESSIBILITY FOR INDIVIDUALS WITH DISABILITIES.—The voting system shall—

(A) be accessible for individuals with disabilities, including nonvisual accessibility for the blind and visually impaired, in a manner that provides the same opportunity for access and participation (including privacy and independence) as for other voters;

(B) satisfy the requirement of subparagraph (A) through the use of at least one direct recording electronic voting system or other voting system equipped for individuals with disabilities at each polling place;

The requirements within Section 2.2.7.1 are intended to address this mandate. Ideally every voter would be able to vote independently and privately. As a practical matter, there may be a small number of voters whose disabilities are so severe that they will need personal assistance. Nonetheless, the requirements of this section are meant to make the voting system directly accessible to as many voters as possible.

Note that this section does not replace requirements of other sections, but adds to them. In particular, the requirements of Section 2.2.7.3 on usability apply either to all voting stations or, in some cases, to all DRE voting stations; many of these requirements support accessibility as well as general usability.

Certain accessibility features that are likely to be useful to a wide range of voters are required on all voting stations, not just the Acc-VS. Finally, note that the Acc-VS is not necessarily a full-fledged DRE; for instance, an implementation may provide an ATI that generates an optiscan ballot.

The outline for Section 2.2.7.1 is:

2.2.7.1 Accessibility

2.2.7.1.1 Voters with Disabilities—General

2.2.7.1.2 Vision

2.2.7.1.2.1 Partial Vision

2.2.7.1.2.2 Blind

2.2.7.1.3 Dexterity

2.2.7.1.4 Mobility

2.2.7.1.5 Hearing

2.2.7.1.6 Speech

2.2.7.1.7 Cognitive

1. The Voting Process Shall Incorporate Features That Are Applicable to Several Types of Disability

Discussion: These features span the disability categories within requirement #2.2.7.1 (e.g. vision, dexterity).

1.1 When the Provision of Accessibility Involves an Alternative Format for Ballot Presentation, Then All the Other Information Presented to Voters in the Case of Non-Disabled English-Literate Voters (Including Instructions, Warnings, Messages, and Ballot Choices) Shall Also Be Presented in That Alternative Format

Discussion: This is a general principle to be followed for any alternative format presentation. Two particular cases, (a) audio formats and (b) non-English formats, are the subject of specific requirements in later sections.

[Best Practice for Voting Officials] When the provision of accessibility involves an alternative format for ballot presentation, then all the other information presented to voters in the case of non-disabled English-literate voters (including instructions, warnings, messages, and ballot choices) is also presented in that alternative format.

1.2 An Acc-VS Shall Provide Direct Accessibility Such That Voters' Personal Assistive Devices Are Not Required for Voting

Discussion: Voters are not to be obliged to supply any special equipment in order to vote. This requirement does not preclude the Acc-VS from providing interfaces to assistive technology. Start Printed Page 18944

1.3 When the Primary Means of Voter Identification or Authentication Uses Biometric Measures That Require a Voter To Possess Particular Biological Characteristics, the Voting Process Shall Provide a Secondary Means That Does Not Depend on Those Characteristics

Discussion: For example, if fingerprints were used for identification, there would have to be another mechanism for voters without usable fingerprints.

[Best Practice for Voting Officials] When the primary means of voter identification or authentication uses biometric measures that require a voter to possess particular biological characteristics, the voting process provides a secondary means that does not depend on those characteristics.

[Best Practice for Voting Officials] Polling places are subject to the appropriate guidelines of the Americans with Disabilities Act (ADA) of 1990 and of the Architectural Barriers Act (ABA) of 1968. This requirement does not stem from HAVA, but rather is a reminder of other legal obligations. For more details, see http://www.access-board.gov/​ada-aba.htm and http://www.usdoj.gov/​crt/​ada/​votingck.htm.

2. The Voting Process Shall Be Accessible to Voters With Visual Disabilities

Discussion: Note that all aspects of the voting process are to be accessible, not just the voting station.

2.1 The Acc-VS Shall Be Accessible to Voters With Partial Vision

2.1.1 The Vendor Should Conduct Summative Usability Tests on the Acc-VS Using Partially Sighted Subjects and Report the Test Results to the Appropriate Testing Authority According to the Common Industry Format (CIF)

Discussion: This requirement is meant to encourage Acc-VS designers to conduct some realistic usability tests on the final product. For now, it is purely a documentation recommendation. Future versions of the VVSG will include requirements for usability testing to be conducted by the testing authority, with specific performance benchmarks.

2.1.2 The Acc-VS and Any Voting Station With an Electronic Image Display Shall Be Capable of Showing All Information in at Least Two Font Sizes, (a) 3.0-4.0 mm and (b) 6.3-9.0 mm, Under Control of the Voter or Poll Worker

Discussion: While larger font sizes may assist most voters with poor vision, certain disabilities such as tunnel vision are best addressed by smaller font sizes. It is anticipated that future versions of the VVSG will require font size to be under the independent control of the voter.

2.1.3 All Voting Stations Using Paper Ballots Should Make Provisions for Voters With Poor Reading Vision

Discussion: Possible solutions include: (a) providing paper ballots in at least two font sizes, 3.0-4.0 mm and 6.3-9.0 mm and (b) providing a magnifying device.

2.1.4 An Acc-VS and Any Voting Station With a Black-and-White-Only Electronic Image Display Shall Be Capable of Showing All Information in High Contrast Either by Default or Under the Control of the Voter or Poll Worker. High Contrast Is a Figure-to-Ground Ambient Contrast Ratio for Text and Informational Graphics of at Least 6:1

Discussion: It is anticipated that future versions of the VVSG will require contrast to be under the independent control of the voter.

2.1.5 An Acc-Vs With a Color Electronic Image Display Shall Allow the Voter or Poll Worker To Adjust the Color or the Figure-to-Ground Ambient Contrast Ratio

Discussion: See NASED Technical Guide #1 for examples of how a voting station may meet this requirement by offering a limited number of discrete choices. In particular, it is not required that the station offer a continuous range of color or contrast values.

2.1.6 On All Voting Stations, the Default Color Coding Shall Maximize Correct Perception by Voters and Operators With Color Blindness

[Best Practice for Voting Officials] On all voting stations, the default color coding maximizes correct perception by voters and operators with color blindness.

2.1.7 On All Voting Stations, Color Coding Shall Not Be Used as the Sole Means of Conveying Information, Indicating an Action, Prompting a Response, or Distinguishing a Visual Element

Discussion: This implies that although color can be used for emphasis, some other non-color mode must also be used to convey the information, such as a shape or text style. For example, red can be enclosed in an octagon shape.

2.1.8 Buttons and Controls on All Voting Stations Should Be Distinguishable by Both Shape and Color

Discussion: The redundant cues have been found to be helpful to those with partial vision.

2.1.9 Any Voting Station Using an Electronic Image Display Should Also Provide Synchronized Audio Output To Convey the Same Information as That on the Screen

Discussion: Synchronized presentation of information in both visual and aural modes is a recommendation in this version of the VVSG, but it is anticipated that this will become a requirement in future versions. Start Printed Page 18945

2.2 The Acc-VS Shall Be Accessible to Voters Who Are Blind

Discussion: Of course, many of the features under this requirement are also useful for voters with partial vision (see requirement # 2.2.7.1.2.1) and for voters who cannot read English for other reasons (see requirement # 2.2.7.2).

2.2.1 The Vendor Should Conduct Summative Usability Tests on the Acc-Vs Using Subjects Who Are Blind and Report the Test Results to the Appropriate Testing Authority According to the Common Industry Format (CIF)

Discussion: This requirement is meant to encourage Acc-VS designers to conduct some realistic usability tests on the final product. For now, it is purely a documentation recommendation. Future versions of the VVSG will include requirements for usability testing to be conducted by the testing authority, with specific performance benchmarks.

2.2.2 The Acc-VS Shall Provide an Audio-Tactile Interface (ATI) That Supports the Full Functionality of a Normal Ballot Interface, as Specified in Section 2.4

Discussion: Note the necessity of both audio output and tactilely discernible controls for voter input. Full functionality includes at least:

  • Instructions and feedback on initial activation of the ballot (such as insertion of a smart card), if this is normally performed by the voter on comparable voting stations,
  • Instructions and feedback to the voter on how to operate the Acc-VS, including settings and options (e.g. volume control, repetition),
  • Instructions and feedback for navigation of the ballot,
  • Instructions and feedback for voter selections in races and referenda, including write-in candidates,
  • Instructions and feedback on confirming and changing selections, and
  • Instructions and feedback on final submission of ballot.

2.2.2.1 The ATI of the Acc-VS Shall Provide the Same Capabilities To Vote and Cast a Ballot as Are Provided by the Other Voting Stations or by the Visual Interface of the Acc-VS. Therefore, Functional Features That Exceed the Requirements of Section 2.4 Must Be Provided on a Non-Discriminatory Basis

Discussion: For example, if a “normal” ballot supports voting a straight party ticket and then changing the choice in a single race, so must the ATI. This requirement is a special case of the more general requirement # 2.2.7.1.1.1.

2.2.2.2 The ATI Shall Allow the Voter To Have Any Information Provided by the System Repeated

2.2.2.3 The ATI Shall Allow the Voter To Pause and Resume the Audio Presentation

2.2.2.4 The ATI Shall Allow the Voter To Skip to the Next Contest or Return to Previous Contests

Discussion: This is analogous to the ability of sighted voters to move on to the next race once they have made a selection or to abstain from voting on a contest.

2.2.2.5 The ATI Should Allow the Voter To Skip Over the Reading of a Referendum so as To Be Able To Vote on It Immediately

Discussion: This is analogous to the ability of sighted voters to skip over the wording of a referendum on which they have already made a decision prior to the voting session (e.g. “Vote yes on proposition #123”). It is anticipated that this recommendation will become a requirement in future versions of the VVSG.

2.2.3 All Voting Stations That Provide Audio Presentation of the Ballot Shall Conform to the Following Sub-Requirements

Discussion: These requirements apply to all audio output, not just to the ATI of an Acc-VS.

2.2.3.1 The Ati Shall Provide Its Audio Signal Through an Industry Standard Connector for Private Listening Using a 3.5Mm Stereo Headphone Jack To Allow Voters To Use Their Own Audio Assistive Devices

2.2.3.2 When a Voting Station Utilizes a Telephone Style Handset/Headset To Provide Audio Information, It Shall Provide a Wireless T-Coil Coupling for Assistive Hearing Devices so as To Provide Access to That Information for Voters With Partial Hearing. That Coupling Shall Achieve at Least a Category T4 Rating as Defined by American National Standard for Methods of Measurement of Compatibility Between Wireless Communications Devices and Hearing Aids, ANSI C63.19

2.2.3.3 No Voting Station Shall Cause Electromagnetic Interference With Assistive Hearing Devices That Would Substantially Degrade the Performance of Those Devices. The Station, Considered as a Wireless Device (WD) Shall Achieve at Least a Category T4 Rating as Defined by American National Standard for Methods of Measurement of Compatibility Between Wireless Communications Devices and Hearing Aids, ANSI C63.19

Discussion: “Hearing devices” includes hearing aids and cochlear implants. Start Printed Page 18946

2.2.3.4 A Sanitized Headphone or Handset Should Be Made Available to Each Voter

Discussion: This requirement can be achieved in various ways, including the use of “throwaway” headphones, or of sanitary coverings.

[Best Practice for Voting Officials] A sanitized headphone or handset is made available to each voter.

2.2.3.5 The Voting Station Shall Set the Initial Volume for Each Voter Between 40 and 50 dB SPL

Discussion: A voter does not “inherit” the volume as set by the previous user of the voting station.

2.2.3.6 The Voting Station Shall Provide a Volume Control With an Adjustable Amplification From a Minimum of 20dB SPL Up to a Maximum of 105 dB SPL, in Increments No Greater Than 20dB

2.2.3.7 The Audio System Shall Be Able To Reproduce Frequencies Over the Audible Speech Range Of 315 Hz To 10KHz

2.2.3.8 The Audio System Should Provide Information Via Recorded Human Speech, Rather Than Synthesized Speech

Discussion: Most users prefer real speech over synthesized speech.

2.2.3.9 The Audio System Should Allow Voters To Control, Within Reasonable Limits, the Rate of Speech

Discussion: Many blind voters are accustomed to interacting with accelerated speech.

2.2.4 If the Normal Procedure Is To Have Voters Initialize the Activation of the Ballot, the Acc-Vs Shall Provide Features That Enable Voters Who Are Blind To Perform This Activation

Discussion: For example, smart cards might provide tactile cues so as to allow correct insertion.

2.2.5 If the Normal Procedure Is for Voters To Submit Their Own Ballots, Then the Voting Process Should Provide Features That Enable Voters Who Are Blind To Perform This Submission

Discussion: For example, if voters normally feed their own optiscan ballots into a reader, blind voters should also be able to do so.

[Best Practice for Voting Officials] If the normal procedure is for voters to submit their own ballots, then the voting process provides features that enable voters who are blind to perform this submission.

2.2.6 If the Normal Procedure Includes VVPAT, the Acc-VS Should Provide Features That Enable Voters Who Are Blind To Perform This Verification

Discussion: For example, the Acc-VS might provide an automated reader for the paper record that converts the contents of the paper into audio output. It is anticipated that this recommendation will become a requirement in future versions of the VVSG.

2.2.7 All Mechanically Operated Controls or Keys on an Acc-VS Shall Be Tactilely Discernible Without Activating Those Controls or Keys

2.2.8 On an Acc-VS, the Status of All Locking or Toggle Controls or Keys (Such as the “Shift” Key) Shall Be Visually Discernible, and Discernible Either Through Touch or Sound

3. The Voting Process Shall Be Accessible to Voters Who Lack Fine Motor Control or the Use of Their Hands

3.1 The Vendor Should Conduct Summative Usability Tests on the Acc-VS With Subjects Lacking Fine Motor Control and Report the Test Results to the Appropriate Testing Authority According to the Common Industry Format (CIF)

Discussion: This requirement is meant to encourage Acc-VS designers to conduct some realistic usability tests on the final product. For now, it is purely a documentation recommendation. Future versions of the VVSG will include requirements for usability testing to be conducted by the testing authority with specific performance benchmarks.

3.2 All Keys and Controls on the Acc-VS Shall Be Operable With One Hand and Shall Not Require Tight Grasping, Pinching, or Twisting of the Wrist. The Force Required To Activate Controls and Keys Shall Be No Greater 5 lbs. (22.2 N)

Discussion: Controls are to be operable without excessive force.

3.3 The Acc-VS Controls Shall Not Require Direct Bodily Contact or for the Body To Be Part of Any Electrical Circuit

Discussion: This requirement ensures that controls are operable by individuals using prosthetic devices. Start Printed Page 18947

3.4 The Acc-VS Should Provide a Mechanism To Enable Non-Manual Input That Is Functionally Equivalent to Tactile Input

Discussion: This recommendation ensures that the Acc-VS is operable by individuals who do not have the use of their hands. All the functionality of the Acc-VS (e.g. straight party voting, write-in candidates) that is available through the other forms of input, such as tactile, must also be available through the input mechanism if it is provided by the Acc-VS.

4. The Voting Process Shall Be Accessible to Voters Who Use Mobility Aids, Including Wheelchairs

4.1 The Acc-VS Shall Provide a Clear Floor Space of 30 Inches (760 mm) Minimum by 48 Inches (1220 mm) Minimum for a Stationary Mobility Aid. The Clear Floor Space Shall Be Level With No Slope Exceeding 1:48 and Positioned for a Forward Approach or a Parallel Approach

[Best Practice for Voting Officials] The Acc-VS provides a clear floor space of 30 inches (760 mm) minimum by 48 inches (1220 mm) minimum for a stationary mobility aid. The clear floor space is level with no slope exceeding 1:48 and positioned for a forward approach or a parallel approach.

4.2 All Controls, Keys, Audio Jacks and Any Other Part of the Acc-VS Necessary for the Voter To Operate the Voting System Shall Be Within Reach as Specified Under the Following Sub-Requirements

Discussion: All dimensions are given in inches. To convert to millimeters, multiply by 25.4 and then round to the nearest multiple of 5. Note that these sub-requirements have meaningful application mainly to controls in a fixed location. A hand-held tethered control panel is another acceptable way of providing reachable controls. All the sub-requirements inherit the “responsible entity” and “process” properties.

[Best Practice for Voting Officials] All controls, keys, audio jacks and any other part of the Acc-VS necessary for the voter to operate the voting system are within the reach regions as specified in the VVSG Volume I, Section 2.2.7.1.4.3.

4.2.1 If the Acc-VS Has a Forward Approach With No Forward Reach Obstruction Then the High Reach Shall Be 48 Inches Maximum and the Low Reach Shall Be 15 Inches Minimum. See Figure 2.2.7.1-1

4.2.2 If the Acc-VS Has a Forward Approach With a Forward Reach Obstruction, the Following Sub-Requirements Apply. See Figure 2.2.7.1-2

4.2.2.1 The Forward Obstruction Shall Be No Greater Than 25 Inches in Depth, Its Top No Higher Than 34 Inches and Its Bottom Surface No Lower Than 27 Inches

4.2.2.2 If the Obstruction Is No More Than 20 Inches in Depth, Then the Maximum High Reach Shall Be 48 Inches, Otherwise It Shall Be 44 Inches

4.2.2.3 Space Under the Obstruction Between the Finish Floor or Ground and 9 Inches (230 mm) Above the Finish Floor or Ground Shall Be Considered Toe Clearance and Shall Comply With the Following Sub-Requirements

A. Toe clearance shall extend 25 inches (635 mm) maximum under the obstruction.

B. The minimum toe clearance under the obstruction shall be either 17 inches (430 mm) or the depth required to reach over the obstruction to operate the Acc-VS, whichever is greater.

C. Toe clearance shall be 30 inches (760 mm) wide minimum.

Voting System Vendor

4.2.2.4 Space Under the Obstruction Between 9 inches (230 mm) and 27 Inches (685 mm) Above the Finish Floor or Ground Shall Be Considered Knee Clearance and Shall Comply With the Following Sub-Requirements

A. Knee clearance shall extend 25 inches (635 mm) maximum under the obstruction at 9 inches (230 mm) above the finish floor or ground.

B. The minimum knee clearance at 9 inches (230 mm) above the finish floor or ground shall be either 11 inches (280 mm) or 6 inches less than the toe clearance, whichever is greater.

C. Between 9 inches (230 mm) and 27 inches (685 mm) above the finish floor or ground, the knee clearance shall be permitted to reduce at a rate of 1 inch (25 mm) in depth for each 6 inches (150 mm) in height.

Discussion: It follows that the minimum knee clearance at 27 inches above the finish floor or ground shall be 3 inches less than the minimum knee clearance at 9 inches above the floor.

D. Knee clearance shall be 30 inches (760 mm) wide minimum.

Start Printed Page 18948

4.2.3 If the Acc-VS Has a Parallel Approach With No Side Reach Obstruction Then the Maximum High Reach Shall be 48 Inches and the Minimum Low Reach Shall be 15 Inches. See Figure 2.2.7.1-3

4.2.4 If the Acc-VS Has a Parallel Approach With a Side Reach Obstruction, the Following Sub-Requirements Apply. See Figure 2.2.7.1-4

4.2.4.1 The Side Obstruction Shall Be No Greater Than 24 Inches in Depth and Its Top No Higher Than 34 Inches

4.2.4.2 If the Obstruction Is No More Than 10 inches in Depth, Then the Maximum High Reach Shall Be 48 Inches, Otherwise It Shall Be 46 Inches

Discussion: Since this is a parallel approach, no clearance under the obstruction is required.

4.2.5 All Labels, Displays, Controls, Keys, Audio Jacks, and Any Other Part of the Acc-VS Necessary for the Voter To Operate the Voting System Shall Be Easily Legible and Visible to a Voter in a Wheelchair With Normal Eyesight (No Worse Than 20/40, Corrected) Who Is in an Appropriate Position and Orientation with Respect to the Acc-VS

Discussion: There are a number of factors that could make relevant parts of the Acc-VS difficult to see: small lettering, controls and labels tilted at an awkward angle from the voter's viewpoint, glare from overhead lighting, etc.

5. The Voting Process Shall Be Accessible to Voters With Hearing Disabilities

5.1 The Acc-VS Shall Incorporate the Features Listed Under Requirement # 2.2.7.1.2.2.3 (Audio Presentation) To Provide Accessibility to Voters With Hearing Disabilities

Discussion: Note especially the requirements for volume initialization and control.

[Best Practice for Voting Officials] The Acc-VS incorporates the features listed in the VVSG Volume I, Section 2.2.7.1.2.2.3 (audio presentation) to provide accessibility to voters with hearing disabilities.

5.2 If a Voting Station Provides Sound Cues as a Method To Alert the Voter, the Tone Shall Be Accompanied by a Visual Cue

Discussion: For instance, the station might beep if the voter attempts to overvote. If so, there would have to be an equivalent visual cue, such as the appearance of an icon, or a blinking element.

6. The Voting Process Shall Be Accessible to Voters With Speech Disabilities

6.1 No Voting Station Shall Require Voter Speech for its Operation

Discussion: This does not preclude a voting station from offering speech input as an option, but speech must not be the only means of input.

7. The Voting Process Should Be Accessible to Voters With Cognitive Disabilities

Discussion: At present there are no design features specifically aimed at helping those with cognitive disabilities. Section 2.2.7.1.2.1.9, the synchronization of audio with the screen in a DRE, is helpful for some cognitive disabilities such as dyslexia. Section 2.2.7.3.3 also contains some relevant guidelines.

[Best Practice for Voting Officials] The voting process is made accessible to voters with cognitive disabilities.

Start Printed Page 18949

2. The Voting Process Shall Be Accessible to Voters Who Are Not Fully Literate in English. This Requirement May Be Satisfied by Providing Voting Stations in a Polling Place That Accommodate Those Without a Full Command of English. See HAVA 301 (a)(4) and 241 (b)(5). Such a Facility is Referred to Herein as an Alternative Language Voting Station (ALVS)

HAVA Section 301 (a)(4) reads:

ALTERNATIVE LANGUAGE ACCESSIBILITY.—The voting system shall provide alternative language accessibility pursuant to the requirements of section 203 of the Voting Rights Act of 1965 (42 U.S.C. 1973aa-1a).

The requirements within Section 2.2.7.2 are intended to address this mandate. Ideally every voter would be able to vote independently and privately, regardless of language. As a practical matter, alternative language access is mandated under the Voting Rights Act of 1975, subject to certain thresholds, e.g. if the language group exceeds 5% of the voting age citizens.

Note that the provision of an audio interface for people with visual disabilities as described in Section 2.2.7.1 may also assist voters who speak English, but are unable to read it.

The outline for section 2.2.7.2 is:

2.2.7.2. Alternative Languages

2.2.7.2.1 Complete Information Start Printed Page 18950

2.2.7.2.2 Spelling of Names

2.2.7.2.3 Literate Voters

2.2.7.2.4 Illiterate Voters

1. All the Information Presented in the Normal Case of English-literate Voters (Including Instructions, Warnings, Messages, and Ballot Choices) Shall Also Be Presented by the ALVS, Whether the Language Is Written or Spoken

Discussion: This is in keeping with general requirement # 2.2.7.1.1.1.

2. Regardless of the Language, Candidate Names Shall Be Displayed or Pronounced in English on All Ballots. For Written Languages That Do Not Use Roman Characters (e.g. Chinese, Japanese, Korean, Arabic), the Ballot Shall Include Transliteration of Candidate Names Into the Relevant Language

[Best Practice for Voting Officials] Regardless of the language, candidate names are displayed or pronounced in English on all ballots. For written languages that do not use Roman characters (e.g., Chinese, Japanese, Korean, Arabic), the ballot includes transliteration of candidate names into the relevant language.

3. For Literate Voters, the ALVS Shall Provide Printed or Displayed Instructions, Messages, and Ballots in Their Preferred Language, Consistent With State and Federal Law

3.1 The Vendor Should Conduct Summative Usability Tests on the ALVS With Literate Subjects Who Neither Speak Nor Read English and Report the Test Results According to the Common Industry Format (CIF)

Discussion: This requirement is meant to encourage Acc-VS designers to conduct some realistic usability tests on the final product. For now, it is purely a documentation recommendation. Future versions of the VVSG will include requirements for usability testing to be conducted by the testing authority, with specific performance benchmarks.

4. For Illiterate Voters, the ALVS Shall Provide Spoken Instructions and Ballots in the Preferred Language of the Voter, Consistent With State and Federal Law. The Requirements and Sub-Requirements of # 2.2.7.1.2.2.2 (Acc-VS/ATI) Shall Apply to This Mode of Interaction

Discussion: Note that some languages have no widely accepted written form.

3. The Voting Process Shall Provide a High Level of Usability to the Voters. Accordingly, Voters Shall Be Able to Negotiate the Process Effectively, Efficiently, and Comfortably

Discussion: The first Voting System Standards codified in HAVA relate to the interaction between the voter and the voting system. HAVA Section 301 begins:

SEC. 301. VOTING SYSTEMS STANDARDS.

a. Requirements.—Each voting system used in an election for Federal office shall meet the following requirements:

1. In general.—

A. Except as provided in subparagraph (B), the voting system (including any lever voting system, optical scanning voting system, or direct recording electronic system) shall—

i. Permit the voter to verify (in a private and independent manner) the votes selected by the voter on the ballot before the ballot is cast and counted;

ii. Provide the voter with the opportunity (in a private and independent manner) to change the ballot or correct any error before the ballot is cast and counted (including the opportunity to correct the error through the issuance of a replacement ballot if the voter was otherwise unable to change the ballot or correct any error); and

iii. If the voter selects votes for more than one candidate for a single office—

I. Notify the voter that the voter has selected more than one candidate for a single office on the ballot;

II. Notify the voter before the ballot is cast and counted of the effect of casting multiple votes for the office; and

III. Provide the voter with the opportunity to correct the ballot before the ballot is cast and counted.

B. A State or jurisdiction that uses a paper ballot voting system, a punch card voting system, or a central count voting system (including mail-in absentee ballots and mail-in ballots), may meet the requirements of subparagraph (A)(iii) by—

i. Establishing a voter education program specific to that voting system that notifies each voter of the effect of casting multiple votes for an office; and

ii. Providing the voter with instructions on how to correct the ballot before it is cast and counted (including instructions on how to correct the error through the issuance of a replacement ballot if the voter was otherwise unable to change the ballot or correct any error).

C. The voting system shall ensure that any notification required under this paragraph preserves the privacy of the voter and the confidentiality of the ballot.”

The requirements of this section supplement these basic HAVA mandates and also HAVA's support for improved usability (see Section 243 and Section 221(e)(2)(D)).

Voting and Usability

Usability is defined generally as a measure of the effectiveness, efficiency, and satisfaction achieved by a specified set of users with a given product in the performance of specified tasks. In the context of voting, the primary users are the voters (but also poll workers), the product is the voting system, and the task is the correct representation of one's choices in the election. Additional requirements for task performance are independence and privacy: the voter should normally be able to complete the voting task without assistance from others (although the voting system itself may offer help), and the voter's choices should be private (see Section 2.2.7.4). Aside from its intrinsic undesirability, lack of independence or privacy may adversely affect effectiveness (e.g. by possibly inhibiting the voter's free choice) and efficiency (e.g. by slowing down the process).

Among the “bottom-line” metrics for usability are:

  • low error rate for marking the ballot (the voter's intention is correctly conveyed to and represented within the voting system),
  • efficient operation (time required to vote is not excessive), and
  • satisfaction (voter experience is safe, comfortable, free of stress, and instills confidence).

These criteria define the core of good voting system usability. The purpose of the detailed requirements listed below is to help voting systems meet the core criteria. Start Printed Page 18951

Methodology for Requirements

It is the intention of the TGDC that in forthcoming versions of the VVSG, usability will be addressed by high-level performance-based requirements. That is, the requirements will directly address metrics for effectiveness (e.g. correct capture of voters' intentions), efficiency (e.g. time taken to vote), and satisfaction. Until the supporting research is completed, however, the contents of this subsection are limited to a somewhat basic set of widely accepted design requirements and lower-level performance requirements. The reasons for this approach are:

  • These are to serve as interim requirements, pending the issuance of high-level performance requirements.
  • The actual benefit of numerous detailed design guidelines is difficult to prove or measure.
  • The technical complexity and costs of a large set of detailed requirements may not be justified.
  • Guidelines that are difficult to test because of insufficient specificity have been omitted.

This is not to say that an extensive set of design guidelines is without value. But we wish to distinguish between good advice to be considered by developers and strict requirements that will be enforced by a regime of formal testing. For more detail on the issue of design vs. performance standards, see Sections 2.3 and 6.1 et al. of NIST Special Publication 500-256: Improving the Usability and Accessibility of Voting Systems and Products (http://vote.nist.gov/​ Final%20Human% 20Factors%20 Report%20% 205-04.pdf).

General Issues for the Usability Requirements

As mentioned in Section 2.2.7.1, many of the guidelines in this section enhance accessibility as well as general usability.

The scope of usability includes the entire voting process, although the emphasis herein is on the interface between the voter and the voting station.

The requirements in this sub-section generally assume a visual-tactile interface, but also see requirements in Sections 2.2.7.1 and Section 2.2.7.2 for alternative formats, including audio.

The outline for Section 2.2.7.3 is:

2.2.7.3 Usability

2.2.7.3.1 Usability Testing by Vendor

2.2.7.3.2 Functional Capabilities

2.2.7.3.3 Cognitive Issues

2.2.7.3.4 Perceptual Issues

2.2.7.3.5 Interaction Issues

1. The Vendor Should Conduct Summative Usability Tests on the Voting System Using Subjects Representative of the General Population and Report the Test Results to the Appropriate Testing Authority According to the Common Industry Format (CIF)

Discussion: This requirement is meant to encourage Acc-VS designers to conduct some realistic usability tests on the final product. For now, it is purely a documentation recommendation. Future versions of the VVSG will include requirements for usability testing to be conducted by the testing authority, with specific performance benchmarks.

2. The Voting Process Shall Provide Certain Functional Capabilities To Support Voter Usability

2.1 As Mandated by HAVA 301(a)(1)(A), the Voting System Shall Support a Process That Allows the Voter To Review His or Her Completed Ballot Before Final Submission in Order To Verify That it Correctly Represents the Intended Vote and To Correct the Ballot if Mistakes Are Detected

Discussion: Note that this review and correction may be achieved by procedural means (e.g. in the case of paper ballots), as well as technical (see HAVA 301(a)(1)(B)). This requirement is a brief paraphrase of the HAVA language but of course the statutory language is determinative.

2.2 As Mandated by HAVA 301(a)(1)(A), the Voting System Shall Support a Process That Notifies the Voter if He or She Has Attempted To Vote for More Candidates Than the Maximum Permitted in a Given Race and That Provides the Voter With the Opportunity To Correct the Ballot Before Final Submission

Discussion: Note that this notification and correction may be achieved by procedural means (e.g. in the case of paper ballots), as well as technical (see HAVA 301(a)(1)(B)). This requirement is a brief paraphrase of the HAVA language but of course the statutory language is determinative.

2.3 DRE Voting Stations Shall Allow the Voter To Change a Vote Within a Race Before Advancing to the Next Race

Discussion: The point here is that voters using a DRE should not have to wait for the final ballot review in order to change a vote.

2.4 The Voting System Shall Support a Process That Notifies the Voter if He or She Has Attempted To Vote for Fewer Candidates Than the Maximum Permitted in a Given Race and That Provides the Voter With the Opportunity To Change the Ballot Before Final Submission. The Process Shall Also Notify the Voter That Such an “Undervote” Is Permitted and Shall Accept a Ballot if the Voter so Chooses

Discussion: Note that this notification and correction may be achieved by procedural means (e.g. in the case of paper ballots), as well as technical (see HAVA 301(a)(1)(B)).

2.5 DRE Voting Stations Should Provide Navigation Controls That Allow the Voter To Advance to the Next Race or Go Back to the Previous Race Before Completing a Vote on the Race or Races Currently Being Presented (Whether Visually or Aurally)

Discussion: For example, the voter should not be forced to proceed sequentially through all the races and/or candidates before going back to check the status of a previous race. Start Printed Page 18952

3. The Voting Process Shall Be Designed To Minimize Cognitive Difficulties for the Voter

3.1 Consistent With Election Law, the Voting System Should Support a Process That Does Not Introduce Any Bias for or Against Any of the Choices To Be Made by the Voter. In Both Visual and Aural Formats, Candidates and Choices Shall Be Presented in an Equivalent Manner

Discussion: Certain differences in presentation are unavoidable, such as the order in which candidates are listed, and write-in candidates are inherently more difficult to vote for. But comparable characteristics such as font size or voice volume and speed must be the same for all choices.

3.2 The Voting System or Related Materials Shall Provide Clear Instructions and Assistance so as To Allow Voters To Successfully Execute and Cast Their Ballots Independently

Discussion: Voters should not routinely need to ask for human assistance.

3.2.1 Voting Stations or Related Materials Shall Provide a Means for the Voter To Get Help at Any Time During the Voting Session

Discussion: The voter should always be able to get help at the station if confused. DRE voting stations may provide this with a distinctive “help” button. Any type of voting station may provide written instructions that are available and separate from the ballot. Note special requirements for the Acc-VS in requirement # 2.2.7.1.2.2.2 (Acc-VS/ATI).

3.2.2 The Voting Station Shall Provide Instructions for All Its Valid Operations

Discussion: If an operation is available to the voter, it must be documented. Examples include how to change a vote, how to navigate among races, how to cast a party-line vote, and how to cast a write-in vote.

3.3 The Voting System Shall Provide the Capability To Design a Ballot for Maximum Clarity and Comprehension

3.3.1 The Voting Station Should Not Visually Present a Single Race Spread Over Two Pages or Two Columns

Discussion: Such a visual separation poses the risk that the voter will perceive the race as two races. Of course, if a race has a very large number of candidates, it may be infeasible to observe this guideline.

[Best Practice for Voting Officials] The voting station does not visually present a single race spread over two pages or two columns.

3.3.2  The Ballot Shall Clearly Indicate the Maximum Number of Candidates for Which One Can Vote Within a Single Race

[Best Practice for Voting Officials] The ballot clearly indicates the maximum number of candidates for which one can vote within a single race.

3.3.3 There Shall Be a Consistent Relationship Between the Name of a Candidate and the Mechanism Used to Vote for That Candidate

Discussion: For example, if the response field where voters indicate their selections is located to the left of a candidate's name, then each response field shall be located to the left of the associated candidate's names.

[Best Practice for Voting Officials] The ballot presents the relationship between the name of a candidate and the mechanism used to vote for that candidate in a consistent manner.

3.4 Warnings and Alerts Issued by the Voting Station Should Clearly State the Nature of the Problem and the Set of Responses Available to the Voter. The Warning Should Clearly State Whether the Voter Has Performed or Attempted an Invalid Operation or Whether the Voting Equipment Itself Has Failed in Some Way

Discussion: In case of an equipment failure, the only action available to the voter might be to get assistance from a poll worker.

3.5 The Use of Color by the Voting Station Should Agree With Common Conventions: (a) Green, Blue or White Is Used for General Information or as a Normal Status Indicator; (b) Amber or Yellow Is Used to Indicate Warnings or a Marginal Status; (c) Red Is Used to Indicate Error Conditions or a Problem Requiring Immediate Attention

4. The Voting Process Shall Be Designed to Minimize Perceptual Difficulties for the Voter

4.1 No Display Screen of a Voting Station Shall Flicker With a Frequency Between 2 Hz and 55 Hz

Discussion: Aside from usability concerns, this requirement protects voters with epilepsy.

4.2 Any Aspect of the Voting Station That is Adjustable by the Voter or Poll Worker, Including Font Size, Color, Contrast, and Audio Volume, Shall Automatically Reset to a Standard Default Value Upon Completion of That Voter's Session

Discussion: This implies that the voting station presents the same initial appearance to every voter (excluding, of course, substantive differences in the ballot content due to residence or party of the voter). Start Printed Page 18953

4.3 If Any Aspect of a Voting Station is Adjustable by the Voter, There Should Be a Mechanism to Reset All Such Aspects to Their Default Values

Discussion: The purpose is to allow a voter who has adjusted the station into an undesirable state to reset all the aspects so as to get a fresh start.

4.4 The Minimum Font Size for All Text Intended for the Voter During the Voting Session Shall Be 3.0mm (Measured as the Height of a Capital Letter)

4.5 All Text Intended for the Voter During the Voting Session Should Be Presented in a Sans Serif Font

Discussion: Experimentation has shown that users prefer such a font and the legibility of serif and sans serif fonts is equivalent.

4.6 The Minimum Figure-to-Ground Ambient Contrast Ratio for All Text and Informational Graphics (Including Icons) Intended for the Voter Shall Be 3:1

5. The Voting Process Shall Be Designed to Minimize Interaction Difficulties for the Voter

5.1 Voting Stations With Electronic Image Displays Shall Not Require Page Scrolling by the Voter

Discussion: This is not an intuitive operation for those unfamiliar with the use of computers. Even those experienced with computers often do not notice a scroll bar and miss information below the page. DREs may require voters to move to the next or previous “page.”

5.2 The Voting Station Shall Provide Unambiguous Feedback Regarding the Voter's Selection, Such as Displaying a Checkmark Beside the Selected Option or Conspicuously Changing Its Appearance

5.3 If the Voting Station Requires a Response by a Voter Within a Specific Period of Time, It Shall Issue an Alert at Least 20 Seconds Before This Time Period Has Expired and Provide a Means by Which the Voter May Receive Additional Time

5.4 Input Mechanisms Shall Be Designed so as to Minimize Accidental Activation (Also, See Requirement # 2.2.7.1.2.2.7 on Tactile Discernability)

5.4.1 On Touch Screens, the Sensitive Touch Areas Shall Have a Minimum Height of 0.5 Inches and Minimum Width of 0.7 Inches. The Vertical Distance Between the Centers of Adjacent Areas Shall Be at Least 0.6 Inches, and the Horizontal Distance at Least 0.8 Inches

5.4.2 No Key or Control on a Voting Station Shall Have a Repeat Feature Enabled

Discussion: This is to preclude accidental activation.

4. The Voting Process Shall Preclude Anyone Else From Determining the Content of a Voter's Ballot, With or Without the Voter's Cooperation

Discussion: Voter privacy is strongly supported by HAVA—see Sections 221(e)(2)(C) and 301(a)(1). In this subsection, we address only privacy concerns in relation to human factors issues, but not with respect to the processing of cast ballots.

Although elections in American history have sometimes been public (and certain “town-hall” questions are still voted openly), the use of the secret ballot for political office is now universal.

Privacy in this context, including the property of the voter being unable to disclose his or her vote, ensures that the voter can make choices based solely on his or her own preferences without intimidation or inhibition. Among other practices, this forbids the issuance of a receipt to the voter that would provide proof to another how he or she voted.

The outline for Section 2.2.7.4 is:

2.2.7.4 Privacy

2.2.7.4.1 Privacy at the polling place

2.2.7.4.2 No preservation of alternative formats

2.2.7.4.3 Absentee Balloting

1. The Voting Station and Polling Place Shall Be Configured so as to Prevent Others From Learning the Contents of a Voter's Ballot

1.1 The Ballot and Any Input Controls Shall Be Visible Only to the Voter During the Voting Session and Ballot Submission

[Best Practice for Voting Officials] The ballot and any input controls are visible only to the voter during the voting session and ballot submission. Poll workers need to take into account such factors as visual barriers, windows, permitted waiting areas for other voters, and procedures for ballot submission when not performed at the voting station, e.g. submission of optiscan ballots to a central reader.

1.2 The Audio Interface Shall Be Audible Only to the Voter

Discussion: Voters who are hard of hearing but need to use an audio interface may also need to increase the volume of the audio. Such situations require headphones with low sound leakage.

[Best Practice for Voting Officials] The audio interface is audible only to the voter. Start Printed Page 18954

1.3 As Mandated By HAVA 301(a)(1)(C), the Voting System Shall Notify the Voter of an Attempted Overvote in a Way That Preserves the Privacy of the Voter and the Confidentiality of the Ballot

Discussion: This requirement is a brief paraphrase of the HAVA language but of course the statutory language is determinative.

[Best Practice for Voting Officials] As mandated by HAVA 301(a)(1)(C), the voting system notifies the voter of an attempted overvote in a way that preserves the privacy of the voter and the confidentiality of the ballot.

2. Voter Anonymity Shall Be Maintained for Alternative Format Ballot Presentation

2.1 No Information Shall Be Kept Within a Non-Paper-Based Cast Vote Record That Identifies Any Accessibility Feature(s) Used by a Voter

Discussion: Large-print paper ballots unavoidably preserve such information.

2.1.1 No Information Shall Be Kept Within a Non-Paper-Based Cast Vote Record That Identifies Any Alternative Language Feature(s) Used by a Voter

Discussion: Non-English paper ballots unavoidably preserve such information.

[Best Practice for Voting Officials] Appropriate procedures are needed to ensure that absentee balloting enable the voter to preserve privacy. There is no practical means to prevent a voter from revealing an absentee paper ballot to others. But the procedures should ensure that if a voter chooses to maintain privacy, it is not violated at a later stage, in particular when the ballot is received by voting officials.

2.2.8 Vote Tabulating Program

Each voting system shall have a vote tabulation program that will meet specific functional requirements.

2.2.8.1 Functions

The vote tabulating program software resident in each voting device, vote count server, or other devices shall include all software modules required to:

a. Monitor system status and generate machine-level audit reports;

b. Accommodate device control functions performed by polling place officials and maintenance personnel;

c. Register and accumulate votes; and

d. Accommodate variations in ballot counting logic.

2.2.8.2 Voting Variations

There are significant variations among the election laws of the 50 states with respect to permissible ballot contents, voting options, and the associated ballot counting logic. The TDP accompanying the system shall specifically identify which of the following items can and cannot be supported by the system, as well as how the system can implement the items supported:

a. Closed primaries;

b. Open primaries;

c. Partisan offices;

d. Non-partisan offices;

e. Write-in voting;

f. Primary presidential delegation nominations;

g. Ballot rotation;

h. Straight party voting;

i. Cross-party endorsement;

j. Split precincts;

k. Vote for N of M;

l. Recall issues, with options;

m. Cumulative voting;

n. Ranked order voting; and

o. Provisional or challenged ballots.

2.2.9 Ballot Counter

For all voting systems, each device that tabulates ballots shall provide a counter that:

a. Can be set to zero before any ballots are submitted for tally;

b. Records the number of ballots cast during a particular test cycle or election;

c. Increases the count only by the input of a ballot;

d. Prevents or disables the resetting of the counter by any person other than authorized persons at authorized points; and

e. Is visible to designated election officials.

2.2.10 Telecommunications

For all voting systems that use telecommunications for the transmission of data during pre-voting, voting or post-voting activities, capabilities shall be provided that ensure data are transmitted with no alteration or unauthorized disclosure during transmission. Such transmissions shall not violate the privacy, secrecy, and integrity demands of the Standards. Section 5 of the Standards describes telecommunications standards that apply to, at a minimum, the following types of data transmissions:

  • Voter Authentication: Coded information that confirms the identity of a voter for security purposes for a system that transmit votes individually over a public network;
  • Ballot Definition: Information that describes to a voting machine the content and appearance of the ballots to be used in an election;
  • Vote Transmission to Central Site: For systems that transmit votes individually over a public network, the transmission of a single vote to the county (or contractor) for consolidation with other county vote data;
  • Vote Count: Information representing the tabulation of votes at any one of several levels: polling place, precinct, or central count; and
  • List of Voters: A listing of the individual voters who have cast ballots in a specific election.

2.2.9 Data Retention

United States Code Title 42, Sections 1974 through 1974e, states that election administrators shall preserve for 22 months “all records and paper that came into (their) possession relating to an application, registration, payment of poll tax, or other act requisite to voting.” This retention requirement applies to systems that will be used at anytime for voting of candidates for Federal offices (e.g., Member of Congress, United States Senator, and/or Presidential Elector). Therefore, all systems shall provide for maintaining the integrity of voting and audit data during an election and for a period of at least 22 months thereafter.

Because the purpose of this law is to assist the Federal government in discharging its law enforcement responsibilities in connection with civil rights and elections crimes, its scope must be interpreted in keeping with that objective. The appropriate state or local authority must preserve all records that may be relevant to the detection and prosecution of federal civil rights or election crimes for the 22-month federal retention period, if the records were generated in connection with an election that was held in whole or in part to select federal candidates. It is important to note that Section 1974 does not require that election officials generate any specific type or classification of election record. However, if a record is generated, Section 1974 comes into force and the appropriate authority must retain the records for 22 months.

For 22-month document retention, the general rule is that all printed copy Start Printed Page 18955records produced by the election database and ballot processing systems shall be so labeled and archived. Regardless of system type, all audit trail information spelled out in subsection 4.5 of the Standards shall be retained in its original format, whether that be real-time logs generated by the system, or manual logs maintained by election personnel. The election audit trail includes not only in-process logs of election-night (and subsequent processing of absentee or provisional ballots), but also time logs of baseline ballot definition formats, and system readiness and testing results.

In many voting systems, the source of election-specific data (and ballot formats) is a database or file. In precinct count systems, this data is used to program each machine, establish ballot layout, and generate tallying files. It is not necessary to retain this information on electronic media if there is an official, authenticatable printed copy of all final database information. However, it is recommended that the state or local jurisdiction also retain electronic records of the aggregate data for each device so that reconstruction of an election is possible without data re-entry. The same requirement and recommendation applies to vote results generated by each precinct device or system.

2.3 Pre-Voting Functions

This section defines capabilities required to support functions performed prior to the opening of polls. All voting systems shall provide capabilities to support:

  • Ballot preparation;
  • Election programming;
  • Ballot and program installation and control;
  • Readiness testing;
  • Verification at the polling place; and
  • Verification at the central counting place.

The standards also include requirements to ensure compatible interfaces with the ballot definition process and the reporting of election results.

2.3.1 Ballot Preparation

Ballot preparation is the process of using election databases to define the specific contests, questions, and related instructions to be contained in ballots and to produce all permissible ballot layouts. Ballot preparation requirements include:

  • General capabilities for ballot preparation;
  • Ballot formatting; and
  • Ballot production.

2.3.1.1 General Capabilities

All systems shall provide the general capabilities for ballot preparation.

2.3.1.1.1 Common Standards

All systems shall be capable of:

a. Enabling the automatic formatting of ballots in accordance with the requirements for offices, candidates, and measures qualified to be placed on the ballot for each political subdivision and election district;

b. Collecting and maintaining the following data:

(1) Offices and their associated labels and instructions;

(2) Candidate names and their associated labels; and

(3) Issues or measures and their associated text;

c. Supporting the maximum number of potentially active voting positions as indicated in the system documentation;

d. For a primary election, generating ballots that segregate the choices in partisan races by party affiliation;

e. Generating ballots that contain identifying codes or marks uniquely associated with each format; and

f. Ensuring that vote response fields, selection buttons, or switches properly align with the specific candidate names and/or issues printed on the ballot display, ballot card or sheet, or separate ballot pages.

2.3.1.1.2 Paper-Based System Standards

In addition to the common standards, paper-based systems shall meet the following standards applicable to the technology used:

a. Enable voters to make selections by punching a hole or by making a mark in areas designated for this purpose upon each ballot card or sheet;

b. For punchcard systems, ensure that the vote response fields can be properly aligned with punching devices used to record votes; and

c. For marksense systems, ensure that the timing marks align properly with the vote response fields.

2.3.1.2 Ballot Formatting

Ballot formatting is the process by which election officials or their designees use election databases and vendor system software to define the specific contests and related instructions contained on the ballot and present them in a layout permitted by state law. All systems shall provide a capability for:

a. Creation of newly defined elections;

b. Rapid and error-free definition of elections and their associated ballot layouts;

c. Uniform allocation of space and fonts used for each office, candidate, and contest such that the voter perceives no active voting position to be preferred to any other;

d. Simultaneous display of the maximum number of choices for a single contest as indicated by the vendor in the system documentation;

e. Retention of previously defined formats for an election;

f. Prevention of unauthorized modification of any ballot formats; and

g. Modification by authorized persons of a previously defined ballot format for use in a subsequent election.

2.3.1.3 Ballot Production

Ballot production is the process of converting ballot formats to a media ready for use in the physical ballot production or electronic presentation.

2.3.1.3.1 Common Standards

The voting system shall provide a means of printing or otherwise generating a ballot display that can be installed in all system voting devices for which it is intended. All systems shall provide a capability to ensure:

a. The electronic display or printed document on which the user views the ballot is capable of rendering an image of the ballot in any of the languages required by The Voting Rights Act of 1965, as amended;

b. The electronic display or printed document on which the user views the ballot does not show any advertising or commercial logos of any kind, whether public service, commercial, or political, unless specifically provided for in State law. Electronic displays shall not provide connection to such material through hyperlink; and

c. The ballot conforms to vendor specifications for type of paper stock, weight, size, shape, size and location of punch or mark field used to record votes, folding, bleed through, and ink for printing if paper ballot documents or paper displays are part of the system.

2.3.1.3.2 Paper-Based System Standards

In addition to the common standards, vendor documentation for marksense systems shall include specifications for ballot materials to ensure that vote selections are read from only a single ballot at a time, without detection of marks from multiple ballots concurrently (e.g., reading of bleed-through from other ballots).

2.3.2 Election Programming

Election programming is the process by which election officials or their designees use election databases and vendor system software to logically define the voter choices associated with Start Printed Page 18956the contents of the ballots. All systems shall provide for the:

a. Logical definition of the ballot, including the definition of the number of allowable choices for each office and contest;

b. Logical definition of political and administrative subdivisions, where the list of candidates or contests varies between polling places;

c. Exclusion of any contest on the ballot in which the voter is prohibited from casting a ballot because of place of residence, or other such administrative or geographical criteria;

d. Ability to select from a range of voting options to conform to the laws of the jurisdiction in which the system will be used; and

e. Generation of all required master and distributed copies of the voting program, in conformance with the definition of the ballots for each voting device and polling place, and for each tabulating device.

2.3.3 Ballot and Program Installation and Control

All systems shall provide a means of installing ballots and programs on each piece of polling place or central count equipment in accordance with the ballot requirements of the election and the requirements of the jurisdiction in which the equipment will be used.

All systems shall include the following at the time of ballot and program installation:

a. A detailed work plan or other documentation providing a schedule and steps for the software and ballot installation, which includes a table outlining the key dates, events and deliverables;

b. A capability for automatically verifying that the software has been properly selected and installed in the equipment or in a programmable memory devices and for indicating errors; and

c. A capability for automatically validating that software correctly matches the ballot formats that it is intended to process, for detecting errors, and for immediately notifying an election official of detected errors.

2.3.4 Readiness Testing

Election personnel conduct equipment and system readiness tests prior to the start of an election to ensure that the voting system functions properly, to confirm that system equipment has been properly integrated, and to obtain equipment status reports.

2.3.4.1 Common Standards

All systems shall provide the capabilities to:

a. Verify that voting machines or vote recording and data processing equipment, precinct count equipment, and central count equipment are properly prepared for an election, and collect data that verifies equipment readiness;

b. Obtain status and data reports from each set of equipment;

c. Verify the correct installation and interface of all system equipment;

d. Verify that hardware and software function correctly;

e. Generate consolidated data reports at the polling place and higher jurisdictional levels; and

f. Segregating test data from actual voting data, either procedurally or by hardware/software features.

Resident test software, external devices, and special purpose test software connected to or installed in voting devices to simulate operator and voter functions may be used for these tests provided that the following standards are met:

a. These elements shall be capable of being tested separately, and shall be proven to be reliable verification tools prior to their use; and

b. These elements shall be incapable of altering or introducing any residual effect on the intended operation of the voting device during any succeeding test and operational phase.

2.3.4.2 Paper-Based Systems

Paper-based systems shall:

a. Support conversion testing that uses all potential ballot positions as active positions; and

b. Support conversion testing of ballots with active position density for systems without pre-designated ballot positions.

2.3.5 Verification at the Polling Place

Election officials perform verification at the polling place to ensure that all voting systems and equipment function properly before and during an election. All systems shall provide a formal record of the following, in any media, upon verification of the authenticity of the command source:

a. The election's identification data;

b. The identification of all equipment units;

c. The identification of the polling place;

d. The identification of all ballot formats;

e. The contents of each active candidate register by office and of each active measure register at all storage locations (showing that they contain only zeros);

f. A list of all ballot fields that can be used to invoke special voting options; and

g. Other information needed to confirm the readiness of the equipment, and to accommodate administrative reporting requirements.

To prepare voting devices to accept voted ballots, all voting systems shall provide the capability to test each device prior to opening to verify that each is operating correctly. At a minimum, the tests shall include:

a. Confirmation that there are no hardware or software failures; and

b. Confirm that the device is ready to be activated for accepting votes.

If a precinct count system includes equipment for the consolidation of polling place data at one or more central counting places, it shall have means to verify the correct extraction of voting data from transportable memory devices, or to verify the transmission of secure data over secure communication links.

2.3.6 Verification at the Central Location

Election officials perform verification at the central location to ensure that vote counting and vote consolidation equipment and software function properly before and after an election. Upon verification of the authenticity of the command source, any system used in a central count environment shall provide a printed record of the following :

a. The election's identification data;

b. The contents of each active candidate register by office and of each active measure register at all storage locations (showing that they contain all zeros); and

c. Other information needed to ensure the readiness of the equipment and to accommodate administrative reporting requirements.

2.4 Voting Functions

All systems shall support:

◆ Opening the polls; and

◆ Casting a ballot.

Additionally, all DRE systems shall support:

◆ Activating the ballot.

◆ Augmenting the election counter; and

◆ Augmenting the life-cycle counter.

2.4.1 Opening the Polls

The capabilities required for opening the polls are specific to individual voting system technologies. At a minimum, the systems shall provide the functional capabilities indicated below.

2.4.1.1 Opening the Polling Place (Precinct Count Systems)

To allow voting devices to be activated for voting, the system shall provide: Start Printed Page 18957

a. An internal test or diagnostic capability to verify that all of the polling place tests specified in Section 2.3.5 have been successfully completed; and

b. Automatic disabling any device that has not been tested until it has been tested.

2.4.1.2 Paper-Based System Standards

The standards for opening the polling place for paper-based systems consist of common standards and additional standards that apply to precinct count paper-based systems.

2.4.1.2.1 All Paper-Based Systems

To facilitate opening the polls, all paper-based systems shall include:

a. A means of verifying that ballot punching or marking devices are properly prepared and ready to use;

b. A voting booth or similar facility, in which the voter may punch or mark the ballot in privacy; and

c. Secure receptacles for holding voted ballots.

2.4.1.2.2 Precinct Count Paper-Based Systems

In addition to the above requirements, all paper-based precinct count equipment shall include a means of:

a. Activating the ballot counting device;

b. Verifying that the device has been correctly activated and is functioning properly; and

c. Identifying device failure and corrective action needed.

2.4.1.3 DRE System Standards

To facilitate opening the polls, all DRE systems shall include:

a. A security seal, a password, or a data code recognition capability to prevent the inadvertent or unauthorized actuation of the poll-opening function;

b. A means of enforcing the execution of steps in the proper sequence if more than one step is required;

c. A means of verifying the system has been activated correctly; and

d. A means of identifying system failure and any corrective action needed.

2.4.2 Activating the Ballot (DRE Systems)

To activate the ballot, all DRE systems shall:

a. Enable election officials to control the content of the ballot presented to the voter, whether presented in printed form or electronic display, such that each voter is permitted to record votes only in contests in which that voter is authorized to vote;

b. Allow each eligible voter to cast a ballot;

c. Prevent a voter from voting on a ballot to which he or she is not entitled; and

d. Prevent a voter from casting more than one ballot in the same election.

e. Activate the casting of a ballot in a general election;

f. Enable the selection of the ballot that is appropriate to the party affiliation declared by the voter in a primary election;

g. Activate all portions of the ballot upon which the voter is entitled to vote; and

h. Disable all portions of the ballot upon which the voter is not entitled to vote.

2.4.3 Casting a Ballot

Some required capabilities for casting a ballot are common to all systems. Others are specific to individual voting technologies or intended use. Systems must provide additional functional capabilities that enable accessibility to disabled voters as defined in Section 2.2.7 of the Standards.

2.4.3.1 Common Standards

To facilitate casting a ballot, all systems shall:

a. Provide text that is at least 3 millimeters high and provide the capability to adjust or magnify the text to an apparent size of 6.3 millimeters;

b. Protect the secrecy of the vote such that the system cannot reveal any information about how a particular voter voted, except as otherwise required by individual State law;

c. Record the selection and non-selection of individual vote choices for each contest and ballot measure;

d. Record the voter's selection of candidates whose names do not appear on the ballot, if permitted under State law, and record as many write-in votes as the number of candidates the voter is allowed to select;

e. In the event of a failure of the main power supply external to the voting system, provide the capability for any voter who is voting at the time to complete casting a ballot, allow for the graceful shutdown of the voting system without loss or degradation of the voting and audit data, and allow voters to resume voting once the voting system has reverted to back-up power; and

f. Provide the capability for voters to continue casting ballots in the event of a failure of a telecommunications connection within the polling place or between the polling place and any other location.

2.4.3.2 Paper-Based Systems Standards

The standards for casting a ballot for paper-based systems consist of common standards and additional standards that apply to precinct count paper-based systems.

2.4.3.2.1 All Paper-Based Systems

All paper-based systems shall:

a. Allow the voter to easily identify the voting field that is associated with each candidate or ballot measure response;

b. Allow the voter to punch or mark the ballot to register a vote;

c. Allow either the voter or the appropriate election official to place the voted ballot into the ballot counting device (for precinct count systems) or into a secure receptacle (for central count systems); and

d. Protect the secrecy of the vote throughout the process.

2.4.3.2.2 Precinct Count Paper-Based Systems

In addition to the above requirements, all paper-based precinct count systems shall:

a. Provide feedback to the voter that identifies specific contests or ballot issues for which an overvote or undervote is detected;

b. Allow the voter, at the voter's choice, to vote a new ballot or submit the ballot ‘as is' without correction; and

c. Allow an authorized election official to turn off the capabilities defined in ‘a' and ‘b' above.

2.4.3.3 DRE Systems Standards

In addition to the above common requirements, DRE systems shall:

a. Prohibit the voter from accessing or viewing any information on the display screen that has not been authorized by election officials and preprogrammed into the voting system (i.e., no potential for display of external information or linking to other information sources);

b. Enable the voter to easily identify the selection button or switch, or the active area of the ballot display that is associated with each candidate or ballot measure response;

c. Allow the voter to select his or her preferences on the ballot in any legal number and combination;

d. Indicate that a selection has been made or canceled;

e. Indicate to the voter when no selection, or an insufficient number of selections, has been made in a contest;

f. Prevent the voter from overvoting;

g. Notify the voter when the selection of candidates and measures is completed;

h. Allow the voter, before the ballot is cast, to review his or her choices and, if the voter desires, to delete or change his or her choices before the ballot is cast; Start Printed Page 18958

i. For electronic image displays, prompt the voter to confirm the voter's choices before casting his or her ballot, signifying to the voter that casting the ballot is irrevocable and directing the voter to confirm the voter's intention to cast the ballot;

j. Notify the voter after the vote has been stored successfully that the ballot has been cast;

k. Notify the voter that the ballot has not been cast successfully if it is not stored successfully, including storage of the ballot image, and provide clear instruction as to the steps the voter should take to cast his or her ballot should this event occur;

l. Provide sufficient computational performance to provide responses back to each voter entry in no more than three seconds;

m. Ensure that the votes stored accurately represent the actual votes cast;

n. Prevent modification of the voter's vote after the ballot is cast;

o. Provide a capability to retrieve ballot images in a form readable by humans (in accordance with the requirements of Section 2.2.2.2 and 2.2.4.2);

p. Increment the proper ballot position registers or counters;

q. Protect the secrecy of the vote throughout the voting process;

r. Prohibit access to voted ballots until after the close of polls;

s. Provide the ability for election officials to submit test ballots for use in verifying the end-to-end integrity of the system; and

t. Isolate test ballots such that they are accounted for accurately in vote counts and are not reflect in official vote counts for specific candidates or measures.

2.5 Post-Voting Functions

All systems shall provide capabilities to accumulate and report results for the jurisdiction and to generate audit trails. In addition, precinct count systems must provide a means to close the polling place including generating appropriate reports. If the system provides the capability to broadcast results, additional standards apply.

2.5.1 Closing the Polling Place (Precinct Count)

These standards for closing the polling place are specific to precinct count systems. The system shall provide the means for:

a. Preventing the further casting of ballots once the polling place has closed;

b. Providing an internal test that verifies that the prescribed closing procedure has been followed, and that the device status is normal;

c. Incorporating a visible indication of system status;

d. Producing a diagnostic test record that verifies the sequence of events, and indicates that the extraction of voting data has been activated; and

e. Precluding the unauthorized reopening of the polls once the poll closing has been completed for that election.

2.5.2 Consolidating Vote Data

All systems shall provide a means to consolidate vote data from all polling places, and optionally from other sources such as absentee ballots, provisional ballots, and voted ballots requiring human review (e.g., write-in votes).

2.5.3 Producing Reports

All systems shall be able to create reports summarizing the data on multiple levels.

2.5.3.1 Common Standards

All systems shall provide capabilities to:

a. Support geographic reporting, which requires the reporting of all results for each contest at the precinct level and additional jurisdictional levels;

b. Produce a printed report of the number of ballots counted by each tabulator;

c. Produce a printed report for each tabulator of the results of each contest that includes the votes cast for each selection, the count of undervotes, and the count of overvotes;

d. Produce a consolidated printed report of the results for each contest of all votes cast (including the count of ballots from other sources supported by the system as specified by the vendor) that includes the votes cast for each selection, the count of undervotes, and the count of overvotes;

e. Be capable of producing a consolidated printed report of the combination of overvotes for any contest that is selected by an authorized official (e.g.; the number of overvotes in a given contest combining candidate A and candidate B, combining candidate A and candidate C, etc.);

f. Produce all system audit information required in Section 4.5 in the form of printed reports, or in electronic memory for printing centrally; and

g. Prevent data from being altered or destroyed by report generation, or by the transmission of results over telecommunications lines.

2.5.3.2 Precinct Count Systems

In addition to the common reporting requirements, all precinct count voting systems shall:

a. Prevent the printing of reports and the unauthorized extraction of data prior to the official close of the polling place;

b. Provide a means to extract information from a transportable programmable memory device or data storage medium for vote consolidation;

c. Consolidate the data contained in each unit into a single report for the polling place when more than one voting machine or precinct tabulator is used; and

d. Prevent data in transportable memory from being altered or destroyed by report generation, or by the transmission of results over telecommunications lines.

2.5.4 Broadcasting Results

Some voting systems offer the capability to make unofficial results available to external organizations such as the news media, political party officials, and others. Although this capability is not required, systems that make unofficial results available shall:

a. Provide only aggregated results, and not data from individual ballots;

b. Provide no access path from unofficial electronic reports or files to the storage devices for official data; and

c. Clearly indicate on each report or file that the results it contains are unofficial.

2.6 Maintenance, Transportation, and Storage

All systems shall be designed and manufactured to facilitate preventive and corrective maintenance, conforming to the hardware standards described in Section 3.

All vote casting and tally equipment designated for storage between elections shall:

a. Function without degradation in capabilities after transit to and from the place of use, as demonstrated by meeting the performance standards described in Section 3; and

b. Function without degradation in capabilities after storage between elections, as demonstrated by meeting the performance standards described in Section 3.

Volume I, Section 3

Table of Contents

3 Hardware Standards

3.1 Scope

3.1.1 Hardware Sources

3.1.2 Organization of this Section

3.2 Performance Requirements

3.2.1 Accuracy Requirements Start Printed Page 18959

3.2.2 Environmental Requirements

3.2.2.1 Shelter Requirements

3.2.2.2 Space Requirements

3.2.2.3 Furnishings and Fixtures

3.2.2.4 Electrical Supply

3.2.2.5 Electrical Power Disturbance

3.2.2.6 Electrical Fast Transient

3.2.2.7 Lightning Surge

3.2.2.8 Electrostatic Disruption

3.2.2.9 Electromagnetic Radiation

3.2.2.10 Electromagnetic Susceptibility

3.2.2.11 Conducted RF Immunity

3.2.2.12 Magnetic Fields Immunity

3.2.2.13 Environmental Control—Operating Environment

3.2.2.14 Environmental Control—Transit and Storage

3.2.2.15 Data Network Requirements

3.2.3 Election Management System (EMS) Requirements

3.2.3.1 Recording Requirements

3.2.3.2 Memory Stability

3.2.4 Vote Recording Requirements

3.2.4.1 Common Standards

3.2.4.2 Paper-Based Recording Standards

3.2.4.2.1 Paper Ballot Standards

3.2.4.2.2 Punching Devices

3.2.4.2.3 Marking Devices

3.2.4.2.4 Frames or Fixtures for Punchcard Ballots

3.2.4.2.5 Frames or Fixtures for Printed Ballots

3.2.4.2.6 Ballot Boxes and Ballot Transfer Boxes

3.2.4.3  DRE Systems Recording Requirements

3.2.4.3.1 Activity Indicator

3.2.4.3.2 DRE System Vote Recording

3.2.4.3.3 Recording Accuracy

3.2.4.3.4 Recording Reliability

3.2.5 Paper-based Conversion Requirements

3.2.5.1 Ballot Handling

3.2.5.1.1 Capacity (Central Count)

3.2.5.1.2 Exception Handling (Central Count)

3.2.5.1.3 Exception Handling (Precinct Count)

3.2.5.1.4 Multiple Feed Prevention

3.2.5.2 Ballot Reading Accuracy

3.2.6  Processing Requirements

3.2.6.1 Paper-Based System Processing Requirements

3.2.6.1.1 Processing Accuracy

3.2.6.1.2 Memory Stability

3.2.6.2 DRE System Processing Requirements

3.2.6.2.1 Processing Speed

3.2.6.2.2 Processing Accuracy

3.2.6.2.3 Memory Stability

3.2.7 Reporting Requirements

3.2.7.1 Removable Storage Media

3.2.7.2 Printers

3.2.8 Vote Data Management Requirements

3.2.8.1 Data File Management

3.2.8.2 Data Report Generation

3.3 Physical Characteristics

3.3.1 Size

3.3.2 Weight

3.3.3 Transport and Storage of Precinct Systems

3.4 Design, Construction, and Maintenance Characteristics

3.4.1 Materials, Processes, and Parts

3.4.2 Durability

3.4.3 Reliability

3.4.4 Maintainability

3.4.4.1 Physical Attributes

3.4.4.2 Additional Attributes

3.4.5 Availability

3.4.6 Product Marking

3.4.7 Workmanship

3.4.8 Safety

3 Hardware Standards

3.1 Scope

This section contains the requirements for the machines and manufactured devices that are part of a voting system. It specifies minimum values for certain performance characteristics; physical characteristics; and design, construction, and maintenance characteristics for the hardware and selected related components of all voting systems, such as:

  • Ballot printers;
  • Ballot cards and sheets;
  • Ballot displays;
  • Voting devices, including punching and marking devices and DRE recording devices;
  • Voting booths and enclosures;
  • Ballot boxes and ballot transfer boxes;
  • Ballot readers;
  • Computers used to prepare ballots, program elections, consolidate and report votes, and perform other elections management activities;
  • Electronic ballot recorders;
  • Electronic precinct vote control units;
  • Removable electronic data storage media;
  • Servers; and
  • Printers.

This section applies to the combination of software and hardware to accomplish specific performance and system control requirements. Standards that are specific to software alone are provided in Section 4 of the Standards.

3.1.1 Hardware Sources

The requirements of this section apply generally to all hardware used in voting systems, including:

a. Hardware provided by the voting system vendor and its suppliers;

b. Hardware furnished by an external provider (for example, providers of commercial off-the-shelf (COTS) machines and devices) where the hardware may be used in any way during voting system operation; and

c. Hardware provided by the voting jurisdiction.

3.1.2 Organization of this Section

The standards presented in this section are organized as follows:

  • Performance Requirements: These requirements address the combined operational capabilities of the voting system's hardware and software across a broad range of parameters;
  • Physical Requirements: These requirements address the size, weight and transportability of the voting system; and
  • Design, Construction, and Maintenance Requirements: These requirements address the reliability and durability of materials, product marking, quality of system workmanship, safety, and other attributes to ensure smooth system operation in the voting environment.

3.2 Performance Requirements

The performance requirements address a broad range of parameters, encompassing:

a. Accuracy requirements, where requirements are specified for distinct processing functions of paper-based and DRE systems;

b. Environmental requirements, where no distinction is made between requirements for paper-based and DRE systems, but requirements for precinct and central count are described;

c. Vote data management requirements, where no differentiation is made between requirements for paper-based and DRE systems;

d. Vote recording requirements, where separate and distinct requirements are delineated for paper-based and DRE systems;

e. Conversion requirements, which apply only to paper-based systems;

f. Processing requirements, where separate and distinct requirements are delineated for paper-based and DRE systems; and

g. Reporting requirements, where no distinction is made between requirements for paper-based and DRE systems, but where differences between precinct and central count systems are readily apparent based on differences of their reporting.

The performance requirements include such attributes as ballot reading and handling requirements; system accuracy; memory stability; and the ability to withstand specified environmental conditions. These characteristics also encompass system-wide requirements for shelter, electrical supply, and compatibility with data networks.

Performance requirements for voting systems represent the combined operational capability of both system hardware and software. Accuracy, as measured by data error rate, and operational failure are treated as distinct attributes in performance testing. All systems shall meet the performance requirements under operating Start Printed Page 18960conditions and after storage under non-operating conditions.

3.2.1 Accuracy Requirements

Voting system accuracy addresses the accuracy of data for each of the individual ballot positions that could be selected by a voter, including the positions that are not selected. For a voting system, accuracy is defined as the ability of the system to capture, record, store, consolidate and report the specific selections and absence of selections, made by the voter for each ballot position without error. Required accuracy is defined in terms of an error rate that for testing purposes represents the maximum number of errors allowed while processing a specified volume of data. This rate is set at a sufficiently stringent level such that the likelihood of voting system errors affecting the outcome of an election is exceptionally remote even in the closest of elections.

The error rate is defined using a convention that recognizes differences in how vote data is processed by different types of voting systems. Paper-based and DRE systems have different processing steps. Some differences also exist between precinct count and central count systems. Therefore, the acceptable error rate applies separately and distinctly to each of the following functions:

a. For all paper-based systems:

(1) Scanning ballot positions on paper ballots to detect selections for individual candidates and contests;

(2) Conversion of selections detected on paper ballots into digital data;

b. For all DRE systems:

(1) Recording the voter selections of candidates and contests into voting data storage; and

(2) Independently from voting data storage, recording voter selections of candidates and contests into ballot image storage.

c. For precinct-count systems (paper-based and DRE):

Consolidation of vote selection data from multiple precinct-based systems to generate jurisdiction-wide vote counts, including storage and reporting of the consolidated vote data; and

d. For central-count systems (paper-based and DRE):

Consolidation of vote selection data from multiple counting devices to generate jurisdiction-wide vote counts, including storage and reporting of the consolidated vote data.

For testing purposes, the acceptable error rate is defined using two parameters: The desired error rate to be achieved, and the maximum error rate that should be accepted by the test process.

For each processing function indicated above, the system shall achieve a target error rate of no more than one in 10,000,000 ballot positions, with a maximum acceptable error rate in the test process of one in 500,000 ballot positions.

3.2.2 Environmental Requirements

The environmental requirements for voting systems include shelter, space, furnishings and fixtures, supplied energy, environmental control , and external telecommunications services. Environmental conditions applicable to the design and operation of voting systems consist of the following categories:

  • Natural environment, including temperature, humidity, and atmospheric pressure;
  • Induced environment, including proper and improper operation and handling of the system and its components during the election processes;
  • Transportation and storage; and
  • Electromagnetic signal environment, including exposure to and generation of radio frequency energy.

All voting systems shall be designed to withstand the environmental conditions contained in the appropriate test procedures of the Standards. These procedures will be applied to all devices for casting, scanning and counting ballots, except those that constitute COTS devices that have not been modified in any manner to support their use as part of a voting system and that have a documented record of performance under conditions defined in the Standards.

The TDP supplied by the vendor shall include a statement of all requirements and restrictions regarding environmental protection, electrical service, recommended auxiliary power, telecommunications service, and any other facility or resource required for the proper installation and operation of the system.

3.2.2.1 Shelter Requirements

All precinct count systems shall be designed for storage and operation in any enclosed facility ordinarily used as a warehouse or polling place, with prominent instructions as to any special storage requirements.

3.2.2.2 Space Requirements

There is no restriction on space allowed for the installation of voting systems, except that the arrangement of these systems shall not impede performance of their duties by polling place officials, the orderly flow of voters through the polling place, or the ability for the voter to vote in private.

3.2.2.3 Furnishings and Fixtures

Any furnishings or fixtures provided as a part of voting systems, and any components provided by the vendor that are not a part of the system but that are used to support its storage, transportation, or operation, shall comply with the design and safety requirements of Subsection 3.4.8.

3.2.2.4 Electrical Supply

Components of voting systems that require an electrical supply shall meet the following standards:

a. Precinct count systems shall operate with the electrical supply ordinarily found in polling places (120vac/60hz/1);

b. Central count systems shall operate with the electrical supply ordinarily found in central tabulation facilities or computer room facilities (120vac/60hz/1, 208vac/60hz/3, or 240vac/60hz/2); and

c. All systems shall also be capable of operating for a period of at least 2 hours on backup power, such that no voting data is lost or corrupted, nor normal operations interrupted. When backup power is exhausted the system shall retain the contents of all memories intact.

The backup power capability is not required to provide lighting of the voting area.

3.2.2.5 Electrical Power Disturbance

Vote scanning and counting equipment for paper-based systems, and all DRE equipment, shall be able to withstand, without disruption of normal operation or loss of data:

a. Surges of 30% dip @10 ms;

b. Surges of 60% dip @100 ms & 1 sec;

c. Surges of >95% interrupt @5 sec;

d. Surges of ±15% line variations of nominal line voltage; and

e. Electric power increases of 7.5% and reductions of 12.5% of nominal specified power supply for a period of up to four hours at each power level.

3.2.2.6 Electrical Fast Transient

Vote scanning and counting equipment for paper-based systems, and all DRE equipment, shall be able to withstand, without disruption of normal operation or loss of data, electrical fast transients of:

a. 2 kV AC & DC external power lines;

b. ±1 kV all external wires >3m no control; and

c. ±2 kV all external wires control.

3.2.2.7 Lightning Surge

Vote scanning and counting equipment for paper-based systems, and Start Printed Page 18961all DRE equipment, shall be able to withstand, without disruption of normal operation or loss of data, surges of:

a. ±2 kV AC line to line;

b. ±2 kV AC line to earth;

c. ±.5 kV DC line to line >10m;

d. ±.5 kV DC line to earth >10m; and

e. ±1 kV I/O sig/control >30m.

3.2.2.8 Electrostatic Disruption

Vote scanning and counting equipment for paper-based systems, and all DRE equipment, shall be able to withstand ±15 kV air discharge and ±8 kV contact discharge without damage or loss of data. The equipment may reset or have momentary interruption so long as normal operation is resumed without human intervention or loss of data. Loss of data means votes that have been completed and confirmed to the voter.

3.2.2.9 Electromagnetic Radiation

Vote scanning and counting equipment for paper-based systems, and all DRE equipment, shall comply with the Rules and Regulations of the Federal Communications Commission, Part 15, Class B requirements for both radiated and conducted emissions.

3.2.2.10 Electromagnetic Susceptibility

Vote scanning and counting equipment for paper-based systems, and all DRE equipment, shall be able to withstand an electromagnetic field of 10 V/m modulated by a 1 kHz 80% AM modulation over the frequency range of 80 MHz to 1000 MHz, without disruption of normal operation or loss of data.

3.2.2.11 Conducted RF Immunity

Vote scanning and counting equipment for paper-based systems, and all DRE equipment, shall be able to withstand, without disruption of normal operation or loss of data, conducted RF energy of:

a. 10V AC & DC power; and

b. 10V, 20 sig/control >3m.

3.2.2.12 Magnetic Fields Immunity

Vote scanning and counting equipment for paper-based systems, and all DRE equipment, shall be able to withstand, without disruption of normal operation or loss of data, AC magnetic fields of 30 A/m at 60 Hz.

3.2.2.13 Environmental Control—Operating Environment

Equipment used for election management activities or vote counting (including both precinct and central count systems) shall be capable of operation in temperatures ranging from 50 to 95 degrees Fahrenheit.

3.2.2.14 Environmental Control—Transit and Storage

Equipment used for vote casting, or for counting votes in a precinct count system, shall meet specific minimum performance standards that simulate exposure to physical shock and vibration associated with handling and transportation by surface and air common carriers, and to temperature conditions associated with delivery and storage in an uncontrolled warehouse environment.

a. High and low storage temperatures ranging from −4 to +140 degrees Fahrenheit, equivalent to MIL-STD-810D, Methods 501.2 and 502.2, Procedure I-Storage;

b. Bench handling equivalent to the procedure of MIL-STD-810D, Method 516.3, Procedure VI;

c. Vibration equivalent to the procedure of MIL-STD-810D, Method 514.3, Category 1—Basic Transportation, Common Carrier; and

d. Uncontrolled humidity equivalent to the procedure of MIL-STD-810D, Method 507.2, Procedure I—Natural Hot—Humid.

3.2.2.15 Data Network Requirements

Voting systems may use a local or remote data network. If such a network is used, then all components of the network shall comply with the telecommunications requirements described in Section 5 of the Standards and the Security requirements described in Section 6.

3.2.3 Election Management System (EMS) Requirements

The EMS requirements address electronic hardware and software used to conduct the pre-voting functions defined in Section 2 with regard to ballot preparation, election programming, ballot and program installation, readiness testing, verification at the polling place, and verification at the central location.

3.2.3.1 Recording Requirements

Voting systems shall accurately record all election management data entered by the user, including election officials or their designees. For recording accuracy, all systems shall:

a. Record every entry made by the user;

b. Add permissible voter selections correctly to the memory components of the device;

c. Verify the correctness of detection of the user selections and the addition of the selections correctly to memory;

d. Add various forms of data entered directly by the election official or designee, such as text, line art, logos, and images;

e. Verify the correctness of detection of data entered directly by the user and the addition of the selections correctly to memory;

f. Preserve the integrity of election management data stored in memory against corruption by stray electromagnetic emissions, and internally generated spurious electrical signals; and

g. Log corrected data errors by the system.

3.2.3.2 Memory Stability

Electronic system memory devices, used to retain election management data, shall have demonstrated error-free data retention for a period of 22 months.

3.2.4 Vote Recording Requirements

The vote recording requirements address the enclosure, equipment, and supplies used by voters to vote.

3.2.4.1 Common Standards

All systems shall provide voting booths or enclosures for poll site use. Such booths or enclosures may be integral to the voting system or supplied as components of the voting system, and shall:

a. Be integral to, or makes provision for, the installation of, the voting device;

b. Ensure by its structure stability against movement or overturning during entry, occupancy, and exit by the voter;

c. Provide privacy for the voter, and be designed in such a way as to prevent observation of the ballot by any person other than the voter; and

d. Be capable of meeting the accessibility requirements of Section 2.2.7.1.

3.2.4.2 Paper-Based Recording Standards

The paper-based recording requirements govern:

  • Ballot cards or sheets, and pages or assemblies of pages containing ballot field identification data;
  • Punching devices;
  • Marking devices;
  • Frames or fixtures to hold the ballot while it is being punched;
  • Compartments or booths where voters record selections; and
  • Secure containers for the collection of voted ballots.

3.2.4.2.1 Paper Ballot Standards

Paper ballots used by paper-based voting systems shall meet the following standards:

a. Punches or marks that identify the unique ballot format, in accordance with Section 2.3.1.1.1.c., shall be Start Printed Page 18962outside the area in which votes are recorded, so as to minimize the likelihood that these punches or marks will be mistaken for vote responses and the likelihood that recorded votes will obliterate these punches or marks;

b. If printed or punched alignment marks are used to locate the vote response fields on the ballot, these marks shall be outside the area in which votes are recorded, so as to minimize the likelihood that these marks will be mistaken for vote responses and the likelihood that recorded votes will obliterate these marks; and

c. The TDP shall specify the required paper stock, size, shape, opacity, color, watermarks, field layout, orientation, size and style of printing, size and location of punch or mark fields used for vote response fields and to identify unique ballot formats, placement of alignment marks, ink for printing, and folding and bleed-through limitations for preparation of ballots that are compatible with the system.

3.2.4.2.2 Punching Devices

Punching devices used by voting systems shall:

a. Be suitable for the type of ballot card specified;

b. Facilitate the clear and accurate recording of each vote intended by the voter;

c. Be designed to avoid excessive damage to vote recorder components; and

d. Incorporate features to ensure that the chad (debris) is completely removed, without damage to other parts of the ballot card.

3.2.4.2.3 Marking Devices

The TDP shall specify marking devices (such as pens or pencils) that, if used to make the prescribed form of mark, produce readable marked ballots such that the system meets the performance requirements for accuracy specified previously. These specifications shall identify:

a. Specific characteristics of marking devices that affect readability of marked ballots;

b. Performance capabilities with regard to each characteristic; and

c. For marking devices manufactured by multiple external sources, a listing of sources and model numbers that are compatible with the system.

3.2.4.2.4 Frames or Fixtures for Punchcard Ballots

The frame or fixture for punchcards shall:

a. Hold the ballot card securely in its proper location and orientation for voting;

b. When contests are not printed directly on the ballot card or sheet, incorporate an assembly of ballot label pages that identify the offices and issues corresponding to the proper ballot format for the polling place where it is used and that are aligned with the voting fields assigned to them; and

c. Incorporate a template to preclude perforation of the card except in the specified voting fields; a mask to allow punches only in fields designated by the format of the ballot; and a backing plate for the capture and removal of chad. This requirement may be satisfied by equipment of a different design as long it achieves the same result as the Standards with regard to:

(1) Positioning the card;

(2) Association of ballot label information with corresponding punch fields;

(3) Enabling of only those voting fields that correspond to the format of the ballot; and

(4) Punching the fields and the positive removal of chad.

3.2.4.2.5 Frames or Fixtures for Printed Ballots

A frame or fixture for printed ballot cards is optional. However, if such a device is provided, it shall:

a. Be of any size and shape consistent with its intended use;

b. Position the card properly;

c. Hold the ballot card securely in its proper location and orientation for voting; and

d. Comply with the requirements for design and construction contained in Section 3.4.

3.2.4.2.6 Ballot Boxes and Ballot Transfer Boxes

Ballot boxes and ballot transfer boxes, which serve as secure containers for the storage and transportation of voted ballots, shall:

a. Be of any size, shape, and weight commensurate with their intended use;

b. Incorporate locks or seals, the specifications of which are described in the system documentation;

c. Provide specific points where ballots are inserted, with all other points on the box constructed in a manner that prevents ballot insertion; and

d. For precinct count systems, contain separate compartments for the segregation of unread ballots, ballots containing write-in votes, or any irregularities that may require special handling or processing. In lieu of compartments, the conversion processing may mark such ballots with an identifying spot or stripe to facilitate manual segregation.

3.2.4.3 DRE Systems Recording Requirements

The DRE systems recording requirements address the detection and recording of votes, including the logic and data processing functions required to determine the validity of voter selections, to accept and record valid selections, and to reject invalid selections. The requirements also address the physical environment in which ballots are cast.

3.2.4.3.1 Activity Indicator

DRE systems shall include an audible or visible activity indicator providing the status of each voting device. This indicator shall:

a. Indicate whether the device has been activated for voting; and

b. Indicate whether the device is in use.

3.2.4.3.2 DRE System Vote Recording

To ensure vote recording accuracy and integrity while protecting the anonymity of the voter, all DRE systems shall:

a. Contain all mechanical, electromechanical, and electronic components; software; and controls required to detect and record the activation of selections made by the voter in the process of voting and casting a ballot;

b. Incorporate redundant memories to detect and allow correction of errors caused by the failure of any of the individual memories;

c. Provide at least two processes that record the voter's selections that:

(1) To the extent possible, are isolated from each other;

(2) Designate one process and associated storage location as the main vote detection, interpretation, processing and reporting path; and

(3) Use a different process to store ballot images, for which the method of recording may include any appropriate encoding or data compression procedure consistent with the regeneration of an unequivocal record of the ballot as cast by the voter.

d. Provide a capability to retrieve ballot images in a form readable by humans; and

e. Ensure that all processing and storage protects the anonymity of the voter.

3.2.4.3.3 Recording Accuracy

DRE systems shall meet the following requirements for recording accurately each vote and ballot cast:

a. Detect every selection made by the voter;Start Printed Page 18963

b. Correctly add permissible selections to the memory components of the device;

c. Verify the correctness of the detection of the voter selections and the addition of the selections to memory;

d. Achieve an error rate not to exceed the requirement indicated in Section 3.2.1;

e. Preserve the integrity of voting data and ballot images (for DRE machines) stored in memory for the official vote count and audit trail purposes against corruption by stray electromagnetic emissions, and internally generated spurious electrical signals; and

f. Maintain a log of corrected data.

3.2.4.3.4 Recording Reliability

Recording reliability refers to the ability of the DRE system to record votes accurately at its maximum rated processing volume for a specified period of time. The DRE system shall record votes reliably in accordance with the requirements of Section 3.4.3.

3.2.5 Paper-Based Conversion Requirements

The paper-based conversion requirements address the ability of the system to read the ballot card and to translate its pattern of punches or marks into electronic signals for later processing. These capabilities may be built into the voting system in an integrated fashion, or may be provided by one or more components that are not unique to the system, such as a general-purpose data processing card reader or read head suitably interfaced to the system. These requirements address two major functions: ballot handling and ballot reading.

3.2.5.1 Ballot Handling

Ballot handling consists of a ballot card's acceptance, movement through the read station, and transfer into a collection station or receptacle.

3.2.5.1.1 Capacity (Central Count)

The capacity to convert the punches or marks on individual ballots into signals is uniquely important to central count systems. The capacity for a central count system shall be documented by the vendor. This documentation shall include the capacity for individual components that impact the overall capacity.

3.2.5.1.2 Exception Handling (Central Count)

This requirement refers to the handling of ballots for a central count system when they are unreadable or when some condition is detected requiring that the cards be segregated from normally processed ballots for human review. In response to an unreadable ballot or a write-in vote all central count paper-based systems shall:

a. Outstack the ballot, or

b. Stop the ballot reader and display a message prompting the election official or designee to remove the ballot, or

c. Mark the ballot with an identifying mark to facilitate its later identification.

Additionally, the system shall provide a capability that can be activated by an authorized election official to identify ballots containing overvotes, blank ballots, and ballots containing undervotes in a designated race. If enabled, these capabilities shall perform one of the above actions in response to the indicated condition.

3.2.5.1.3 Exception Handling (Precinct Count)

This requirement refers to the handling of ballots for a precinct count system when they are unreadable or when some condition is detected requiring that the cards be segregated from normally processed ballots for human review. All paper based precinct count systems shall:

a. In response to an unreadable or blank ballot, return the ballot and provide a message prompting the voter to examine the ballot;

b. In response to a ballot with a write-in vote, segregate the ballot or mark the ballot with an identifying mark to facilitate its later identification;

c. In response to a ballot with an overvote the system shall:

(1) Provide a capability to identify an overvoted ballot;

(2) Return the ballot;

(3) Provide an indication prompting the voter to examine the ballot;

(4) Allow the voter to submit the ballot with the overvote; and

(5) Provide a means for an authorized election official to deactivate this capability entirely and by contest; and

d. In response to a ballot with an undervote the system shall:

(1) Provide a capability to identify an undervoted ballot;

(2) Return the ballot;

(3) Provide an indication prompting the voter to examine the ballot;

(4) Allow the voter to submit the ballot with the undervote; and

(5) Provide a means for an authorized election official to deactivate this capability.

3.2.5.1.4 Multiple Feed Prevention

Multiple feed refers to the situation arising when a ballot reader attempts to read more than one ballot at a time. The requirements govern the ability of a ballot reader to prevent multiple feed or to detect and provide an alarm indicating multiple feed.

a. If multiple feed is detected, the card reader shall halt in a manner that permits the operator to remove the unread cards causing the error, and reinsert them in the card input hopper.

b. The frequency of multiple feeds with ballots intended for use with the system shall not exceed 1 in 10,000.

3.2.5.2 Ballot Reading Accuracy

This paper-based system requirement governs the conversion of the physical ballot into electronic data. Reading accuracy for ballot conversion refers to the ability to:

  • Recognize vote punches or marks, or the absence thereof, for each possible selection on the ballot;
  • Discriminate between valid punches or marks and extraneous perforations, smudges, and folds; and
  • Convert the vote punches or marks, or the absence thereof, for each possible selection on the ballot into digital signals.

To ensure accuracy, paper-based systems shall:

a. Detect punches or marks that conform to vendor specifications with an error rate not exceeding the requirement indicated in Section 3.2.1;

b. Ignore, and not record, extraneous perforations, smudges, and folds; and

c. Reject ballots that meet all vendor specifications at a rate not to exceed 2 percent.

3.2.6 Processing Requirements

Processing requirements apply to the hardware and software required to accumulate voting data for all candidates and measures within voting machines and polling places, and to consolidate the voting data at a central level or multiple levels. These requirements also address the generation and maintenance of audit records, the detection and disabling of improper use or operation of the system, and the monitoring of overall system status. Separate and distinct requirements for paper-based and DRE voting systems are presented below.

3.2.6.1 Paper-Based System Processing Requirements

The paper-based processing requirements address all mechanical devices, electromechanical devices, electronic devices, and software required to perform the logical and numerical functions of interpreting the electronic image of the voted ballot, and assigning votes to the proper memory registers. Start Printed Page 18964

3.2.6.1.1 Processing Accuracy

Processing accuracy refers to the ability of the system to receive electronic signals produced by punches for punchcard systems and vote marks and timing information for marksense systems; perform logical and numerical operations upon these data; and reproduce the contents of memory when required, without error. Specific requirements are detailed below:

a. Processing accuracy shall be measured by vote selection error rate, the ratio of uncorrected vote selection errors to the total number of ballot positions that could be recorded across all ballots when the system is operated at its nominal or design rate of processing;

b. The vote selection error rate shall include data that denotes ballot style or precinct as well as data denoting a vote in a specific contest or ballot proposition;

c. The vote selection error rate shall include all errors from any source; and

d. The vote selection error rate shall not exceed the requirement indicated in Section 3.2.1.

3.2.6.1.2 Memory Stability

Paper-based system memory devices, used to retain control programs and data, shall have demonstrated error-free data retention for a period of 22 months, under the environmental conditions for operation and non-operation (i.e. storage).

3.2.6.2 DRE System Processing Requirements

The DRE system processing requirements address all mechanical devices, electromechanical devices, electronic devices, and software required to process voting data after the polling places are closed.

3.2.6.2.1 Processing Speed

DRE voting systems shall meet the following requirements for processing speed:

a. Operate at a speed sufficient to respond to any operator and voter input without perceptible delay (no more than three seconds); and

b. If the consolidation of polling place data is done locally, perform this consolidation in a time not to exceed five minutes for each device in the polling place.

3.2.6.2.2 Processing Accuracy

Processing accuracy is defined as the ability of the system to process voting data stored in DRE voting devices, or in removable memory modules installed in such devices. Processing includes all operations to consolidate voting data after the polling places have been closed. DRE voting systems shall:

a. Produce reports that are completely consistent, with no discrepancy among reports of voting device data produced at any level; and

b. Produce consolidated reports containing absentee, provisional, or other voting data that are similarly error-free. Any discrepancy, regardless of source, is resolvable to a procedural error, to the failure of a non-memory device, or to an external cause.

3.2.6.2.3 Memory Stability

DRE system memory devices used to retain control programs and data shall have demonstrated error-free data retention for a period of 22 months. Error-free retention may be achieved by the use of redundant memory elements, provided that the capability for conflict resolution or correction among elements is included.

3.2.7 Reporting Requirements

The reporting requirements govern all mechanical, electromechanical, and electronic devices required for voting systems to print audit record entries and results of the tabulation. These requirements also address data storage media for transportation of data to other sites.

3.2.7.1 Removable Storage Media

In voting systems that use storage media that can be removed from the system and transported to another location for readout and report generation, these media shall use devices with demonstrated error-free retention for a period of 22 months under the environmental conditions for operation and non-operation contained in Section 3.2.2. Examples of removable storage media include: programmable read-only memory (PROM), random access memory (RAM) with battery backup, magnetic media, or optical media.

3.2.7.2 Printers

All printers used to produce reports of the vote count shall be capable of producing:

a. Alphanumeric headers;

b. Election, office and issue labels; and

c. Alphanumeric entries generated as part of the audit record.

3.2.8 Vote Data Management Requirements

The vote data management requirements for all systems address capabilities that manage, process, and report voting data after the data has been consolidated at the polling place or other intermediate levels. These capabilities allow the system to:

a. Consolidate voting data from polling place data memory or transfer devices;

b. Report polling place summaries; and

c. Process absentee ballots, data entered manually, and administrative ballot definition data.

The requirements address all hardware and software required to generate output reports in the various formats required by the using jurisdiction.

3.2.8.1 Data File Management

All voting systems shall provide the capability to:

a. Integrate voting data files with ballot definition files;

b. Verify file compatibility; and

c. Edit and update files as required.

3.2.8.2 Data Report Generation

All voting systems shall include report generators for producing output reports at the device, polling place, and summary level, with provisions for administrative and judicial subdivisions as required by the using jurisdiction.

3.3 Physical Characteristics

This section covers physical characteristics of all voting systems and components that affect their general utility and suitability for election operations.

3.3.1 Size

There is no numerical limitation on the size of any voting system equipment, but the size of each device should be compatible with its intended use and the location at which the equipment is to be used.

3.3.2 Weight

There is no numerical limitation on the weight of any voting system equipment, but the weight of each device should be compatible with its intended use and the location at which the equipment is to be used.

3.3.3 Transport and Storage of Precinct Systems

All precinct systems shall:

a. Provide a means to safely and easily handle, transport, and install polling place equipment, such as wheels or a handle or handles; and

b. Be capable of using, or be provided with, a protective enclosure rendering the equipment capable of withstanding:

(1) Impact, shock and vibration loads accompanying surface and air transportation; and

(2) Stacking loads accompanying storage. Start Printed Page 18965

3.4 Design, Construction, and Maintenance Characteristics

This section covers voting system materials, construction workmanship, and specific design characteristics important to the successful operation and efficient maintenance of the system.

3.4.1 Materials, Processes, and Parts

The approach to system design is unrestricted, and may incorporate any form or variant of technology capable of meeting the voting systems requirements and standards.

Precinct count systems shall be designed in accordance with best commercial practice for microcomputers, process controllers, and their peripheral components. Central count voting systems and equipment used in a central tabulating environment shall be designed in accordance with best commercial and industrial practice.

All voting systems shall:

a. Be designed and constructed so that the frequency of equipment malfunctions and maintenance requirements are reduced to the lowest level consistent with cost constraints;

b. Include, as part of the accompanying TDP, an approved parts list; and

c. Exclude parts or components not included in the approved parts list.

3.4.2 Durability

All voting systems shall be designed to withstand normal use without deterioration and without excessive maintenance cost for a period of ten years.

3.4.3 Reliability

The reliability of voting system devices shall be measured as mean time between Failure (MTBF) for the system submitted for testing. MBTF is defined as the value of the ratio of operating time to the number of failures which have occurred in the specified time interval. A typical system operations scenario consist of approximately 45 hours of equipment operation, consisting of 30 hours of equipment set-up and readiness testing and 15 hours of elections operations. For the purpose of demonstrating compliance with this requirement, a failure is defined as any event which results in either the:

a. Loss of one or more functions; or

b. Degradation of performance such that the device is unable to perform its intended function for longer than 10 seconds.

The MTBF demonstrated during qualification testing shall be at least 163 hours.

3.4.4 Maintainability

Maintainability represents the ease with which maintenance actions can be performed based on the design characteristics of equipment and software and the processes the vendor and election officials have in place for preventing failures and for reacting to failures. Maintainability includes the ability of equipment and software to self-diagnose problems and make non-technical election workers aware of a problem. Maintainability addresses all scheduled and unscheduled events, which are performed to:

  • Determine the operational status of the system or a component;
  • Adjust, align, tune, or service components;
  • Repair or replace a component having a specified operating life or replacement interval;
  • Repair or replace a component that exhibits an undesirable predetermined physical condition or performance degradation;
  • Repair or replace a component that has failed; and
  • Verify the restoration of a component, or the system, to operational status.

Maintainability shall be determined based on the presence of specific physical attributes that aid system maintenance activities, and the ease with which system maintenance tasks can be performed by the ITA. Although a more quantitative basis for assessing maintainability, such as the mean to repair the system is desirable, the qualification of a system is conducted before it is approved for sale and thus before a broader base of maintenance experience can be obtained.

3.4.4.1 Physical Attributes

The following physical attributes will be examined to assess reliability:

a. Presence of labels and the identification of test points;

b. Provision of built-in test and diagnostic circuitry or physical indicators of condition;

c. Presence of labels and alarms related to failures; and

d. Presence of features that allow non-technicians to perform routine maintenance tasks (such as update of the system database).

3.4.4.2 Additional Attributes

The following additional attributes will be considered to assess system maintainability.

a. Ease of detecting that equipment has failed by a non-technician;

b. Ease of diagnosing problems by a trained technician;

c. Low false alarm rates (i.e., indications of problems that do not exist);

d. Ease of access to components for replacement;

e. Ease with which adjustment and alignment can be performed;

f. Ease with which database updates can be performed by a non-technician; and

g. Adjust, align, tune, or service components.

3.4.5 Availability

The availability of a voting system is defined as the probability that the equipment (and supporting software) needed to perform designated voting functions will respond to operational commands and accomplish the function. The voting system shall meet the availability standard for each of the following voting functions:

a. For all paper-based systems:

(1) Recording voter selections (such as by ballot marking or punch); and

(2) Scanning the punches or marks on paper ballots and converting them into digital data;

b. For all DRE systems, recording and storing the voter's ballot selections.

c. For precinct-count systems (paper-based and DRE), consolidation of vote selection data from multiple precinct-based systems to generate jurisdiction-wide vote counts, including storage and reporting of the consolidated vote data; and

d. For central-count systems (paper-based and DRE), consolidation of vote selection data from multiple counting devices to generate jurisdiction-wide vote counts, including storage and reporting of the consolidated vote data.

System availability is measured as the ratio of the time during which the system is operational a (up time) to the total time period of operation (up time plus down time). Inherent availability (Ai) is a the fraction of time a system is functional, based upon Mean Time Between Failure (MTBF) and Mean Time to Repair (MTTR), that is:

Ai = (MTBF)/(MTBF + MTTR)

Mean Time to Repair (MTTR) is the average time required to perform a corrective maintenance task during periods of system operation. Corrective maintenance task time is active repair time, plus the time attributable to other factors that could lead to logistic or administrative delays, such as travel notification of qualified maintenance personnel and travel time for such personnel to arrive at the appropriate site.

Corrective maintenance may consist of substitution of the complete device or one of its components, as in the case of precinct count and some central count systems, or it may consist of on-site repair. Start Printed Page 18966

The voting system shall achieve at least ninety nine percent availability during normal operation for the functions indicated above. This standard encompasses for each function the combination of all devices and components that support the function, including their MTTR and MTBF attribute.

Vendors shall specify the typical system configuration that is to be used to assess availability, and any assumptions made with regard to any parameters that impact the MTTR. These factors shall include at a minimum:

a. Recommended number and locations of spare devices or components to be kept on hand for repair purposes during periods of system operation;

b. Recommended number and locations of qualified maintenance personnel who need to be available to support repair calls during system operation; and

c. Organizational affiliation (i.e., jurisdiction, vendor) of qualified maintenance personnel.

3.4.6 Product Marking

All voting systems shall:

a. Identify all devices by means of a permanently affixed nameplate or label containing the name of the manufacturer or vendor, the name of the device, its part or model number, its revision letter, its serial number, and if applicable, its power requirements;

b. Display on each device a separate data plate containing a schedule for and list of operations required to service or to perform preventive maintenance; and

c. Display advisory caution and warning instructions to ensure safe operation of the equipment and to avoid exposure to hazardous electrical voltages and moving parts at all locations where operation or exposure may occur.

3.4.7  Workmanship

To help ensure proper workmanship, all manufacturers of voting systems shall:

a. Adopt and adhere to practices and procedures to ensure that their products are free from damage or defect that could make them unsatisfactory for their intended purpose; and

b. Ensure that components provided by external suppliers are free from damage or defect that could make them unsatisfactory for their intended purpose.

3.4.8  Safety

All voting systems shall meet the following requirements for safety:

a. All voting systems and their components shall be designed so as to eliminate hazards to personnel, or to the equipment itself;

b. Defects in design and construction that can result in personal injury or equipment damage must be detected and corrected before voting systems and components are placed into service; and

c. Equipment design for personnel safety shall be equal to or better than the appropriate requirements of the Occupational Safety and Health Act (OSHA), as identified in Title 29, part 1910, of the Code of Federal Regulations.

Volume I, Section 4

Table of Contents

4 Software Standards

4.1 Scope

4.1.1 Software Sources

4.1.2 Location and Control of Software and Hardware on Which it Operates

4.1.3 Exclusions

4.2 Software Design and Coding Standards

4.2.1 Selection of Programming Languages

4.2.2 Software Integrity

4.2.3 Software Modularity and Programming

4.2.4 Control Constructs

4.2.5 Naming Conventions

4.2.6 Coding Conventions

4.2.7 Comment Conventions

4.3 Data and Document Retention

4.4 Audit Record Data

4.4.1 Pre-election Audit Records

4.4.2 System Readiness Audit Records

4.4.3 In-Process Audit Records

4.4.4 Vote Tally Data

4.5 Vote Secrecy (DRE Systems)

4 Software Standards

4.1 Scope

This section describes essential design and performance characteristics of the software used in voting systems, addressing both system-level software, such as operating systems, and voting system application software, including firmware. The requirements of this section are intended to ensure that voting system software is reliable, robust, testable, and maintainable. The standards in this section also support system accuracy, logical correctness, privacy, security and integrity.

The general requirements of this section apply to software used to support the entire range of voting system activities described in Section 2. More specific requirements are defined for ballot counting, vote processing, creating an audit trail, and generating output reports and files. Although this section emphasizes software, the standards described also influence hardware design considerations.

This section recognizes that there is no best way to design software. Many programming languages are available for which modern programming practices are applicable, such as the use of rigorous program and data structures, data typing, and naming conventions. Other programming languages exist for which such practices are not easily applied.

The Standards are intended to guide the design of software written in any of the programming languages commonly used for mainframe, mini-computer, and microprocessor systems. They are not intended to preclude the use of other languages or environments, such as those that exhibit “declarative” structure, “object-oriented” languages, “functional” programming languages, or any other combination of language and implementation that provides appropriate levels of performance, testability, reliability, and security. The vendor makes specific software selections. However, the use of widely recognized and proven software design methods will facilitate the analysis and testing of voting system software in the qualification process.

4.1.1 Software Sources

The requirements of this section apply generally to all software used in voting systems, including:

  • Software provided by the voting system vendor and its component suppliers;
  • Software furnished by an external provider (for example, providers of COTS operating systems and web browsers) where the software may be used in any way during voting system operation; and
  • Software developed by the voting jurisdiction.

Compliance with the requirements of the software standards is assessed by several formal tests, including code examination. Unmodified software is not subject to code examination; however, source code generated by a package and embedded in software modules for compilation or interpretation shall be provided in human readable form to the ITA. The ITA may inspect source code units to determine testing requirements or to verify that the code is unmodified and that the default configuration options have not been changed.

Configuration of software, both operating systems and applications, is critical to proper system functioning. Correct test design and sufficient test execution must account for the intended and proper configuration of all system components. Therefore, the vendors shall submit to the ITA, in the TDP, a Start Printed Page 18967record of all user selections made during software installation. The vendor shall also submit a record of all configuration changes made to the software following its installation. The ITA shall confirm the propriety and correctness of these user selections and configuration changes.

4.1.2 Location and Control of Software and Hardware on Which it Operates

The requirements of this section apply to all software used in any manner to support any voting-related activities, regardless of the ownership of the software or the ownership and location of the hardware on which the software is installed or operates. These requirements apply to:

  • Software that operates on voting devices and vote counting devices installed at polling places under the control of the voting jurisdiction;
  • Software that operates on ballot printers, vote counting devices, and other hardware typically installed at central or precinct locations (including contractor facilities); and
  • Election management software.

However, some requirements apply only in specific situations indicated in this section. In addition to the requirements of this section, all software used in any manner to support any voting-related activities shall meet the requirements for security described in Section 6 of the Standards.

4.1.3 Exclusions

Some voting systems use equipment, such as personal computers, that may be used for other purposes and have resident on the equipment general purpose software such as operating systems, programming language compilers, database management systems, and Web browsers. Such software is governed by the Standards unless:

  • The software provides no support of voting system capabilities;
  • The software is removable, disconnectable, or switchable such that it cannot function while voting system functions are enabled; and
  • Procedures are provided that confirm that the software has been removed, disconnected, or switched.

4.2 Software Design and Coding Standards

The software used by voting systems is selected by the vendor and not prescribed by the Standards. This section provides standards for voting system software with regard to:

  • Selection of programming languages;
  • Software integrity;
  • Software modularity and programming;
  • Control constructs;
  • Naming conventions;
  • Coding conventions; and
  • Comment conventions.

4.2.1 Selection of Programming Languages

Software associated with the logical and numerical operations of vote data shall use a high-level programming language, such as: Pascal, Visual Basic, Java, C and C++. The requirement for the use of high-level language for logical operations does not preclude the use of assembly language for hardware-related segments, such as device controllers and handler programs. Also, operating system software may be designed in assembly language.

4.2.2 Software Integrity

Self-modifying, dynamically loaded, or interpreted code is prohibited, except under the security provisions outlined in section 6.4.e. This prohibition is to ensure that the software tested and approved during the qualification process remains unchanged and retains its integrity. External modification of code during execution shall be prohibited. Where the development environment (programming language and development tools) includes the following features, the software shall provide controls to prevent accidental or deliberate attempts to replace executable code:

  • Unbounded arrays or strings (includes buffers used to move data);
  • Pointer variables; and
  • Dynamic memory allocation and management.

4.2.3 Software Modularity and Programming

Voting system application software, including COTS software, shall be designed in a modular fashion. However, COTS software is not required to be inspected for compliance with this requirement. For the purpose of this requirement [1] , “modules” may be compiled or interpreted independently. Modules may also be nested. The modularity rules described here apply to the component sub modules of a library. The principle concept is that the module contains all the elements to compile or interpret successfully and has limited access to data in other modules. The design concept is simple replacement with another module whose interfaces match the original module. A module is designed in accordance with the following rules:

a. Each module shall have a specific function that can be tested and verified independently of the remainder of the code. In practice, some additional modules (such as library modules) may be needed to compile the module under test, but the modular construction allows the supporting modules to be replaced by special test versions that support test objectives;

b. Each module shall be uniquely and mnemonically named, using names that differ by more than a single character. In addition to the unique name, the modules shall include a set of header comments identifying the module's purpose, design, conditions, and version history, followed by the operational code. Headers are optional for modules of fewer than ten executable lines where the subject module is embedded in a larger module that has a header containing the header information. Library modules shall also have a header comment describing the purpose of the library and version information;

c. All required resources, such as data accessed by the module, should either be contained within the module or explicitly identified as input or output to the module. Within the constraints of the programming language, such resources shall be placed at the lowest level where shared access is needed. If that shared access level is across multiple modules, the definitions should be defined in a single file (called header files in some languages, such as C) where any changes can be applied once and the change automatically applies to all modules upon compilation or activation;

d. A module is small enough to be easy to follow and understand. Program logic visible on a single page is easy to follow and correct. Volume II, Section 5 provides testing guidelines for the ITA to identify large modules subject to review under this requirement;

e. Each module shall have a single entry point, and a single exit point, for normal process flow. For library modules or languages such as the object-oriented languages, the entry point is to the individual contained module or method invoked. The single exit point is the point where control is returned. At that point, the data that is expected as output must be appropriately set. The exception for the exit point is where a problem is so severe that execution cannot be resumed. In this case, the design must explicitly protect all recorded votes and audit log information and must implement formal exception handlers provided by the language; and Start Printed Page 18968

f. Process flow within the modules shall be restricted to combinations of the control structures defined in Volume II, Section 5. These structures support the modular concept, especially the single entry/exit rule above. They apply to any language feature where program control passes from one activity to the next, such as control scripts, object methods, or sets of executable statements, even though the language itself is not procedural.

4.2.4 Control Constructs

Voting system software shall use the control constructs identified in Volume II, Section 5:

a. Acceptable constructs are Sequence, If-Then-Else, Do-While, Do-Until, Case, and the General loop (including the special case for loop);

b. If the programming language used does not provide these control constructs, the vendor shall provide them (that is, comparable control structure logic). The constructs shall be used consistently throughout the code. No other constructs shall be used to control program logic and execution;

c. While some programming languages do not create programs as linear processes, stepping from an initial condition, through changes, to a conclusion, the program components nonetheless contain procedures (such as “methods” in object-oriented languages). Even in these programming languages, the procedures must execute through these control constructs (or their equivalents, as defined and provided by the vendor); and

d. Operator intervention or logic that evaluates received or stored data shall not re-direct program control within a program routine. Program control may be re-directed within a routine by calling subroutines, procedures, and functions, and by interrupt service routines and exception handlers (due to abnormal error conditions). Do-While (False) constructs and intentional exceptions (used as GoTos) are prohibited.

4.2.5 Naming Conventions

Voting system software shall use the following naming conventions:

a. Object, function, procedure, and variable names shall be chosen so as to enhance the readability and intelligibility of the program. Insofar as possible, names shall be selected so that their parts of speech represent their use, such as nouns to represent objects, verbs to represent functions, etc.;

b. Names used in code and in documentation shall be consistent;

c. Names shall be unique within an application. Names shall differ by more than a single character. All single-character names are forbidden except those for variables used as loop indexes. In large systems where subsystems tend to be developed independently, duplicate names may be used where the scope of the name is unique within the application. Names should always be unique where modules are shared; and

d. Language keywords shall not be used as names of objects, functions, procedures, variables, or in any manner not consistent with the design of the language.

4.2.6 Coding Conventions

Voting system software shall adhere to basic coding conventions. The coding conventions used shall meet one of the following conditions:

a. The vendors shall identify the published, reviewed, and industry-accepted coding conventions used and the ITAs shall test for compliance; or

b. The ITAs shall evaluate the code using the coding convention requirements specified in Volume II, Section 5.

These standards reference conventions that protect the integrity and security of the code, which may be language-specific, and language-independent conventions that significantly contribute to readability and maintainability. Specific style conventions that support economical testing are not binding unless adopted by the vendor.

4.2.7 Comment Conventions

Voting system software shall use the following comment conventions:

a. All modules shall contain headers. For small modules of 10 lines or less, the header may be limited to identification of unit and revision information. Other header information should be included in the small unit headers if not clear from the actual lines of code. Header comments shall provide the following information:

(1) The purpose of the unit and how it works;

(2) Other units called and the calling sequence;

(3) A description of input parameters and outputs;

(4) File references by name and method of access (read, write, modify, append, etc.);

(5) Global variables used; and

(6) Date of creation and a revision record;

b. Descriptive comments shall be provided to identify objects and data types. All variables shall have comments at the point of declaration clearly explaining their use. Where multiple variables that share the same meaning are required, the variables may share the same comment;

c. In-line comments shall be provided to facilitate interpretation of functional operations, tests, and branching;

d. Assembly code shall contain descriptive and informative comments, such that its executable lines can be clearly understood; and

e. All comments shall be formatted in a uniform manner that makes it easy to distinguish them from executable code.

4.3 Data and Document Retention

All systems shall:

a. Maintain the integrity of voting and audit data during an election, and for at least 22 months thereafter, a time sufficient in which to resolve most contested elections and support other activities related to the reconstruction and investigation of a contested election; and

b. Protect against the failure of any data input or storage device at a location controlled by the jurisdiction or its contractors, and against any attempt at improper data entry or retrieval.

4.4 Audit Record Data

Audit trails are essential to ensure the integrity of a voting system. Operational requirements for audit trails are described in Section 2.2.5.2 of the Standards. Audit record data are generated by these procedures. The audit record data in the following subsections are essential to the complete recording of election operations and reporting of the vote tally. This list of audit records may not reflect the design constructs of some systems. Therefore, vendors shall supplement it with information relevant to the operation of their specific systems.

4.4.1 Pre-Election Audit Records

During election definition and ballot preparation, the system shall audit the preparation of the baseline ballot formats and modifications to them, a description of these modifications, and corresponding dates. The log shall include:

a. The allowable number of selections for an office or issue;

b. The combinations of voting patterns permitted or required by the jurisdiction;

c. The inclusion or exclusion of offices or issues as the result of multiple districting within the polling place;

d. Any other characteristics that may be peculiar to the jurisdiction, the election, or the polling place's location;

e. Manual data maintained by election personnel;

f. Samples of all final ballot formats; and Start Printed Page 18969

g. Ballot preparation edit listings.

4.4.2 System Readiness Audit Records

The following minimum requirements apply to system readiness audit records:

a. Prior to the start of ballot counting, a system process shall verify hardware and software status and generate a readiness audit record. This record shall include the identification of the software release, the identification of the election to be processed, and the results of software and hardware diagnostic tests;

b. In the case of systems used at the polling place, the record shall include the polling place's identification;

c. The ballot interpretation logic shall test and record the correct installation of ballot formats on voting devices;

d. The software shall check and record the status of all data paths and memory locations to be used in vote recording to protect against contamination of voting data;

e. Upon the conclusion of the tests, the software shall provide evidence in the audit record that the test data have been expunged;

f. If required and provided, the ballot reader and arithmetic-logic unit shall be evaluated for accuracy, and the system shall record the results. It shall allow the processing, or simulated processing, of sufficient test ballots to provide a statistical estimate of processing accuracy; and

g. For systems that use a public network, provide a report of test ballots that includes:

(1) Number of ballots sent;

(2) When each ballot was sent;

(3) Machine from which each ballot was sent; and

(4) Specific votes or selections contained in the ballot.

4.4.3 In-Process Audit Records

In-process audit records document system operations during diagnostic routines and the casting and tallying of ballots. At a minimum, the in-process audit records shall contain:

a. Machine generated error and exception messages to demonstrate successful recovery. Examples include, but are not necessarily limited to:

(1) The source and disposition of system interrupts resulting in entry into exception handling routines;

(2) All messages generated by exception handlers;

(3) The identification code and number of occurrences for each hardware and software error or failure;

(4) Notification of system login or access errors, file access errors, and physical violations of security as they occur, and a summary record of these events after processing;

(5) Other exception events such as power failures, failure of critical hardware components, data transmission errors, or other type of operating anomaly;

b. Critical system status messages other than informational messages displayed by the system during the course of normal operations. These items include, but are not limited to:

(1) Diagnostic and status messages upon startup;

(2) The “zero totals” check conducted before opening the polling place or counting a precinct centrally;

(3) For paper-based systems, the initiation or termination of card reader and communications equipment operation; and

(4) For DRE machines at controlled voting locations, the event (and time, if available) of activating and casting each ballot (i.e., each voter's transaction as an event). This data can be compared with the public counter for reconciliation purposes;

c. Non-critical status messages that are generated by the machine's data quality monitor or by software and hardware condition monitors; and

d. System generated log of all normal process activity and system events that require operator intervention, so that each operator access can be monitored and access sequence can be constructed.

4.4.4 Vote Tally Data

In addition to the audit requirements described above, other election-related data is essential for reporting results to interested parties, the press, and the voting public, and is vital to verifying an accurate count.

Voting systems shall meet these reporting requirements by providing software capable of obtaining data concerning various aspects of vote counting and producing reports of them on a printer. At a minimum, vote tally data shall include:

a. Number of ballots cast, using each ballot configuration, by tabulator, by precinct, and by political subdivision;

b. Candidate and measure vote totals for each contest, by tabulator;

c. The number of ballots read within each precinct and for additional jurisdictional levels, by configuration, including separate totals for each party in primary elections;

d. Separate accumulation of overvotes and undervotes for each contest, by tabulator, precinct and for additional jurisdictional levels (no overvotes would be indicated for DRE voting devices); and

e. For paper-based systems only, the total number of ballots both processed and unprocessable; and if there are multiple card ballots, the total number of cards read.

For systems that produce an electronic file containing vote tally data, the contents of the file shall include the same minimum data cited above for printed vote tally reports.

4.5 Vote Secrecy (DRE Systems)

All DRE systems shall ensure vote secrecy by:

a. Immediately after the voter chooses to cast his or her ballot, record the voter's selections in the memory to be used for vote counting and audit data (including ballot images), and erase the selections from the display, memory, and all other storage, including all forms of temporary storage; and

b. Immediately after the voter chooses to cancel his or her ballot, erase the selections from the display and all other storage, including buffers and other temporary storage.

Volume I, Section 5

Table of Contents

5 Telecommunications

5.1 Scope

5.1.1 Types of Components

5.1.2 Telecommunications Operations and Providers

5.1.3 Data Transmissions

5.2 Design, Construction, and Maintenance Requirements

5.2.1 Accuracy

5.2.2 Durability

5.2.3 Reliability

5.2.4 Maintainability

5.2.5 Availability

5.2.6 Integrity

5.2.7 Confirmation

5 Telecommunications

5.1 Scope

This section contains the performance, design, and maintenance characteristics of the telecommunications components of voting systems and the acceptable levels of performance against these characteristics. For the purpose of the Standards, telecommunications is defined as the capability to transmit and receive data electronically using hardware and software components over distances both within and external to a polling place.

The requirements in this section represent acceptable levels of combined telecommunications hardware and software function and performance for the transmission of data that is used to operate the system and report election results. Where applicable, this section specifies minimum values for critical performance and functional attributes involving telecommunications hardware and software components. Start Printed Page 18970

This section does not apply to other means of moving data, such as the physical transport of data recorded on paper-based media, or the transport of physical devices, such as memory cards, that store data in electronic form.

Voting systems may include network hardware and software to transfer data among systems. Major network components are local area networks (LANs), wide area networks (WANs), workstations (desktop computers), servers, data, and applications. Workstations include voting stations, precinct tabulation systems, and voting supervisory terminals. Servers include systems that provide registration forms and ballots and accumulate and process voter registrations and cast ballots.

Desirable network characteristics include simplicity, flexibility (especially in routing, to maintain good response times) and maintainability (including availability, provided primarily through redundancy of resources and connections, particularly of connections to public infrastructure).

A wide area network (WAN) public telecommunications component consists of the hardware and software to transport information, over shared, public (i.e., commercial or governmental) circuitry, or among private systems. For voting systems, the telecommunications boundaries are defined as the transport circuitry, on one side of which exists the public telecommunications infrastructure, outside the control of voting system supervisors. On the other side of the transport circuitry are the local area network (LAN) resources, workstations, servers, data and applications controlled by voting system supervisors.

Local area network (LAN) components consist of the hardware and software infrastructure used to transport information between users in a local environment, typically a building or group of buildings. Typically a LAN connects workstations, perhaps with a local server.

An application may be a single program or a group of programs that work together to provide a function to an end user, who may be a voter or an election administrator. Voter programs may include voter registration, balloting, and status checking. Administrator programs may include ballot preparation, registration for preparation, registration approval, ballot vetting, ballot processing, and election processing.

This Section is intended to compliment the network security requirements found in Volume I Section 6, which include requirements for voter and administrator access, availability of network service, data confidentiality, and data integrity. Most importantly, security services will restrict access to local election system components from public resources, and these services will also restrict access to voting system data while it is in transit across public resources. (This is corollary to voting supervisors controlling local election systems and not assuming control over public resources.)

5.1.1 Types of Components

This section addresses telecommunications hardware and software across a broad range of technologies including, but not limited to:

—Dial-up communications technologies:

  • Standard landline;
  • Wireless;
  • Microwave;
  • Very Small Aperture Terminal (VSAT);
  • Integrated Services Digital Network (ISDN); and
  • Digital Subscriber Line (DSL);

—High-speed telecommunications lines (public and private):

  • FT-1, T-1, T-3;
  • Frame Relay; and
  • Private line;

—Cabling technologies:

  • Universal Twisted Pair (UTP) cable (CAT 5 or higher);
  • Ethernet hub/switch; and
  • Wireless connections (Radio Frequency (RF) and Infrared);

—Communications routers;

—Modems, whether internal and external to personal computers, computer servers, and other voting system components (whether installed at the polling place or central count location);

—Modem drivers, dial-up networking software;

—Channel service units (CSU)/Data service units (DSU) (whether installed at the polling place or central count location); and

—Dial-up networking applications software.

5.1.2 Telecommunications Operations and Providers

This section applies to voting-related transmissions over public networks, such as those provided by regional telephone companies and long distance carriers. This section also applies to private networks regardless of whether the network is owned and operated by the election jurisdiction.

For systems that transmit official data over public networks, this Section applies to telecommunications components installed and operated at settings supervised by election officials, such as polling places or central offices. These standards apply to:

  • Components acquired by the jurisdiction for the purpose of voting, including components installed at the poll site or a central office (including central site facilities operated by vendors or contractors); and
  • Components acquired by others (such as school systems, libraries, military installations and other public organizations) that are used at settings supervised by election officials, including minimum configuration components required by the vendor but that the vendor permits to be acquired from third party sources not under the vendor's control (e.g., router or modem card manufacturer or supplier)

5.1.3 Data Transmissions

These requirements apply to the use of telecommunications to transmit data for the preparation of the system for an election, the execution of an election, and the preservation of the system data and audit trails during and following an election. While this section does not assume a specific model of voting system operations and does not assume a specific model for the use of telecommunications to support such operations, it does address the following types of data, where applicable:

  • Voter Authentication: Coded information that confirms the identity of a voter for security purposes for a system that transmits votes individually over a public network;
  • Ballot Definition: Information that describes to a voting machine the content and appearance of the ballots to be used in an election;
  • Vote Transmission: For systems that transmit votes individually over a public network, the transmission of a single vote within a network at a polling place and to the county (or contractor) for consolidation with other county vote data;
  • Vote Count: Information representing the tabulation of votes at any level within the control of the jurisdiction, such as the polling place, precinct, or central count; and
  • List of Voters: A listing of the individual voters who have cast ballots in a specific election.

Additional data transmissions used to operate a voting system in the conduct of an election, but not explicitly listed above, are also subject to the standards of this section.

For systems that transmit data using public networks, this section applies to telecommunications hardware and software for transmissions within and Start Printed Page 18971among all combinations of senders and receivers indicated below:

  • Polling places;
  • Precinct count facilities; and
  • Central count facilities (whether operated by the jurisdiction or a contractor).

5.2 Design, Construction, and Maintenance Requirements

Design, construction, and maintenance requirements for telecommunications represent the operational capability of both system hardware and software. These capabilities shall be considered basic to all data transmissions.

5.2.1 Accuracy

The telecommunications components of all voting systems shall meet the accuracy requirements of Section 3.2.1.

5.2.2 Durability

The telecommunications components of all voting systems shall meet the durability requirements of Section 3.4.2.

5.2.3 Reliability

The telecommunications components of all voting systems shall meet the reliability requirements of Section 3.4.3.

5.2.4 Maintainability

The telecommunications components of all voting systems shall meet the maintainability requirements of Section 3.4.4.

5.2.5 Availability

The telecommunications components of all voting systems shall meet the availability requirements of Section 3.4.5.

5.2.6 Integrity

For WANs using public telecommunications, boundary definition and implementation shall meet the following requirements.

a. Outside service providers and subscribers of such providers shall not be given direct access or control of any resource inside the boundary;

b. Voting system administrators shall not require any type of control of resources outside this boundary. Typically, an end point of a telecommunications circuit will be a subscriber termination on a Digital Service Unit/Customer Service Unit (DSU/CSU) (though the precise technology may vary, being such things as cable modems or routers). Regardless of the technology used, the boundary point must ensure that everything on one side is locally configured and controlled while everything on the other side is controlled by an outside service provider; and

c. The system shall be designed and configured such that it is not vulnerable to a single point of failure in the connection to the public network causing total loss of voting capabilities at any polling place.

5.2.7 Confirmation

Confirmation occurs when the system notifies the user of the successful or unsuccessful completion of the data transmission, where successful completion is defined as accurate receipt of the transmitted data. To provide confirmation, the telecommunications components of a voting system shall:

d. Notify the user of the successful or unsuccessful completion of the data transmission; and

e. In the event of unsuccessful transmission, notify the user of the action to be taken.

Volume I, Section 6

Table of Contents

6  Security

6.0 Security

6.0.1 Security Overview (Informative)

6.0.1.1 Independent Dual Verification Systems (Informative)

6.0.1.2  Core characteristics for Independent Verification Systems (Informative)

6.0.2 Requirements for Voter Verified Paper Audit Trails (Normative)

6.0.2.1 Display and Print a Paper Record

6.0.2.2 VVPAT Voting Station Usability

6.0.2.3 VVPAT Voting Station Accessibility

6.0.2.4 Approve or Spoil the Paper Record

6.0.2.5 Preserve Voter Privacy and Anonymity

6.0.2.6 Electronic and Paper Record Structure

6.0.2.7 Equipment Security, Reliability, and Maintainability

6.0.3 Wireless Requirements (Normative)

6.0.3.1 Relationship to Volume 1, Section 5: “Telecommunications”

6.0.3.2 Controlling Usage

6.0.3.3 Identifying Usage

6.0.3.4 Protecting the Transmitted Data

6.0.3.5 Protecting the Wireless Path

6.0.3.6  Protecting the Voting System From a Wireless-based Attack.

6.0.4 Distribution of Voting System Software and Setup Validation (Normative)

6.0.4.1 Software Distribution Methodology Requirements

6.0.4.2 Generation and Distribution Requirements for Reference Information

6.0.4.3 Setup Validation Methodology Requirements

6.1  Scope

6.1.1 System Components and Sources

6.1.2 Location and Control of Software and Hardware on Which it Operates

6.1.3 Elements of Security Outside Vendor Control

6.1.4 Organization of this Section

6.2 Access Control

6.2.1 Access Control Policy

6.2.1.1 General Access Control Policy

6.2.1.2  Individual Access Privileges

6.2.2  Access Control Measures

6.3  Physical Security Measures

6.3.1 Polling Place Security

6.3.2 Central Count Location Security

6.4 Software Security

6.4.1 Software and Firmware Installation

6.4.2 Protection Against Malicious Software

6.5 Telecommunications and Data Transmission

6.5.1 Access Control

6.5.2 Data Integrity

6.5.3 Data Interception Prevention

6.5.4 Protection Against External Threats

6.5.4.1 Identification of COTS Products

6.5.4.2 Use of Protective Software

6.5.4.3 Monitoring and Responding to External Threats

6.5.5 Shared Operating Environment

6.5.6 Access to Incomplete Election Returns and Interactive Queries

6.6 Security for Transmission of Official Data Over Public Communications Networks

6.6.1 General Security Requirements for Systems Transmitting Data Over Public Networks

6.6.2 Voting Process Security for Casting Individual Ballots Over a Public Telecommunications Network

6.6.2.1 Documentation of Mandatory Security Activities

6.6.2.2 Capabilities to Operate During Interruption of Telecommunications Capabilities

6.0 Security

Section 6.0 addresses four new, specific aspects of voting systems security:

1. Independent Dual Verification Voting Systems: Definition and characteristics of voting systems that produce multiple records of votes. A future version of the VVSG will require that voting systems produce multiple records of ballots or receipts for auditing purposes (Section 6.0.1, Informative).

2. Security Requirements for Voter Verified Paper Audit Trails: Requirements for voter verified paper audit trails, if a State chooses to require them (Section 6.0.2, Normative).

3. Use of Wireless Networking in Voting Systems: Requirements for wireless networks and the data sent across wireless networks (Section 6.0.3, Normative).

4. Security Requirements for Software Distribution and Setup Validation of Voting System: Requirements for (a) the secure distribution of voting systems software and (b) for verifying that voting systems are operating with the correct software configuration (Section 6.0.4, Normative). Start Printed Page 18972

1. Security Overview (Informative)

This section is a discussion of independent verification systems followed by characteristics of independent verification systems which will be used as the basis for future requirements. The characteristics are preliminary and will be evolving with further research.

1. Independent Dual Verification Systems

A primary objective for using electronic voting systems is the production of voting records that are highly precise, highly reliable, and easily counted—in essence, an accurate representation of ballot choices whose handling requirements are reasonable. To meet this objective, there are many factors to consider in an electronic voting system's design, including:

  • The environment provided for voting, including the voting site and various environmental factors,
  • The ease with which voters can use the voting system, i.e., its usability,
  • The robustness and reliability of the voting equipment, and
  • The capability of the records to be used in audits.

Independent Dual Verification (IDV) systems have as their primary objective the production of ballot records that are capable of being used in audits in which their correctness can be audited to very high levels of precision. The primary security issues addressed by IDV systems are:

  • Whether electronic voting systems are accurately recording ballot choices, and
  • Whether the ballot record contents can be audited precisely post-election.

The threats addressed by IDV systems are those that could cause a voting system to inaccurately record the voter's intent or cause a voting system's records to become damaged, i.e., inserted, deleted, or changed. These threats could occur via any number of means including accidental damage or various forms of fraud. The threats are addressed mainly by providing, in the voting system design, the capability for ballot record audits to detect precisely whether specific records are correct as recorded or damaged, missing, or fraudulent.

1.1 Independent Dual Verification Systems: Improved Accuracy in Audits

Independent Verification is the top-level categorization for electronic voting systems that produce multiple records of ballot choices whose contents are capable of being audited to high levels of precision. For this to happen, the records must be produced and made verifiable by the voter, and then subsequently handled according to the following protocol:

  • At least two records of the voter's choices are produced and one of the records is then stored such that it cannot be modified by the voting system, e.g. the voting system creates a record of the voter's choices and then copies it to some write-once media.
  • The voter must be able to verify that both records are correct, e.g., verify his or her choices on the voting system's display and also verify the second record of choices stored on the write-once media.
  • The verification processes for the two verifications must be independent of each other and (a) at least one of the records must be verified directly by the voter, or (b) it is acceptable for the voter to indirectly verify both records if they are stored on different systems produced by different vendors.
  • The content of the two records can be checked later for consistency through the use of identifiers that allow the records to be linked.

An assumption is made that at least one set of records is usable in an efficient counting process such as by using an electronic voting system, and the other set of records is usable in an efficient process of verifying its agreement with the other set of records used in the counting process. The sets of records would preferentially be different in form and thus have more resistance to accidental or deliberate damage.

Given these conditions above, the multiple records are said to be distinct and independently verifiable, that is, both records are not under the control of the same processes. As a result of this independence, one record can be used to audit or check up on the accuracy of the other record. Because the storage of the records is separate, an attacker who can compromise one of the records still will face a difficult task in compromising the other.

1.2  Issues in Handling Multiple Records Produced by Independent Dual Verification Systems

There are several fundamental questions that need to be addressed when designing the structure and selecting the physical characteristics of IDV systems records, including:

  • How to tell if the records are authentic and not forged,
  • How to tell if the integrity of the records has remained intact from the time they were recorded,
  • The suitability of the records for various types of auditing, and
  • How best to address problems if there are errors in the records.

Whenever an electronic voting system produces multiple records of votes, there is some possibility that one or more of the records may not match. Records can be lost, or deliberately or accidentally damaged, or stolen, or fabricated. Keeping the two records in correspondence with each other can be made more or less difficult depending on the technologies used for the records and the procedures used to handle the records.

As a consequence, it is important to structure the records so that errors and other anomalies can be readily detected during audits. There are a number of techniques that can be used, such as the following:

  • Associating unique identifiers with corresponding records, e.g., an individual paper record sharing a unique identifier with its corresponding electronic record,
  • Including an identification of the specific voting system that produced the records, such as a serial number identifier or by having the voting system digitally sign the records using public key cryptography,
  • Including other information about the election and the precinct or location where the records were created,
  • Creating checksums of the electronic records and having the voting system digitally sign the entire sets of records so that missing or inserted records can be detected, and
  • Structuring the records in open, publicly documented formats that can be readily analyzed on different computing platforms.

The ease or relative difficulty with which some types of records must be handled is also a determining factor in the practical capability to conduct precise audits, given that some types of records are better suited to different types of auditing and different voting environments than others. The factors that make certain types of records more suitable than others could vary greatly depending upon many other criteria, both objective and subjective. For example, paper records may require manual handling by voters or poll workers and thus be more susceptible to damage or loss. At the same time, the extent to which the paper records must be handled will vary depending on the type of voting system in use. Electronic records may by their nature be more suitable for automated audits; however electronic records are still subject to accidental or deliberate damage, loss, and theft. Start Printed Page 18973

2. Core Characteristics for Independent Verification Systems

This section contains a preliminary set of characteristics for IDV systems. These characteristics are fundamental in nature and apply to all categories of IDV systems. They will form the basis for future requirements for independent verification systems.

2.1 An Independent Dual Verification Voting System Produces Two Distinct Sets of Records of Ballot Choices Via Interactions With the Voter Such That One Set of Records Can be Compared Against the Other to Check Their Equality of Content

Discussion: This is the fundamental core definition for IDV systems. The records can be checked against one another to determine whether or not the voter's choices were correctly recorded.

2.1.1 The Voter Verifies the Content of Each Record and Either (a) Verifies at Least One of the Records Directly or (b) Verifies Both Records Indirectly if the Records Are Each Under the Control of Independent Processes

Discussion: Direct Verification involves using human senses, e.g., directly verifying a paper record via one's eyesight. Indirect Verification involves using an intermediary to perform the verification, e.g., verifying an electronic ballot image at the voting system.

2.1.2 The Creation, Storage, and Handling of the Records are Sufficiently Separate Such That the Failure or Compromise of One Record Does Not Cause the Failure or Compromise of Another

Discussion: The records must be stored on different media and handled independently of each other, so that no one process could compromise all records. If an attack can alter one record, it should still be very difficult to alter the other record.

2.1.2.1 At Least One Record Is Highly Resistant to Damage or Alteration and Should be Capable of Long-Term Storage

Discussion: At least one of the records should be difficult to alter or damage so that it could be used in case the counted records are damaged or lost.

2.1.3 The Processes of Verification for the Multiple Records do not all Depend for Their Integrity on the Same Device, Software Module, or System, and are Sufficiently Separate Such That Each Record Provides Evidence of the Voter's Choices Independently of Its Other Corresponding Record

Discussion: For example, the verification of an electronic record on a DRE is not sufficiently separate from the verification of an electronic record located on a token but performed by the same DRE as the verification for the first record. Verification of the paper record by one's senses is sufficiently separate in this case.

2.1.4 The Records Can Be Used in Checks of One Another, Such That if One Set of Records Can Be Used in an Efficient Counting Process, the Other Set of Records Can Be Used for Checking Its Agreement With the First Set of Records

Discussion: For example, an electronic record can be used in an efficient counting process. A second paper record can be used to verify the accuracy of the electronic record; however its suitability for efficient counting is less clear. If a paper record can be used in an automated scan process, it may be more suitable.

2.1.5 The Records Within a Set are Linked to Their Corresponding Records in the Other Set by Including a Unique Identifier Within Each Record That Can Be Used to Identify the Record's Corresponding Record in the Other Set

Discussion: The identifier should serve the purpose of uniquely identify the record so as to identify duplicates and/or for cross-checking two record types.

2.1.6 Each Record Includes an Identification of the Voting Site/Precinct

Discussion: If the voting site and precinct are different, both should be included.

2.1.7  The Records Include Information Identifying Whether the Balloting is Provisional, Early, or on Election Day, and Information That Identifies the Ballot Style In Use

2.1.8  The Records Include a Voting Session Identifier that is Generated When The Voting Station is Placed in Voting Mode and That Can Be Used to Identify The Records as Being Created During That Voting Session

Discussion: If there are several voting sessions on the same voting station on the same day, the voting session identifiers must be different. They should be generated from a random number generator.

2.1.9 The Records Include An Identifier of The Voting System that is Unique To that Style of Voting Systems

Discussion: The identifier could be a serial number or other unique ID. Start Printed Page 18974

2.1.10 The cryptographic Software in Independent Verification Voting Systems is Approved by The U.S. Government's Cryptographic Module Validation Program (CMVP) as Applicable

Discussion: The voting systems may use cryptographic software for a number of different purposes, including calculating checksums, encrypting records, authentication, generating random numbers, and for digital signatures. This software should be reviewed and approved by the Cryptographic Module Validation Program. There may be cryptographic voting schemes where the cryptographic algorithms used are necessarily different from any algorithms that have approved CMVP implementations, thus CMVP approved software shall be used where feasible. The CMVP web site is http://csrc.nist.gov/​cryptval.

2. Requirements for Voter Verified Paper Audit Trails (Normative)

This section contains requirements for Voter Verified Paper Audit Trail (VVPAT) voting systems. VVPAT is not mandatory. These requirements apply only to voting systems that include a VVPAT component and are consistent with the definition of Independent Dual Verification (IDV) systems from Section 6.0.1. Requirements for usability, accessibility, and privacy from Volume I, Section 2.2.7 apply to VVPAT. The requirements in this section apply only to VVPAT systems; the requirements do not apply to other types of voting systems and are not intended to in any way restrict use or operation of other types of voting systems.

1. Display and Print a Paper Record

1.1 The Voting Station Shall Print and Display a Paper Record of the Voter's Ballot Choices Prior to the Voter Making the Ballot Choices Final

Discussion: This is the basic requirement for VVPAT capability. It requires that the paper record be created as a distinct representation of the voter's ballot choices. It requires that the paper record contain the same information as contained in the electronic record and be suitable for use in verifications and recounts of the election and of the voting station's electronic records. Thus, either the paper or electronic record could be used as the ballot of record for the election.

1.1.1 The Paper Record Shall Constitute A Complete Record of Ballot Choices That Can Be Used To Assess The Accuracy of The Voting Station's Electronic Record, To Verify The Election Results, And In Full Recounts.

Discussion: This requirement exists to make clear that it is possible to use the paper record for checks of the voting station's accuracy in recording voter's ballot choices, as well as usable for election audits (such as mandatory 1% recounts). The paper record shall also be suitable for use in full manual recounts of the election.

1.1.2 The Paper Record Shall Contain All Information Stored in the Electronic Record

Discussion: The electronic record cannot hide any information related to ballot choices; all information relating to ballot choices must be equally present in both records. The electronic record may contain other items that don't necessarily need to be on the paper record, such as digital signature information.

2. VVPAT Voting Station Usability

2.1 All Usability Requirements From Volume I, Section 2.2.7 Shall Apply to Voting Stations With VVPAT

Discussion: The requirements in this section are in addition to those requirements from Section 2.2.7. They require that the paper record be formatted and displayed so that the voter is able to verify his or her votes with maximum reasonable ease and satisfaction, and that instructions be provided to the voter to handle all relevant aspects of the voter verification.

2.1.1 The Voting Station Shall Be Capable of Showing the Information on the Paper in a Font Size of at Least 3.0 mm, and Should Be Capable of Showing the Information in at Least Two Font Ranges, (a) 3.0-4.0 mm and (b) 6.3-9.0 mm, Under Control of the Voter or Poll Worker

Discussion: In keeping with requirements in Section 2.2.7, the paper record should use the same font sizes as displayed by the voting station, but at least be capable of 3.0 mm. While larger font sizes may assist most voters with poor vision, certain disabilities such as tunnel vision are best addressed by smaller font sizes.

2.1.2 The Paper and Electronic Records Shall Be Presented so as to Allow for Easy, Simultaneous Comparison

2.1.2.1 The Paper and Electronic Records Shall Be Positioned so That the Voter Can, at the Same Posture, Easily Read and Compare the Two Records

Discussion: The voter should not have to shift positions when comparing the records.

2.1.2.2 If The Paper Record Cannot Be Displayed in Its Entirety, a Means Shall Be Provided to Allow the Voter to View the Entire Ballot

Discussion: Possible solutions include scrolling the paper or printing a new sheet of paper.

2.1.2.3 If the Paper Record Cannot Be Displayed in Its Entirety on a Single Page, Each Page of the Record Shall Be Numbered and the Last Page Shall Be Clearly Distinguished

Start Printed Page 18975

2.1.3 The Instructions for Performing the Verification Process Shall Be Made Available to the Voter in A Location on the Voting Station

Discussion: All instructions need to meet the accessibility requirements contained in Section 2.2.7.

3. VVPAT Voting Station Accessibility

3.1 All Accessibility Requirements From Section 2.2.7 Shall Apply to Voting Stations With VVPAT

Discussion: Requirements in this section are in addition to the accessibility and alternative language requirements from Section 2.2.7. They make explicit that an accessible vote verification procedure for voters be provided at voting sites, including voters with disabilities, limited English proficiency (LEP), and voters with Native American and Alaska Native languages that are not written.

3.1.1 The Voting Station Shall Display, Print, and Store a Paper Record in any of the Alternative Languages Chosen for Making Ballot Selections

Discussion: For the purposes of voter privacy, it must not be possible to identify voters based on their use of alternative languages. Requirement 6.0.2.5.1.3 addresses this issue.

3.1.1.1 For the Purposes of Verification, Candidate Names on the Records Shall Be in English

Discussion: This requirement is included to assist manual auditing of the paper records.

3.1.1.2 Other Markings Not Related to Ballot Selection on The Paper Record Shall Be In English

Discussion: Other markings may include designations of the precinct and the election.

3.1.2 If the Normal Procedure Includes VVPAT, the Accessible Voting Station Should Provide Features That Enable Voters Who Are Blind to Perform This Verification

Discussion: This requirement is repeated from Section 2.2.7 and included here for emphasis. This requirement will be mandatory in future versions.

4. Approve or Spoil the Paper Record

4.1 The Voting Station Shall Allow the Voter to Approve or Spoil the Paper Record

Discussion: The voting station cannot create an electronic record without its corresponding paper record. It requires that the voting station mark the electronic record as accepted or spoiled in the voter's presence, and if spoiled, the corresponding electronic record be marked as spoiled and be preserved. It requires that the voting station display a warning message when a spoil limit is reached.

4.1.1 The Voting Station Shall, in the Presence of The Voter, Mark the Paper Record as Being Accepted by the Voter or Spoiled

Discussion: If a paper record is marked as spoiled, then the corresponding electronic record is presented to the voter for update.

4.1.2 The Voting Station Should Mark and Preserve Electronic and Paper Records That Have Been Spoiled

Discussion: For the purposes of reconciliation of records, electronic and paper spoiled records should be retained and analyzed.

4.1.3 Following the Close of Polls, a Means Shall Be Provided to Reconcile the Number of Spoiled Paper Records With the Number of Occurrences of Spoiled Electronic Records, and Procedures Shall Be in Place to Address Any Discrepancies

[Best practice for voting officials] Appropriate procedures are needed for reconciling the number of spoiled paper records with the number of spoiled electronic records and for addressing any discrepancies after the close of polls.

4.1.4 Prior to the Maximum Number of Spoiled Ballots Occurring, the Voting Station Shall Display a Warning Message to the Voter Indicating That the Voter May Spoil Only One More Ballot

Discussion: The maximum number of spoiled ballots varies from state to state.

4.1.5 If the Maximum Number of Spoiled Ballots Occurs, the Voting Station Should Provide a Way to Permit the Voter to Cast a Ballot, as Required

Discussion: Possible solutions include using other equipment, using a paper ballot, or accepting the last ballot cast. This capability defined by state and local jurisdiction.

[Best practice for voting officials] Appropriate procedures are needed to permit the voter to cast a ballot if the maximum number of spoiled ballots occurs.

[Best practice for voting officials] Appropriate procedures are needed to address situations in which a voter is unable to review the paper record.

[Best practice for voting officials] Appropriate procedures are needed to address situations in which a voter indicates that the electronic and paper records do not match. If the records do not match, a potentially serious error has likely occurred, and voting officials may need to take appropriate actions such as removing the voting station from service and quarantining its records for later analysis. Start Printed Page 18976

4.1.6 The Voting Station Should Not Record the Electronic Record as Being Approved By The Voter Until the Paper Record Has Been Stored

Discussion: In general it is better not to record any record as being approved until the record that is independent of the voting system is approved by the voter.

4.1.7 Vendor Documentation Shall Include Procedures for Returning a Voting Station to Correct Operation After a Voter Has Used It Incompletely or Incorrectly; This Procedure Shall Not Cause Discrepancies Between the Tallies of the Electronic and Paper Records

5. Preserve Voter Privacy and Anonymity

5.1 The Voter's Privacy and Anonymity Shall be Preserved During the Process of Recording, Verifying, and Auditing Ballot Choices

Discussion: Privacy requirements from Section 2.2.7 apply to voting stations with VVPAT; requirements in this section are in addition to those requirements from Section 2.2.7. They require that the voter's privacy be maintained during the verification step, including requirements that the paper record contain no human or machine-readable markings that could identify the voter and that the paper and electronic records be stored in ways that preserve the privacy and anonymity of the voter.

5.1.1 The Privacy and Anonymity of the Voter's Verification of His or Her Ballot Choices on the Electronic and Paper Records Shall Be Maintained

5.1.1.1 When the Voter is Responsible for Depositing a Paper Record in the Ballot Box, the Accessible Voting Station Shall Maintain the Privacy and Anonymity of Voters Unable to Manually Handle Paper

5.1.2 The Electronic and Paper Records Shall be Created and Stored in Ways that Preserve the Privacy and Anonymity of the Voter

Discussion: This can be accomplished in various ways including shuffling the order of the records or other methods to separate the order of stored records.

5.1.3 The Privacy and Anonymity of Voters Whose Paper Records Contain Any of the Alternative Languages Chosen for Making Ballot Selections Shall be Maintained

Discussion: One method for accomplishing this is to ensure that no less than, e.g., five voters use any of the alternative languages for their ballot selections.

[Best practice for voting officials] Appropriate procedures are needed to ensure the privacy and anonymity of voters whose paper records contain any of the alternative languages chosen for making ballot selections.

5.1.4 The Voter Shall Not be Able to Leave the Voting Area With the Paper Record if the Information on the Paper Record Can Directly Reveal the Voter's Choices

[Best practice for voting officials] Appropriate procedures are needed to prevent voters from leaving the voting area with a paper record that can directly reveal the voter's choices.

5.1.5 Unique Identifiers Shall Not be Displayed in a Way That Is Easily Memorable by the Voter

Discussion: Unique identifiers on the paper record are displayed or formatted in such a way that they are not memorable to voters, such as by obscuring them in other characters.

6. Electronic and Paper Record Structure

6.1 The Voting Station's Ballot Records Shall Be Structured and Contain Information So as to Support Highly Precise Audits of Their Accuracy

Discussion: It requires that electronic records and paper records contain election precinct information, information to link the paper record to its corresponding electronic record, and information identifying the voting station. It requires that the electronic records be maintained in a format that can be exported to a different computer, e.g., a personal computer, and that the format be well-documented to support analysis of the records.

6.1.1 All Cryptographic Software in the Voting Station Should be Approved by the U.S. Government's Cryptographic Module Validation Program (CMVP) as Applicable

Discussion: The voting station may use cryptographic software for a number of different purposes, including calculating checksums, encrypting records, authentication, generating random numbers, and for digital signatures. This software should be reviewed and approved by the Cryptographic Module Validation Program. There may be cryptographic voting schemes where the cryptographic algorithms used are necessarily different from any algorithms that have approved CMVP implementations, thus CMVP approved software should be used where feasible but is not required. The CMVP web site is http://csrc.nist.gov/​cryptval. Start Printed Page 18977

6.1.2 The Electronic and Paper Records Shall Include Information About the Election

6.1.2.1 The Voting Station Shall be Able to Include an Identification of the Particular Election, the Voting Site/Precinct, and the Voting Station

Discussion: If the voting site and precinct are different, both should be included. Some of this information may have to be excluded in certain cases to protect voter privacy.

6.1.2.2 The Records Shall Include Information Identifying Whether the Balloting is Provisional, Early, or on Election Day, and Information that Identifies the Ballot Style in Use

6.1.2.3 The Records Shall Include a Voting Session Identifier That is Generated When the Voting Station is Placed in Voting Mode and That can be Used to Identify the Records as Being Created During that Voting Session

Discussion: If there are several voting sessions on the same voting station on the same day, the voting session identifiers must be different. They should be generated from a random number generator.

6.1.3 The Electronic and Paper Records Shall be Linked by Including a Unique Identifier Within Each Record That can be Used to Identify Each Record Uniquely and Each Record's Corresponding Record

Discussion: The identifier serves the purpose of uniquely identifying the record so as to identify duplicates and/or for crosschecking two record types.

6.1.4 The Voting Station Should Generate and Store a Digital Signature for Each Electronic Record

6.1.5 The Electronic Records Shall be Able to be Exported for Auditing or Analysis on Standards Based and/or COTS Information Technology Computing Platforms

6.1.5.1 The Exported Electronic Records Shall be in a Publicly Available, Non-Proprietary Format

Discussion: It is advantageous when all electronic records, regardless of manufacture, use the same format or can easily be converted to a publicly available, non-proprietary format, e.g., the OASIS Election Markup Language (EML) Standard.

6.1.5.2 The Voting Station Should Export the Records Accompanied by a Digital Signature of the Collection of Records, Which Shall be Calculated on the Entire Set of Electronic Records and Their Associated Digital Signatures

Discussion: This is necessary to determine if records are missing or substituted.

6.1.5.3 The Voting System Vendor Shall Provide Documentation as to the Structure of the Exported Records and How They Shall be Read and Processed by Software

6.1.5.4 The Voting System Vendor Shall Provide a Software Program That Will Display the Exported Records and That May Include Other Capabilities Such as Providing Vote Tallies and Indications of Undervotes

6.1.6 The Paper Record Should be Created in a Format That May be Made Available Across Different Manufacturers of Electronic Voting Systems

Discussion: Future standards may require some commonality in the format of paper records.

6.1.7 The Paper Record Shall be Created Such That Its Contents Are Machine-Readable

Discussion: This can be done by using specific OCR fonts.

6.1.7.1 The Paper Record Should Contain Error Correcting Codes for the Purposes of Detecting Read Errors and for Preventing Other Markings on the Paper Record to be Misinterpreted When Machine Reading the Paper Record

Discussion: This requirement is not mandatory if, for example, a state prohibits non-human-readable information on the paper record. This requirement serves the purpose of detecting scanning errors and preventing stray or deliberate markings on the paper from being interpreted as valid data.

6.1.8 Any Automatic Accumulation of Electronic or Paper Records Shall be Capable of Detecting and Discarding Duplicate Copies of the Records

Start Printed Page 18978

6.1.9 The Voting Station Should be Able to Print a Barcode With Each Paper Record that Contain the Human Readable Contents of the Paper Record and Digital Signature Information

Discussion: This requirement is not mandatory if, for example, a state prohibits non-human-readable information on the paper record.

6.1.9.1 The Barcode Shall Use an Industry-Standard Format and Shall be Able to be Read Using Readily Available Commercial Technology

Discussion: Examples of such codes are Maxi Code or PDF417.

6.1.9.2 If the Paper Record's Corresponding Electronic Record Contains a Digital Signature, the Digital Signature Shall be Included in the Barcode

6.1.9.3 The Barcode Shall Not Contain Any Information Other Than the Paper Record's Human Readable Content and Digital Signature Information

6.1.10 The Voting System Vendor Shall Provide Full Documentation of Procedures for Exporting Its Electronic Records and Reconciling Its Electronic Records With Its Paper Records

7. Equipment Security and Reliability

7.1 The Voting Station Equipment Shall be Secure, Reliable, and Easily Maintained

7.1.1 The Voting Station Shall be Physically Secure From Tampering, Including Intentional Damage

[Best practice for voting officials] Appropriate procedures are needed to ensure that voting systems are physically secured from tampering and intentional damage.

7.1.1.1 The Voting Station Shall Provide a Standard, Publicly Documented Printer Port (or the Equivalent) Using a Standard Communication Protocol

Discussion: Using a standard, publicly documented printer protocol assists in security evaluations of its software.

7.1.1.2 The Paper Path Between the Printing, Viewing and Storage of The Paper Record Shall be Protected and Sealed From Access Except by Authorized Election Officials

7.1.1.3 The Printer Shall Not be Permitted to Communicate With Any Other System or Machine Other Than the Single Voting Machine to Which it is Connected

7.1.1.4 The Printer Shall Only be Able to Function as a Printer; It Shall Not Contain Any Other Services (e.g., Provide Copier or Fax Functions) or Network Capability

7.1.1.5 Printer Access to Replace Consumables Such as Ink or Paper Shall Only be Possible if it Does Not Compromise the Sealed Printer Paper Path

7.1.1.6 The Ballot Box Storing the Paper Records Shall be Sealed and Secured and No Access Shall be Provided to Poll Workers

7.1.1.7 Tamper-Evident Seals or Physical Security Measures Shall Protect the Connection Between the Printer and the Voting Station, so that the Connection Cannot be Broken or Interfered With Without Leaving Extensive and Obvious Evidence

7.1.2 The Voting Station's Printer Shall be Highly Reliable and Easily Maintained

7.1.2.1 The Voting Station Should Detect Errors and Malfunctions such as Paper Jams or Low Supplies of Consumables such as Paper and Ink That May Prevent Paper Records from Being Correctly Displayed Printed or Stored

Discussion: This could be accomplished in a variety of different ways: for example, a printer that is out of paper or jammed could issue audible alarms, with the alarm different for each condition. Start Printed Page 18979

7.1.2.2 If Errors or Malfunctions Occur, the Voting Station Shall Suspend Voting Operations and Should Present a Clear Indication to The Voter and Election Officials of the Malfunctions

Discussion: The voting station does not record votes if errors or malfunctions occur.

7.1.2.3 Printing Devices Should Either (a) Contain Paper and Ink of Sufficient Capacity so as not to Require Reloading or Opening Equipment Covers or Enclosures and Circumvention of Security Features, or (b) Be Able to Reload Paper and Ink with Minimal Disruption to Voting and Without Circumvention of Security Features such as Seals

7.1.2.4 Vendor Documentation Shall Include Procedures for Investigating and Resolving Printer Malfunctions Including but Not Limited to Printer Operations, Misreporting of Votes, Unreadable Paper Records, and Power Failures

7.1.2.5 Vendor Documentation Shall Include Printer Reliability Information Including Mean Time Between Failure Information and Shall Include Recommendations for Appropriate Numbers of Backup Printer and Printer Supplies

7.1.3 Protective Coverings Intended to be Transparent on Voting Station Devices Shall be Maintainable via a Predefined Cleaning Process. If The Coverings Become Damaged Such That They Obscure the Paper Record, They Shall be Replaceable

7.1.4 The Paper Record Shall be Sturdy, Clean, and of Sufficient Durability to be Used for Verifications, Reconciliations, and Recounts Conducted Manually and via Machine Reading Equipment

3. Wireless Requirements (Normative)

This section provides wireless requirements for implementing and using wireless capabilities within a voting system. These requirements reduce, but don't eliminate, the risk of using wireless communications for voting systems.

Wireless is defined as any means of communication that occurs without wires. This normally covers the entire electromagnetic spectrum. For the purposes of this section wireless includes radio frequency (RF), infrared, (IR), and microwave.

Since the wireless communications path on which the signals travel is via the air and not via a wire or cable, devices other than those intended to receive the wireless signal (e.g., voting data) can receive (intentionally and unintentionally) the wireless signals. Some of the wireless communications paths (i.e., signals) are weakened by walls and distance, but are not stopped. This makes it possible to eavesdrop from a distance as well as transmit wireless signals (e.g., interference or intrusive data) from a distance. In many cases the wireless signals cannot be seen, heard, or felt, thus making the presence of wireless communication hard to determine by the human senses. The use of wireless technology introduces severe risk and should be approached with extreme caution. The requirements in this section (i.e., controlling and identifying usage, protecting the transmitted data and path, and protecting the system) mitigate these risks.

The requirements that are applicable to all types of wireless communications are presented, followed by requirements that are applicable to a specific part of the electromagnetic spectrum (e.g., audible, radio frequency, and infrared). These latter requirements only apply to systems using those parts of the spectrum.

There are other concerns when evaluating wireless usage, specifically radio frequency. A device's radio frequencies usage and the power output are governed by Federal Communications Commission (FCC) regulations and therefore all RF wireless communications devices are subject to the applicable FCC requirements. However, these FCC regulations do not fully address RF wireless interference caused by multiple FCC compliant devices. That is, the RF wireless used in a voting system may be using the same RF wireless of another non-voting wireless system and which may potentially cause a degradation of the wireless performance or a complete wireless failure for the voting system. Sometimes a particular wireless technology permits a power output range, which may be used to overcome interference received from another device. A radio emissions site test can determine the extent of potential existing interference at the location where the wireless voting system is to be used. A radio emission site test can also determine the extent that the RF wireless transmission of the voting system escapes the building in which the RF wireless voting system is used.

1. Relationship to Volume I, Section 5: “Telecommunications”

1.1 At a Minimum Wireless Communications Shall Meet the Requirements Listed in Volume I, Section 5, “Telecommunications”

2. Controlling Usage

2.1 If Wireless Communications Are Used in a Voting System, Then the Vendor Shall Supply Documentation Describing How to Use All Aspects of Wireless Communications in a Secure Manner

2.1.1 This documentation shall include:

  • A complete description of the uses of wireless in the voting system including descriptions of the data elements and signals that are to be carried by the wireless mechanism,
  • A complete description of the vulnerabilities associated with this proposed use of wireless, including vulnerabilities deriving from the insertion, deletion, modification, capture, or suppression of wireless messages,
  • A complete description of the techniques used to mitigate the risks associated with the described Start Printed Page 18980vulnerabilities including techniques used by the vendor to ensure that wireless cannot send or receive messages other than those situations specified in the documentation. Cryptographic techniques shall be carefully and fully described, including a description of cryptographic key generation, management, use, certification, and destruction, and
  • A rationale for the inclusion of wireless in the proposed voting system, based on a careful and complete description of the perceived advantages and disadvantages of using wireless for the documented uses compared to using non-wireless approaches.

Discussion: In general, convenience is not a sufficiently compelling reason, on its own, to justify the inclusion of wireless communications in a voting system. If convenience is cited as an advantage of wireless, it shall be balanced against the difficulty of working with cryptographic keys.

[Best Practice for Voting Officials] When using encryption to ensure that the wireless communication is secure, appropriate procedures are needed for cryptographic key management.

2.1.2 The Details of All Cryptographic Protocols Used for Wireless Communications, Including the Specific Features and Data, Shall be Documented

2.1.3 The Wireless Documentation Shall be Closely Reviewed for Accuracy, Completeness, and Correctness

2.1.3.1 This Review Shall be Done Either Through an Open and Public Review or by a Subject Area Recognized Expert

2.1.4 There Shall be No Undocumented Use of the Wireless Capability, Nor Shall There be Any Use of the Wireless Capability That Is Not Entirely Controlled by the Voting Official

Discussion: This can be tested by reviewing all of the software, hardware, and documentation and by testing the status of wireless activity during all phases of testing.

2.2 If a Voting System Includes Wireless Capabilities, Then the Voting System Should be Able to Accomplish the Same Function if Wireless Capabilities are Not Available Due to an Error or No Service

2.2.1 The Vendor Shall Provide Documentation How to Accomplish These Functions When Wireless Is Not Available

2.3 The System Shall be Designed and Configured Such That it Is Not Vulnerable to a Single Point of Failure Using Wireless Communications That Causes a Total Loss of Any of Voting Capabilities

Discussion: Rewritten from Volume 1, Section 5.2.6 Integrity item (c)

2.4 If a Voting System Includes Wireless Capabilities, Then the System Shall Have the Ability to Turn on the Wireless Capability When it is to be Used and to Turn Off the Wireless Capability When the Wireless Capability is Not in Use

2.5 If a Voting System Includes Wireless Capabilities, Then the System Shall Not Activate the Wireless Capabilities without Confirmation From a Voting Official

3. Identifying Usage

Since there are a wide variety of wireless technologies (both standard and proprietary) and differing physical properties of wireless signals, it is important to identify some of the characteristics of the wireless technologies used in the voting system

3.1 If a Voting System Provides Wireless Communications Capabilities, Then There Shall be a Method for Determining the Existence of the Wireless Communications Capabilities

3.2 If a Voting System Provides Wireless Communications Capabilities, Then There Shall be An Indication that Allows One to Determine When the Wireless Communications (e.g., Radio Frequencies) Capability is Active

3.2.1 The Indication Should be Visual

3.3 If a Voting System Provides Wireless Communications Capabilities, Then the Type of Wireless Communications Used (e.g., Radio Frequencies) Shall be Identified Either via a Label or via the Voting Systems Documentation

4. Protecting the Transmitted Data

The transmitted data, especially via wireless communications, needs to be protected to ensure confidentiality and integrity. Examples of election information that needs to be protected Start Printed Page 18981include: ballot definitions, ballot instructions (audio), voting device counts, precinct counts, opening of poll signal, and closing of poll signal.

Examples of non—specific election information that needs to be protected include: Protocol messages, address or device identification information, and passwords.

Since radio frequency wireless signals radiate in all directions and pass through most construction material, anyone may easily receive the wireless signals. In contrast, infrared signals are line of sight and do not pass through most construction materials. However to a lesser extent, infrared signals can still be received by other devices that are in the line of sight. Similarly, wireless signals can also be easily transmitted by others in order to create unwanted signals. Thus to protect the privacy and confidentiality of the information, encryption is required. The following requirements are rewritten from Volume I, Section 6.5.3.

4.1 All Information Transmitted via Wireless Communications Shall be Encrypted and Authenticated, with the Exception of Wireless T-Coil Coupling, to Protect Against Eavesdropping and Data Manipulation Including Modification, Insertion, and Deletion

4.1.1 The Encryption Shall be as Defined in Federal Information Processing Standards (FIPS) 197, “Advanced Encryption Standard (AES)”

4.1.1.1 The Cryptographic Modules Used Shall Comply With FIPS 140-2, Security Requirements for Cryptographic Modules

4.1.2 The Capability to Transmit Non-Encrypted and Non-Authenticated Information via Wireless Communications Shall Not Exist

4.1.2.1 If Wireless Communication (Audible) is Used, and if the Receiver of the Wireless Transmission is the Human Ear, then the Information Shall Not be Encrypted (i.e., This Specifically Covers the Case of the Wireless T-Coil Coupling for Assistive Devices Used by People Who are Hard of Hearing—See Volume I, Section 2.2.7.2 DRE Standards Item C)

5. Protecting the Wireless Path

With the exception of wireless communications using audible and infrared, it is technically infeasible to use physical means to prevent denial of service (DoS) attacks. If wireless communications are used, then the following capabilities shall exist in order to mitigate the effects of a denial of service (DoS) attack:

5.1 The Voting System Shall be Able to Function Properly Throughout a DoS Attack, Since the DoS Attack May Continue Throughout the Voting Process.

5.2 The Voting System Shall Function Properly as if the Wireless Capability Were Never Available for Use

5.3 Alternative Procedures or Capabilities Shall Exist to Accomplish the Same Functions That the Wireless Communications Capability Would Have Done

5.4 The Wireless (Audible) Path Shall be Protected or Shielded

Discussion: Protecting the audible path is a tradeoff between the high volume level necessary for an individual to hear with the low volume level necessary to keep others from hearing, as well as protecting from interference (i.e., noise) from the polling place, voting station, or voting environment. The same is true for the audible path if a voter's speech is to be captured by the voting device. This wireless communication's path protection is necessary to protect privacy. Some audio headsets may already satisfy this requirement for the hearing part, while a soundproof voting booth may be necessary in some other cases (e.g., voice recordings).

5.5 Infrared

Since infrared has the line-of-sight (LoS) property, securing the wireless path can be accomplished by shielding the path between the wireless communicating devices with an opaque enclosure. However this is only practical for short distances. Additionally, this type of shielding can help to prevent accidental damage to the eyes by the infrared signal.

5.5.1 The Shielding Shall be Strong Enough to Prevent Escape of the Voting System's Signal, as well as Strong Enough to Prevent Infrared Saturation Jamming

6. Protecting the Voting System from a Wireless-based Attack

The security of the wireless voting systems is as important as the information transmitted. If a voting system becomes compromised, there is no way to determine the harm to the system until the compromise is discovered and an investigation is conducted to determine the extent of the damage.

Physical security measures (Volume I, Section 6.3) to prohibit access to a voting system are not possible when using a wireless communications interface. This is similar to when access is through a telecommunications interface, but it is worsened by the fact that there is no wire (physical communication path) to physically secure and by the various physical properties of the electromagnetic spectrum used.

This section covers and reaffirms the applicable overall system capabilities defined in Volume I, Section 2 as well as authentication requirements. Start Printed Page 18982

6.1 The Security Requirements Listed in Volume I, Section 2.2.1 Shall be Applicable to Systems With Wireless Communications

6.2 The Accuracy Requirements Listed in Volume I, Section 2.2.2 Shall be Applicable to Systems With Wireless Communications

6.2.1 The Use of Wireless Communications That May Cause Impact to the System's Accuracy Through Electromagnetic Stresses Is Prohibited

6.3 The Error Recovery Requirements Listed in Volume I, Section 2.2.3, Shall Be Applicable to Systems With Wireless Communications

6.4 All Wireless Communications Actions Shall Be Logged

Discussion: A log of important information is maintained to monitor the wireless communications. This is to ensure that the wireless communications are only used by authorized users with authorized access to authorized devices or services, or to determine if these requirements were not followed. This relates to the system audit requirements (Volume I, Section 2.2.5) and integrity (Volume I, Section 2.2.4), if wireless communications are used.

6.4.1 The Log Shall Contain at Least the Following Entries: Times Wireless Activated and Deactivated, Services Accessed, Identification of Device to Which Data Was Transmitted to or Received From, Identification of Authorized User, and Successful and Unsuccessful Attempts To Access Wireless Communications or Service

Discussion: Other information such as the number of frames or packets transmitted or received at various logical layers may be useful, but is dependent on the wireless technology used.

[Best Practice for Voting Officials] Appropriate procedures are needed to ensure that wireless communication actions are logged and capture at least the following information: Times wireless activated and deactivated, services accessed, identification of device to which data was transmitted to or received from, identification of authorized user, and successful and unsuccessful attempts to access wireless communications or service.

6.5 Authentication

Authentication is an important part in the protection and security of the wireless communications. It provides a mechanism to verify the identity and legitimacy of a person, device, services, or system. Authenticating users, devices and services helps to secure the wireless communications and prevent unauthorized access to the system, services and/or information.

6.5.1 Device Authentication Shall Occur Before Any Access to or Services From the Voting System are Granted Through Wireless Communications

6.5.2 User Authentication Shall Be at Least Level 2 as Per NIST Special Publication 800-63 Version 1.0.1, “Electronic Authentication Guideline.”

4. Distribution of Voting System Software and Setup Validation (Normative)

This section specifies requirements for the distribution of voting system software and the setup validation performed on voting system equipment. These requirements are applicable to voting systems that have completed qualification testing. The goal of the software distribution requirements is to ensure that the correct voting system software has been distributed without modification. The goal of setup validation requirements, including requirements for verifying the presence of qualified software and the absence of other software, is to ensure that voting system equipment is in a proper initial state before being used.

In general, a voting system can be considered to be composed of multiple other systems including polling place systems, central counting/aggregation systems, and election management systems. These other systems may reside on different computer based platforms at different locations and run different software. Voting system software is considered to be all executable code and associated configuration files critical for the proper operation of the voting system regardless of the location of installation and functionality provided. This includes third party software such as operating systems, drivers, etc.

1. Software Distribution Methodology Requirements

1.1 The Vendor Shall Document All Software Including Voting System Software, Third Party Software (Such as Operating Systems, Drivers, etc.) To Be Installed on Voting Equipment of the Qualified Voting System, and Installation Programs

1.1.1 The Documentation Shall Have a Unique Identifier (Such as a Serial Number) for the Following Set of Information: Documentation, Software Vendor Name, Product Name, Version, Qualification Number of the Voting System, File Names and Paths or Other Location Information (Such as Storage Addresses) of the Software

Start Printed Page 18983

1.1.2 The Documentation Shall Designate All Software Files as Static, Semi-Static, or Dynamic

Discussion: Static voting system software such as executable code does not change based on the election being conducted or the voting equipment upon which it is installed. Semi-static voting system software contains configuration information for the voting system based on the voting equipment that is installed and the election being conducted. Semi-static software is only modified during the installation of (a) the voting system software on voting equipment or (b) the election specific software such as ballot formats. Dynamic voting system software changes over time once installed on voting equipment. However, the specific time or value of the change in the dynamic software is usually unknown a priori making it impossible to create reference information to verify the software.

1.2 The EAC Accredited Testing Authority Shall Witness the Final Build of the Executable Version of the Qualified Voting System Software Performed by the Vendor

1.2.1 The Testing Authority Shall Create a Complete Record of the Build That Includes: A Unique Identifier (Such as a Serial Number) for the Complete Record, List of Unique Identifiers of Write-Once Media Associated with the record, Time, Date, Location, Name and Signatures of All People Present, Source Code and Resulting Executable File Names, Version of Voting System Software, Qualification Number of the Voting System, the Name and Versions of All (Including Third Party) Libraries, and the Name, Version, and Configuration Files of the Development Environment Used for the Build

1.2.2 The Record of the Source Code and Executable Files Shall be Made on Write-Once Media. Each Piece of Write-Once Media Shall Have a Unique Identifier

Discussion: Write-once media includes technology such as a CD-R, ROM, or PROM (but not EEPROM or CD-RW). The unique identifiers appear on indelibly printed labels and in a digitally signed file on the write-once media.

1.2.3 The Testing Authority Shall Retain This Record Until the Voting System Ceases to be Qualified

1.2.4 The EAC Accredited Testing Authority Shall Create a Subset of the Complete Record of the Build That Includes a Unique Identifier (Such as a Serial Number) of the Subset, the Unique Identifier of the Complete Record, List of Unique Identifiers of Write-Once Media Associated With the Subset, Vendor, Product Name, Version of Voting System Software, Qualification Number of the Voting System, All the Files That Resulted from the Build and Binary Images of All Installation Programs

1.2.5 The Record of the Software Shall be Made on Write-Once Media. Each Piece of Write-Once Media Shall Have a Unique Identifier

1.2.6 The Testing Authority Shall Retain a Copy, Send a Copy to the Vendor, and Send a Copy to the NIST National Software Reference Library (NSRL) [1] and/or to Any Other Repository Named by the Election Assistance Commission

Discussion: The NSRL was established to meet the needs of the law enforcement community for court admissible digital evidence by providing an authoritative source of commercial software reference information. Information is available at www.nsrl.nist.gov.

1.2.7 The Testing Authority Shall Retain This Record Until the Voting System Ceases to be Qualified

1.3 The Vendor Shall Provide the NSRL or Other EAC Designated Repository With a Copy of All Third Party Software

1.4 All Voting System Software, Installation Programs, Third Party Software (Such as Operating Systems, Drivers, etc.) Used to Install or to be Installed on Voting System Equipment Shall be Distributed on a Write-Once Media

[Best Practice for Voting Officials] Voting software used to install the qualified voting systems can be obtained on write-once media from the voting system vendor or an EAC accredited testing authority. Start Printed Page 18984

1.4.1 The Vendor Shall Document That the Process Used to Verify the Software Distributed on Write-Once Media is the Qualified Software by Using the Reference Information Provided by the NSRL or Other EAC Designated Repository

[Best Practice for Voting Officials] The reference information produced by the NSRL or other EAC designated repository can be used to verify that the correct software has been received.

1.4.2 The Voting System Equipment Shall be Designed to Allow the Voting System Administrator to Verify That the Software is the Qualified Software by Comparing it to Reference Information Produced by the NSRL or Other EAC Designated Repository Before Installing the Software

1.4.3 The Vendors and Testing Authority Shall Document to Whom They Provide Voting System Software Write-Once Media

2. Generation and Distribution Requirements for Reference Information

2.1 The NSRL or Other EAC Designed Repository Shall Generate Reference Information Using the Binary Images of the (a) Qualified Voting System Software Received on Write-Once Media From Testing Authorities and (b) Election Specific Software Received on Write-Once Media From Jurisdictions

2.1.1 The NSRL or Other EAC Designated Repository Shall Generate Reference Information in at Least One of the Following Forms: (a) Complete Binary Images, (b) Cryptographic Hash Values, or (c) Digital Signatures of the Software

Discussion: Although binary images, cryptographic hashes, and digital signatures can detect a modification or alteration in the software, they cannot determine if the change to the software was accidental or intentional.

2.1.1.1 The NSRL or Other EAC Designated Repository Shall Create a Record of the Creation of Reference Information That Includes: A Unique Identifier (Such as a Serial Number) for the Record, File Names of Software and Associated Unique Identifier(s) of the Write-Once Media From Which Reference Information is Generated, Time, Date, Name of People Who Generated Reference Information, the Type of Reference Information Created, Qualification Number of Voting System (If Issued), Voting System Software Version, Product Name, and Vendor

2.1.1.2 The NSRL or Other EAC Designated Repository Shall Retain the Write-Once Media Used to Generate the Reference Information Until the Voting System Ceases to be Qualified

2.1.1.3 The NSRL or Other EAC Designated Repository That Generates Hash Value and/or Digital Signature Reference Information Shall Use FIPS Approved Algorithms for Hashing and Signing

2.1.1.4 The NSRL or Other EAC Designated Repository That Generates Hash Values, Digital Signatures Reference Information, or Cryptographic Keys Shall Use a FIPS 140-2 Level 1 or Higher Validated Cryptographic Module

Discussion: See http://www.csrc.nist.gov/​cryptval/​ for information on FIPS 140-2.

2.1.1.5 The NSRL or Other EAC Designated Repository That Generates Sets of Hash Values and Digital Signatures for Reference Information Shall Include a Hash Value or Digital Signature Covering the Set of Reference Information

[FEDREG][VOL]71[NO]1[DATE]Monday, January 3, 2006[UNITNAME]Notices[NOTICES][NOTICE][PREAMB][AGENCY TYPE='S']DEPARTMENT OF [SUBAGY] [CFR] [DEPDOC][Docket No. [RIN]RIN [SUBJECT][AGY][HED]AGENCY: [P][ACT][HED]ACTION:[P]  [/ACT][SUM][HED]SUMMARY:[P] [DATES][HED]DATES:[P] [ADD][HED]ADDRESSES:[P] [FURINF][HED]FOR FURTHER INFORMATION CONTACT:[P] [SUPLINF][HED]SUPPLEMENTARY INFORMATION:[P] [FNP][HD3]2.1.1.6 If The NSRL or Other EAC Designated Repository Uses Public key Technology, the Following Requirements Shall Be Met[P]• Public and private key pairs used by the repository to generate digital signatures shall be 2048-bits or greater in length, and [P]• The repository's private keys used to generate digital signature reference information shall be used for no more than three years. [GPH SPAN='1' DEEP='38'][GID]EN12AP06.009[/GPH][HD3]2.1.1.7 Public Keys Used To Verify Digital Signature Reference Information Shall Be Placed on a Write-Once Media if Not Contained in a Signed Non-Proprietary Format for Distribution [GPH SPAN='1' DEEP='38'][GID]EN12AP06.009[/GPH][P]Discussion: Examples of non-proprietary standard formats include X.509 or PKCS#7. [HD3]2.1.1.8 All Copies of Public Key Write-Once Media Made by the Repository Shall be Labeled so That They are Uniquely Identifiable Including at a Minimum: A Unique Identifier (Such as a Serial Number) for the Write-Once Media, Time, Date, Location, Name(s) of the Repository Owning the Associated Private Keys, Documentation About its Creation, and an Indication That the Contents are Public Keys[GPH SPAN='1' DEEP='38'][GID]EN12AP06.009[/GPH][HD3]2.1.1.9 The NSRL or Other EAC Designated Repository Shall Document to Whom They Provide Write-Once Media Containing Their Public Keys Used To Verify Digital Signature Reference Information Including at a Minimum: The Uniquely Identified Public Keys, Time and Date Provided, Name and Contact Information (Phone, Address, E-mail Address, etc.) of the Recipient[GPH SPAN='1' DEEP='38'][GID]EN12AP06.009[/GPH][HD3]2.1.1.10 When a Private Key Used To Generate Digital Signature Reference Information Becomes Compromised, the NSRL or EAC Designated Repository Shall Provide Notification to Recipients of the Associated Public Key That the Private Key has Been Compromised and the Date of Compromise[GPH SPAN='1' DEEP='38'][GID]EN12AP06.009[/GPH][HD2]2.2 The NSRL or Other EAC Designated Repository Shall Make Both the Reference Information Available on Write-Once Media and its Associated Documentation That is Labeled by the Repository That Created it Uniquely Identifiable by Including at a Minimum: A Unique Identifier (Such as a Serial Number) for the Write-Once Media, Time, Date, Location, Name of the Creating Repository, and an Indication that the Contents are Reference Information[GPH SPAN='1' DEEP='38'][GID]EN12AP06.009[/GPH][P][Best Practice for Voting Officials] To ensure that the write-once media contains the correct information, a digital signature can be used. The digital signature can replace secure storage of reference information since the digital signature can be used to verify that the reference information media has not been modified or corrupted. [HD1]3. Setup Validation Methodology Requirements [HD2]3.1 Setup Validation Methods Shall Verify That no Unauthorized Software Is Present on the Voting Equipment[GPH SPAN='1' DEEP='38'][GID]EN12AP06.004[/GPH][HD3]3.1.1 The Vendor Shall Have a Process to Verify That the Correct Software Is Loaded, That There Is no Unauthorized Software, and That Static and Semi-Static Voting System Software on Voting Equipment Has Not Been Modified Using the Reference Information From the NSRL or Other EAC Designated Repository[GPH SPAN='1' DEEP='38'][GID]EN12AP06.004[/GPH][HD3]3.1.1.1 The Process Used To Verify Software Should Be Possible to Perform Without Using Software Installed on the Voting System[GPH SPAN='1' DEEP='38'][GID]EN12AP06.004[/GPH][HD3]3.1.1.2 The Vendor Shall Document the Process Used To Verify Software on Voting Equipment[GPH SPAN='1' DEEP='38'][GID]EN12AP06.004[/GPH][HD3]3.1.1.3 The Process Shall not Modify the Voting System Software on the Voting System During the Verification Process[GPH SPAN='1' DEEP='38'][GID]EN12AP06.004[/GPH][HD3]3.1.2 The Vendor Shall Provide a Method To Comprehensively List all Software Files That are Installed on Voting Systems[GPH SPAN='1' DEEP='38'][GID]EN12AP06.004[/GPH][HD3]3.1.2.1 The Verification Process Shall Be Able To Be Performed Using COTS Software and Hardware Available From Sources Other Than the Voting System Vendor[GPH SPAN='1' DEEP='38'][GID]EN12AP06.004[/GPH][HD3]3.1.2.2 If the Process Uses Hashes or Digital Signatures, Then the Verification Software Shall Use a FIPS 140-2 Level 1 or Higher Validated Cryptographic Module[GPH SPAN='1' DEEP='38'][GID]EN12AP06.004[/GPH][HD3]3.1.2.3 The Verification Process Shall Either (a) use Reference Information on “Write-Once” Media Received From the Repository or (b) Verify the Digital Signature of the Reference Information on any Other Media[GPH SPAN='1' DEEP='38'][GID]EN12AP06.004[/GPH][HD3]3.1.2.4 Voting System Equipment Shall Provide a Read-Only External Interface To Access the Software on the System[P]• The external interface shall be protected using tamper evident techniques. [P]• The external interface shall have a physical indicator showing when the interface is enabled and disabled. [P]• The external interface shall be disabled during voting. [P]• The external interface should provide a direct read-only access to the location of the voting system software without the use of installed software. [GPH SPAN='3' DEEP='38'][GID]EN12AP06.004[/GPH][HD2]3.2 Setup Validation Methods Shall Verify That Registers and Variables of the Voting System Equipment Contain the Proper Static and Initial Values[GPH SPAN='3' DEEP='38'][GID]EN12AP06.004[/GPH][HD3]3.2.1 The Vendor Should Provide a Method To Query the Voting Systems To Determine the Values of all Static and Dynamic Registers and Variables Including the Values That Jurisdictions are Required To Modify To Conduct a Specific Election[GPH SPAN='1' DEEP='38'][GID]EN12AP06.004[/GPH][HD3]3.2.2 The Vendor Shall Document the Values of all Static Registers and Variables and the Initial Starting Values of all Dynamic Registers and Variables Listed for Voting System Software Except for the Values set To Conduct a Specific Election[GPH SPAN='1' DEEP='38'][GID]EN12AP06.004[/GPH][P][Best Practice for Voting Officials] The vendor's documented values can be used to verify that all voting systems' static and initial register and variable values are correct prior to an election. [P][Best Practice for Voting Officials] The reference information can be used to verify that voting system software is the correct version of the software prior to an election. [P][Best Practice for Voting Officials] If differences between the reference information and voting system software are found, then appropriate procedures are needed to handle and resolve these anomalies. [?USGPO Galley End:?]

6.1 Scope

This section describes essential security capabilities for a voting system, encompassing the system's hardware, software, communications, and documentation. The Standards recognize that no predefined set of security standards will address and defeat all conceivable or theoretical threats. However, the Standards articulate requirements to achieve acceptable levels of integrity, reliability, and inviolability. Ultimately, the objectives of the security standards for voting systems are:

  • To establish and maintain controls that can ensure that accidents, inadvertent mistakes, and errors are minimized,
  • To protect the system from intentional manipulation and fraud, and from malicious mischief,
  • To identify fraudulent or erroneous changes to the system, and
  • To protect secrecy in the voting process.

The Standards are intended to address a broad range of risks to the integrity of a voting system. While it is not possible to identify all potential risks, the Standards identify several types of risk that must be addressed by a voting system. These include:

  • Unauthorized changes to system capabilities for:
  • Defining ballot formats,
  • Casting and recording votes,
  • Calculating vote totals consistent with defined ballot formats, and
  • Reporting vote totals, Start Printed Page 18985
  • Alteration of voting system audit trails,
  • Changing, or preventing the recording of, a vote,
  • Introducing data for a vote not cast by a registered voter,
  • Changing calculated vote totals,
  • Preventing access to vote data, including individual votes and vote totals, to unauthorized individuals, and
  • Preventing access to voter identification data and data for votes cast by the voter such that an individual can determine the content of specific votes cast by the voter.

This section describes specific capabilities that vendors shall integrate into a voting system in order to address the risks listed above.

6.1.1 System Components and Sources

The requirements of this section apply to the broad range of hardware, software, communications components, and documentation that comprises a voting system. These requirements apply to components:

  • Provided by the voting system vendor and the vendor's suppliers,
  • Furnished by an external provider (for example providers of personal computers and commercial off-the-shelf (COTS) operating systems) where the components are capable of being used during voting system operation, and
  • Developed by a voting jurisdiction.

6.1.2 Location and Control of Software and Hardware on Which It Operates

The requirements of this section apply to all software used in any manner to support any voting-related activity, regardless of the ownership of the software or the ownership and location of the hardware on which the software is installed or operated. These requirements apply to software that operates on:

  • Voting devices and vote counting devices installed at polling places under the control or authority of the voting jurisdiction, and
  • Ballot printers, vote counting devices, and other hardware typically installed at central or precinct locations (including contractor facilities).

However, some requirements are applicable only in circumstances specified by this section.

6.1.3 Elements of Security Outside Vendor Control

The requirements of this section apply to the capabilities of a voting system provided by the vendor. The Standards recognizes that effective security requires safeguards beyond those provided by the vendor. Effective security demands diligent security practices by the purchasing jurisdiction and the jurisdictions representatives. These practices include:

  • Administrative and management controls for the voting system and election management, including access controls,
  • Internal security procedures,
  • Adherence to, and enforcement of, operational procedures (e.g., effective password management),
  • Security of physical facilities, and
  • Organizational responsibilities and personnel screening.

Because specific standards for these elements are not under the direct control of the vendor, they will be addressed in forthcoming Operational Guidelines that address best practices for jurisdictions conducting elections and managing the operation of voting systems.

6.1.4 Organization of this Section

The standards presented in this section are organized as follows:

  • Access Control: These standards addresses procedures and system capabilities that limit or detect access to critical system components in order to guard against loss of system integrity, availability, confidentiality, and accountability.
  • Equipment and Data Security: These standards address physical security measures and procedures that prevent disruption of the voting process at the poll site and corruption of voting data.
  • Software Security: These standards address the installation of software, including firmware, in the voting system and the protection against malicious software.
  • Telecommunication and Data Transmission: These standards address security for the electronic transmission of data between system components or locations over both private and public networks
  • Security for Transmission of Official Data Over Public Communications Networks: These standards address security for systems that communicate individual votes or vote totals over public communications networks.

It should be noted that computer-generated audit controls facilitate system security and are an integral part of software capability. These audit requirements are presented in section 4.

6.2 Access Control

Access controls are procedures and system capabilities that detect or limit access to system components in order to guard against loss of system integrity, availability, confidentiality, and accountability. Access controls provide reasonable assurance that system resources such as data files, application programs, and computer-related facilities and equipment are protected against unauthorized operation, modification, disclosure, loss, or impairment. Unauthorized operations include modification of compiled or interpreted code, run-time alteration of flow control logic or of data, and abstraction of raw or processed voting data in any form other than a standard output report by an authorized operator.

Access controls may include physical controls, such as keeping computers in locked rooms to limit physical access, and technical controls, such as security software programs designed to prevent or detect unauthorized access to sensitive files. The access controls contained in this section of the Standards are limited to those controls required of system vendors. Access controls required of jurisdictions will be addressed in future documents detailing operational guidelines for jurisdictions.

6.2.1 Access Control Policy

The vendor shall specify the general features and capabilities of the access control policy recommended to provide effective voting system security.

6.2.1.1 General Access Control Policy

Although the jurisdiction in which the voting system is operated is responsible for determining the access policies applying to each election, the vendor shall provide a description of recommended policies for:

a. Software access controls,

b. Hardware access controls,

c. Communications,

d. Effective password management,

e. Protection abilities of a particular operating system,

f. General characteristics of supervisory access privileges,

g. Segregation of duties, and

h. Any additional relevant characteristics.

6.2.1.2 Individual Access Privileges

Voting system vendors shall:

a. Identify each person to whom access is granted, and the specific functions and data to which each person holds authorized access,

b. Specify whether an individual's authorization is limited to a specific time, time interval, or phase of the voting or counting operations, and

c. Permit the voter to cast a ballot expeditiously, but preclude voter access to all other aspects of the vote-counting processes. Start Printed Page 18986

6.2.2 Access Control Measures

Vendors shall provide a detailed description of all system access control measures designed to permit authorized access to the system and prevent unauthorized access. Examples of such measures include:

a. Use of data and user authorization,

b. Program unit ownership and other regional boundaries,

c. One-end or two-end port protection devices,

d. Security kernels,

e. Computer-generated password keys,

f. Special protocols,

g. Message encryption, and

h. Controlled access security.

Vendors also shall define and provide a detailed description of the methods used to prevent unauthorized access to the access control capabilities of the system itself.

6.3 Physical Security Measures

A voting system's sensitivity to disruption or corruption of data depends, in part, on the physical location of equipment and data media, and on the establishment of secure telecommunications among various locations. Most often, the disruption of voting and vote counting results from a physical violation of one or more areas of the system thought to be protected. Therefore, security procedures shall address physical threats and the corresponding means to defeat them.

6.3.1 Polling Place Security

For polling place operations, vendors shall develop and provide detailed documentation of measures to anticipate and counteract vandalism, civil disobedience, and similar occurrences. The measures shall:

a. Allow the immediate detection of tampering with vote casting devices and precinct ballot counters, and

b. Control physical access to a telecommunications link if such a link is used.

6.3.2 Central Count Location Security

Vendors shall develop and document in detail the measures to be taken in a central counting environment. These measures shall include physical and procedural controls related to the:

a. Handling of ballot boxes,

b. Preparing of ballots for counting,

c. Counting operations, and

d. Reporting data.

6.4 Software Security

Voting systems shall meet specific security requirements for the installation of software and for protection against malicious software.

6.4.1 Software and Firmware Installation

The system shall meet the following requirements for installation of software, including hardware with embedded firmware:

a. If software is resident in the system as firmware, the vendor shall require and state in the system documentation that every device is to be retested to validate each ROM prior to the start of elections operations,

b. To prevent alteration of executable code, no software shall be permanently installed or resident in the system unless the system documentation states that the jurisdiction must provide a secure physical and procedural environment for the storage, handling, preparation, and transportation of the system hardware,

c. The system bootstrap, monitor, and device-controller software may be resident permanently as firmware, provided that this firmware has been shown to be inaccessible to activation or control by any means other than by the authorized initiation and execution of the vote-counting program, and its associated exception handlers,

d. The election-specific programming may be installed and resident as firmware, provided that such firmware is installed on a component (such as computer chip) other than the component on which the operating system resides; and

e. After initiation of election day testing, no source code or compilers or assemblers shall be resident or accessible.

6.4.2 Protection Against Malicious Software

Voting systems shall deploy protection against the many forms of threats to which they may be exposed such as file and macro viruses, worms, Trojan horses, and logic bombs. Vendors shall develop and document the procedures to be followed to ensure that such protection is maintained in a current status.

6.5 Telecommunications and Data Transmission

There are four areas that must be addressed by telecommunications and data transmission security capabilities:

  • Access control for telecommunications capabilities,
  • Data integrity,
  • Detection and prevention of data interception, and
  • Protection against external threats to which commercial products used by a voting system may be susceptible.

6.5.1 Access Control

Voting systems that use telecommunications to communicate between system components and locations are subject to the same security requirements governing access to any other system hardware, software, and data function.

6.5.2 Data Integrity

Voting systems that use electrical or optical transmission of data shall ensure the receipt of valid vote records is verified at the receiving station. This should include standard transmission error detection and correction methods such as checksums or message digest hashes. Verification of correct transmission shall occur at the voting system application level and ensure that the correct data is recorded on all relevant components consolidated within the polling place prior to the voter completing casting of his or her ballot.

6.5.3 Data Interception Prevention

Voting systems that use telecommunications as defined in Section 5 to communicate between system components and locations before the poll site is officially closed shall:

a. Implement an encryption standard currently documented and validated for use by an agency of the U.S. Federal Government; and

b. Provide a means to detect the presence of an intrusive process, such as an Intrusion Detection System.

6.5.4 Protection Against External Threats

Voting systems that use public telecommunications networks shall implement protections against external threats to which commercial products used in the system may be susceptible.

6.5.4.1 Identification of COTS Products

Voting systems that use public telecommunications networks shall provide system documentation that clearly identifies all COTS hardware and software products and communications services used in the development and/or operation of the voting system, including:

a. Operating systems,

b. Communications routers,

c. Modem drivers, and

d. Dial-up networking software.

Such documentation shall identify the name, vendor, and version used for each such component.

6.5.4.2 Use of Protective Software

Voting systems that use public telecommunications networks shall use Start Printed Page 18987protective software at the receiving-end of all communications paths to:

a. Detect the presence of a threat in a transmission,

b. Remove the threat from infected files/data,

c. Prevent against storage of the threat anywhere on the receiving device,

d. Provide the capability to confirm that no threats are stored in system memory and in connected storage media, and

e. Provide data to the system audit log indicating the detection of a threat and the processing performed.

Vendors shall use multiple forms of protective software as needed to provide capabilities for the full range of products used by the voting system.

6.5.4.3 Monitoring and Responding to External Threats

Voting systems that use public telecommunications networks may become vulnerable, by virtue of their system components, to external threats to the accuracy and integrity of vote recording, vote counting, and vote consolidation and reporting processes. Therefore, vendors of such systems shall document how they plan to monitor and respond to known threats to which their voting systems are vulnerable. This documentation shall provide a detailed description, including scheduling information, of the procedures the vendor will use to:

a. Monitor threats, such as through the review of assessments, advisories, and alerts for COTS components issued by the Computer Emergency Response Team (CERT), for which a current listing can be found at http://www.cert.org, the National Infrastructure Protection Center (NIPC), for which a current listing can be found at http://www.nipc.gov/​warnings/​warnings.htm, and the Federal Computer Incident Response Capability (FedCIRC), for which additional information can be found at http://www.fedcirc.gov/​,

b. Evaluate the threats and, if any, proposed responses,

c. Develop responsive updates to the system and/or corrective procedures,

d. Submit the proposed response to the ITAs and appropriate states for approval, identifying the exact changes and whether or not they are temporary or permanent,

e. After implementation of the proposed response is approved by the state, assist clients, either directly or through detailed written procedures, how to update their systems and/or to implement the corrective procedures no later than one month before an election, and

f. Address threats emerging too late to correct the system at least one month before the election, including:

(1) Providing prompt, emergency notification to the ITAs and the affected states and user jurisdictions,

(2) Assisting client jurisdictions directly, or advising them through detailed written procedures, to disable the public telecommunications mode of the system, and

(3) After the election, modifying the system to address the threat, submitting the modified system to an ITA and appropriate state certification authority for approval, and assisting client jurisdictions directly, or advising them through detailed written procedures, to update their systems and/or to implement the corrective procedures after approval.

6.5.5 Shared Operating Environment

Ballot recording and vote counting can be performed in either a dedicated or non-dedicated environment. If ballot recording and vote counting operations are performed in an environment that is shared with other data processing functions, both hardware and software features shall be present to protect the integrity of vote counting and of vote data. Systems that use a shared operating environment shall:

a. Use security procedures and logging records to control access to system functions,

b. Partition or compartmentalize voting system functions from other concurrent functions at least logically, and preferably physically as well,

c. Controlled system access by means of passwords, and restriction of account access to necessary functions only, and

d. Have capabilities in place to control the flow of information, precluding data leakage through shared system resources.

6.5.6 Access to Incomplete Election Returns and Interactive Queries

If the voting system provides access to incomplete election returns and interactive inquiries before the completion of the official count, the system shall:

a. For equipment that operates in a central counting environment, be designed to provide external access to incomplete election returns only if that access for these purposes is authorized by the statutes and regulations of the using agency. This requirement applies as well to polling place equipment that contains a removable memory module, or that may be removed in its entirety to a central place for the consolidation of polling place returns.

b. Use voting system software and its security environment designed such that data accessible to interactive queries resides in an external file, or database, that is created and maintained by the elections software under the restrictions applying to any other output report, namely, that:

(1) The output file or database has no provision for write-access back to the system.

(2) Persons whose only authorized access is to the file or database are denied write-access, both to the file or database, and to the system.

6.6 Security for Transmission of Official Data Over Public Communications Networks

DRE systems that transmit data over public telecommunications networks face security risks that are not present in other DRE systems. This section describes standards applicable to DRE systems that use public telecommunications networks.

6.6.1 General Security Requirements for Systems Transmitting Data Over Public Networks

All systems that transmit data over public telecommunications networks shall:

a. Preserve the secrecy of a voter's ballot choices, and prevent anyone from violating ballot privacy,

b. Employ digital signature for all communications between the vote server and other devices that communicate with the server over the network, and

c. Require that at least two authorized election officials activate any critical operation regarding the processing of ballots transmitted over a public communications network takes place, i.e. the passwords or cryptographic keys of at least two employees are required to perform processing of votes.

6.6.2 Voting Process Security for Casting Individual Ballots over a Public Telecommunications Network

Systems designed for transmission of telecommunications over public networks shall meet security standards that address the security risks attendant with the casting of ballots from poll sites controlled by election officials using voting devices configured and installed by election officials and/or their vendor or contractor, and using in-person authentication of individual voters.

6.6.2.1 Documentation of Mandatory Security Activities

Vendors of systems that cast individual ballots over a public Start Printed Page 18988telecommunications network shall provide detailed descriptions of:

a. All activities mandatory to ensuring effective system security to be performed in setting up the system for operation, including testing of security before an election; and

b. All activities that should be prohibited during system setup and during the time frame for voting operations, including both the hours when polls are open and when polls are closed.

6.6.2.2 Capabilities to Operate During Interruption of Telecommunications Capabilities

These systems shall provide the following capabilities to provide resistance to interruptions of telecommunications service that prevent voting devices at the poll site from communicating with external components via telecommunications:

a. Detect the occurrence of a telecommunications interruption at the poll site and switch to an alternative mode of operation that is not dependent on the connection between poll site voting devices and external system components,

b. Provide an alternate mode of operation that includes the functionality of a conventional DRE machine without losing any single vote,

c. Create and preserve an audit trail of every vote cast during the period of interrupted communication and system operation in conventional DRE system mode,

d. Upon reestablishment of communications, transmit and process votes accumulated while operating in conventional DRE system mode with all security safeguards in effect, and

e. Ensure that all safeguards related to voter identification and authentication are not affected by the procedures employed by the system to counteract potential interruptions of telecommunications capabilities.

Volume I, Section 7

Table of Contents

7 Quality Assurance

7.1 Scope

7.2 General Requirements

7.3 Components from Third Parties

7.4 Responsibility for Tests

7.5 Parts & Materials Special Tests and Examinations

7.6 Quality Conformance Inspections

7.7 Documentation

7 Quality Assurance

7.1 Scope

Quality Assurance provides continuous confirmation that a voting system conforms with the Standards and to the requirements of state and local jurisdictions. Quality Assurance is a vendor function with associated practices that is initiated prior to system development and continues throughout the maintenance life cycle of the voting system. Quality Assurance focuses on building quality into a system and reducing dependence on system tests at the end of the life cycle to detect deficiencies, thus helping ensure the system:

  • Meets stated requirements and objectives;
  • Adheres to established standards and conventions;
  • Functions consistent with related components and meets dependencies for use within the jurisdiction; and
  • Reflects all changes approved during its initial development, internal testing, qualification, and, if applicable, additional certification processes.

7.2 General Requirements

The voting system vendor is responsible for designing and implementing a quality assurance program to ensure that the design, workmanship, and performance requirements of this standard are achieved in all delivered systems and components. At a minimum, this program shall:

a. Include procedures for specifying, procuring, inspecting, accepting, and controlling parts and raw materials of the requisite quality;

b. Require the documentation of the hardware and software development process;

c. Identify and enforce all requirements for:

(1) In-process inspection and testing that the manufacturer deems necessary to ensure proper fabrication and assembly of hardware, and

(2) Installation and operation of software (including firmware).

d. Include plans and procedures for post-production environmental screening and acceptance test; and

e. Include a procedure for maintaining all data and records required to document and verify the quality inspections and tests.

7.3 Components from Third Parties

A vendors who does not manufacture all the components of its voting system, but instead procures components as standard commercial items for assembly and integration into a voting system, should verify that the supplier vendors follow documented quality assurance procedures that are at least as stringent as those used internally by the voting system vendor.

7.4 Responsibility for Tests

The manufacturer or vendor shall be responsible for:

a. Performing all quality assurance tests;

b. Acquiring and documenting test data; and

c. Providing test reports for review by the ITA, and to the purchaser upon request.

7.5 Parts & Materials Special Tests and Examinations

In order to ensure that voting system parts and materials function properly, vendors shall:

a. Select parts and materials to be used in voting systems and components according to their suitability for the intended application. Suitability may be determined by similarity of this application to existing standard practice, or by means of special tests;

b. Design special tests, if needed, to evaluate the part or material under conditions accurately simulating the actual operating environment; and

c. Maintain the resulting test data as part of the quality assurance program documentation.

7.6 Quality Conformance Inspections

The vendor performs conformance inspections to ensure the overall quality of the voting system and components delivered to the ITA for testing and to the jurisdiction for implementation. To meet the conformance inspection requirements the vendor or manufacturer shall:

a. Inspect and test each voting system or component to verify that it meets all inspection and test requirements for the system; and

b. Deliver a record of tests, or a certificate of satisfactory completion, with each system or component.

7.7 Documentation

Vendors are required to produce documentation to support the development and formal testing of voting systems. To meet documentation requirements, vendors shall provide complete product documentation with each voting systems or components, as described Volume II, Section 2 for the TDP. This documentation shall:

a. Be sufficient to serve the needs of the ITA, voters, election officials, and maintenance technicians;

b. Be prepared and published in accordance with standard industrial practice for information technology and electronic and mechanical equipment; and

c. Consist, at a minimum, of the following:

(1) System overview; Start Printed Page 18989

(2) System functionality description;

(3) System hardware specification;

(4) Software design and specifications;

(5) System security specification;

(6) System test and verification specification;

(7) System operations procedures;

(8) System maintenance procedures;

(9) Personnel deployment and training requirements;

(10) Configuration management plan;

(11) Quality assurance program; and

(12) System Change Notes.

Volume I, Section 8

Table of Contents

8 Configuration Management

8.1 Scope

8.1.1 Configuration Management Requirements

8.1.2 Organization of Configuration Management Standards

8.1.3 Application of Configuration Management Requirements

8.2 Configuration Management Policy

8.3 Configuration Identification

8.3.1 Structuring and Naming Configuration Items

8.3.2 Versioning Conventions

8.4 Baseline, Promotion, and Demotion Procedures

8.5 Configuration Control Procedures

8.6 Release Process

8.7 Configuration Audits

8.7.1 Physical Configuration Audit

8.7.2 Functional Configuration Audit

8.8 Configuration Management Resources

8 Configuration Management

8.1 Scope

This section contains specific requirements for configuration management of voting systems. For the purpose of the Standards, configuration management is defined as a set of activities and associated practices that ensures full knowledge and control of the components of a system, starting with its initial development and progressing through its ongoing maintenance and enhancement. This section describes activities in terms of their purposes and outcomes. It does not describe specific procedures or steps to be employed to accomplish them. Specific steps and procedures are left to the vendor to select.

Vendors are required to submit these procedures to the Independent Test Authority (ITA) as part of the Technical Data Package (TDP) for system qualifications described in Volume II, Voting Systems Qualification Testing Standards, for review against the requirements of this section. Additionally, state or local election legislation, regulations, or contractual agreements may require the vendor to conform to additional standards for configuration management or to adopt specific required procedures. Further, authorized election officials or their representatives reserve the right to inspect vendor facilities and operations to determine conformance with the vendor's reported procedures and with any additional requirements.

8.1.1 Configuration Management Requirements

Configuration management addresses a broad set of recordkeeping, audit, and reporting activities that contribute to full knowledge and control of a system and its components. These activities include:

  • Identifying discrete system components;
  • Creating records of a formal baseline and later versions of components;
  • Controlling changes made to the system and its components;
  • Releasing new versions of the system to ITAs;
  • Releasing new versions of the system to customers;
  • Auditing the system, including its documentation, against configuration management records;
  • Controlling interfaces to other systems; and
  • Identifying tools used to build and maintain the system.

8.1.2 Organization of Configuration Management Standards

The standards for configuration management presented in this section include:

  • Application of configuration management requirements;
  • Configuration management policy;
  • Configuration identification;
  • Baseline, promotion, and demotion procedures;
  • Configuration control procedures;
  • Release process;
  • Configuration audits; and
  • Configuration management resources.

8.1.3 Application of Configuration Management Requirements

Requirements for configuration management apply regardless of the specific technologies employed to all voting systems subject to the Standards. These system components include:

a. Software components;

b. Hardware components;

c. Communications components;

d. Documentation;

e. Identification and naming and conventions (including changes to these conventions) for software programs and data files;

f. Development and testing artifacts such as test data and scripts; and

g. File archiving and data repositories.

8.2 Configuration Management Policy

The vendor shall describe its policies for configuration management in the TDP. This description shall address the following elements:

a. Scope and nature of configuration management program activities; and

b. Breadth of application of the vendor's policies and practices to the voting system (i.e., extent to which policies and practices apply to the total system, and extent to which policies and practices of suppliers apply to particular components, subsystems, or other defined system elements.

8.3 Configuration Identification

Configuration identification is the process of identifying, naming, and acquiring configuration items. Configuration identification encompasses all system components.

8.3.1 Structuring and Naming Configuration Items

The vendor shall describe the procedures and conventions used to:

a. Classify configuration items into categories and subcategories;

b. Uniquely number or otherwise identify configuration items; and

c. Name configuration items;

8.3.2 Versioning Conventions

When a system component is used to identify higher-level system elements, a vendor shall describe the conventions used to:

a. Identify the specific versions of individual configuration items and sets of items that are used by the vendor to identify higher level system elements such as subsystems;

b. Uniquely number or otherwise identify versions; and

c. Name versions.

8.4 Baseline, Promotion, and Demotion Procedures

The vendor shall establish formal procedures and conventions for establishing and providing a complete description of the procedures and related conventions used to:

a. Establish a particular instance of a component as the starting baseline;

b. Promote subsequent instances of a component to baseline status as development progresses through to completion of the initial completed version released to the ITAs for qualification testing; and

c. Promote subsequent instances of a component to baseline status as the component is maintained throughout its life cycle until system retirement (i.e., the system is no longer sold or maintained by the vendor). Start Printed Page 18990

8.5 Configuration Control Procedures

Configuration control is the process of approving and implementing changes to a configuration item to prevent unauthorized additions, changes, or deletions. The vendor shall establish such procedures and related conventions, providing a complete description of those procedures used to:

a. Develop and maintain internally developed items;

b. Acquire and maintain third-party items;

c. Resolve internally identified defects for items regardless of their origin; and

d. Resolve externally identified and reported defects (i.e., by customers and ITAs).

8.6 Release Process

The release process is the means by which the vendor installs, transfers, or migrates the system to the ITAs and, eventually, to its customers. The vendor shall establish such procedures and related conventions, providing a complete description of those used to:

a. Perform a first release of the system to an ITA;

b. Perform a subsequent maintenance or upgrade release of the system, or a particular components, to an ITA;

c. Perform the initial delivery and installation of the system to a customer, including confirmation that the installed version of the system matches exactly the qualified system version; and

d. Perform a subsequent maintenance or upgrade release of the system, or a particular component, to a customer, including confirmation that the installed version of the system matches exactly the qualified system version.

8.7 Configuration Audits

The Standards require two types of configuration audits: Physical Configuration Audits (PCA) and Functional Configuration Audits (FCA).

8.7.1 Physical Configuration Audit

The PCA is conducted by the ITA to compare the voting system components submitted for qualification to the vendor's technical documentation. For the PCA, a vendor shall provide:

a. Identification of all items that are to be a part of the software release;

b. Specification of compiler (or choice of compilers) to be used to generate executable programs;

c. Identification of all hardware that interfaces with the software;

d. Configuration baseline data for all hardware that is unique to the system;

e. Copies of all software documentation intended for distribution to users, including program listings, specifications, operations manual, voter manual, and maintenance manual;

f. User acceptance test procedures and acceptance criteria; and

g. Identification of any changes between the physical configuration of the system submitted for the PCA and that submitted for the FCA, with a certification that any differences do not degrade the functional characteristics; and

h. Complete descriptions of its procedures and related conventions used to support this audit by:

(1) Establishing a configuration baseline of the software and hardware to be tested; and

(2) Confirming whether the system documentation matches the corresponding system components.

8.7.2 Functional Configuration Audit

The FCA is conducted by the ITA to verify that the system performs all the functions described in the system documentation. The vendor shall:

a. Completely describe its procedures and related conventions used to support this audit for all system components;

b. Provide the following information to support this audit:

(1) Copies of all procedures used for module or unit testing, integration testing, and system testing;

(2) Copies of all test cases generated for each module and integration test, and sample ballot formats or other test cases used for system tests; and

(3) Records of all tests performed by the procedures listed above, including error corrections and retests.

In addition to such audits performed by ITAs during the system qualification process, elements of this audit may also be performed by state election organizations during the system certification process, and individual jurisdictions during system acceptance testing.

8.8 Configuration Management Resources

Often, configuration management activities are performed with the aid of automated tools. Assuring that such tools are available throughout the system life cycle, including if the vendor is acquired by or merged with another organization, is critical to effective configuration management. Vendors may choose the specific tools they use to perform the record keeping, audit, and reporting activities of the configuration management standards. The resources documentation standard provided below focus on assuring that procedures are in place to record information about the tools to help ensure that they, and the data they contain, can be transferred effectively and promptly to a third party should the need arise. Within this context, a vendor is required to develop and provide a complete description of the procedures and related practices for maintaining information about:

a. Specific tools used, current version, and operating environment;

b. Physical location of the tools, including designation of computer directories and files; and

c. Procedures and training materials for using the tools.

Volume I, Section 9

Table of Contents

9 Overview of Qualification Tests

9.1 Scope

9.2 Documentation Submitted by Vendor

9.3 Voting Equipment Submitted by Vendor

9.4 Testing Scope

9.4.1 Test Categories

9.4.1.1 Focus of Functionality Tests

9.4.1.2 Focus of Hardware Tests

9.4.1.3 Focus of Software Evaluation

9.4.1.4 Focus of System-Level Integration Tests

9.4.1.5 Focus of Vendor Documentation Examination

9.4.2 Sequence of Tests and Audits

9.5 Test Applicability

9.5.1 General Applicability

9.5.1.1 Hardware

9.5.1.2 Software

9.5.2 Modifications to Qualified Systems

9.5.2.1 General Requirements for Modifications

9.5.2.2 Basis for Limited Testing Determinations

9.6 Qualification Test Process

9.6.1 Pre-test Activities

9.6.1.1 Initiation of Testing

9.6.1.2 Pre-test Preparation

9.6.2 Qualification Testing

9.6.2.1 Qualification Test Plan

9.6.2.2 Qualification Test Conditions

9.6.2.3 Qualification Test Fixtures

9.6.2.4 Witness of System Build and Installation

9.6.2.5 Qualification Test Data Requirements

9.6.2.6 Qualification Test Practices

9.6.3 Qualification Report Issuance and Post-test Activities

9.6.4 Resolution of Testing Issues

9 Overview of Qualification Tests

9.1 Scope

This section provides an overview of the testing process for qualification testing of voting systems. Qualification testing is the process by which a voting system is shown to comply with the requirements of the Standards and the requirements of its own design and performance specifications.

Qualification testing encompasses the examination of software; tests of hardware under conditions simulating the intended storage, operation, transportation, and maintenance Start Printed Page 18991environments; the inspection and evaluation of system documentation; and operational tests to validate system performance and function under normal and abnormal conditions. The testing also evaluates the completeness of the vendor's developmental test program, including the sufficiency of vendor tests conducted to demonstrate compliance with stated system design and performance specifications, and the vendor's documented quality assurance and configuration management practices. The tests address individual system components or elements, as well as the integrated system as a whole. Since 1994, qualification tests for voting systems have been performed by Independent Test Authorities (ITAs) certified by the National Association of State Election Directors (NASED). NASED has certified an ITA for either the full scope of qualification testing or a distinct subset of the total scope of testing. The test process described in this section may be conducted by one or more ITAs, depending on the nature of tests to be conducted and the expertise of the certified ITAs.

Qualification testing is distinct from all other forms of testing, including developmental testing by the vendor, certification testing by a state election organization, and system acceptance testing by a purchasing jurisdiction:

  • Qualification testing follows the vendor's developmental testing;
  • Qualification testing provides an assurance to state election officials and local jurisdictions of the conformance of a voting system to the Standards as input to state certification of a voting system and acceptance testing by a purchasing jurisdiction; and
  • Qualification testing may precede state certification testing, or may be conducted in parallel as established by the certification program of individual states.

Generally a voting system remains qualified under the standards against which it was tested, as long as all modifications made to the system are evaluated and passed by a certified ITA. The qualification test report remains valid for as long as the voting system remains unchanged from the last tested configuration. However, if a new threat to a particular voting system is discovered, it is the prerogative of NASED to determine which qualified voting systems are vulnerable, whether those systems need to be retested, and the specific tests to be conducted. In addition, when new standards supersede the standards under which the system was qualified, it is the prerogative of NASED to determine when systems that were qualified under the earlier standards will lose their qualification, unless they are tested to meet current standards.

The remainder of this section describes the documentation and equipment required to be submitted by the vendor, the scope of qualification testing, the applicability to voting system components, and the flow of the test process.

9.2 Documentation Submitted by Vendor

The vendor shall submit to the ITA documentation necessary for the identification of the full system configuration submitted for evaluation and for the development of an appropriate test plan by the ITA for system qualification testing.

One element of the documentation is the Technical Data Package (TDP). The TDP contains information that that defines the voting system design, method of operation, and related resources. It provides a system overview and documents the system's functionality, hardware, software, security, test and verification specifications, operations procedures, maintenance procedures, and personnel deployment and training requirements. It also documents the vendor's configuration management plan and quality assurance program. If the system was previously qualified, the TDP also includes the system change notes.

This documentation is used by the ITA in constructing the qualification testing plan and is particularly important in constructing plans for the re-testing of systems that have been qualified previously. Re-testing of systems submitted by vendors that consistently adhere to particularly strong and well documented quality assurance and configuration management practices will generally be more efficient than for systems developed and maintained using less rigorous or less well documented practices. Volume II provides a detailed description of the documentation required for the vendor's quality assurance and configuration management practices used for the system submitted for qualification testing.

9.3 Voting Equipment Submitted by Vendor

Vendors may seek to market a complete voting system or an interoperable component of a voting system. Nevertheless, vendors shall submit for testing the specific system configuration that is to be offered to jurisdictions or that comprises the component to be marketed plus the other components with which the vendor recommends that component be used. The system submitted for testing shall meet the following requirements:

a. The hardware submitted for qualification testing shall be equivalent, in form and function, to the actual production versions of the hardware units or the COTS hardware specified for use in the TDP;

b. The software submitted for qualification testing shall be the exact software that will be used in production units;

c. Engineering or developmental prototypes are not acceptable, unless the vendor can show that the equipment to be tested is equivalent to standard production units in both performance and construction; and

d. Benchmark directory listings shall be submitted for all software/firmware elements (and associated documentation) included in the vendor's release as they would normally be installed upon setup and installation.

9.4 Testing Scope

The qualification test process is intended to discover vulnerabilities that, should they appear in actual election use, could result in failure to complete election operations in a satisfactory manner.

Five types of focuses guide the overall qualification testing process:

  • Operational accuracy in the recording and processing of voting data, as measured by target error rate, for which the maximum acceptable error rate is no more than one in ten million ballot positions, with a maximum acceptable error rate in the test process of one in 500,000 ballot positions (while it would be desirable that there be an error rate of zero, if this had to be proven by a test, the test itself would take an infinity of time);
  • Operational failures or the number of unrecoverable failures under conditions simulating the intended storage, operation, transportation, and maintenance environments for voting systems, using an actual time-based period of processing test ballots;
  • System performance and function under normal and abnormal conditions; and
  • Completeness and accuracy of the system documentation and configuration management records to enable purchasing jurisdictions to effectively install, test, and operate the system.

Qualification testing complements and evaluates the vendor's developmental testing, including any beta testing. The ITA evaluates the completeness of the vendor's Start Printed Page 18992developmental test program, including the sufficiency of vendor tests conducted to demonstrate compliance with the Standards as well as the system's performance specifications. The ITA undertakes sample testing of the vendor's test modules and also designs independent system-level tests to supplement and check those designed by the vendor. Although some of the qualification tests are based on those prescribed in the Military Standards, in most cases the test conditions are less stringent, reflecting commercial, rather than military, practice. The ITA may use automated software testing tools to assist in this process if they are available for the software under examination.

The procedure for disposition of system deficiencies discovered during qualification testing is described in Volume II of the Standards. This procedure recognizes that some but not necessarily all operational malfunctions (apart from software logic defects) may result in rejection. Basically, any defect that results in or may result in the loss or corruption of voting data, whether through failure of system hardware, software, or communication, through procedural deficiency, or through deficiencies in security and audit provisions, shall be cause for rejection. Otherwise, malfunctions that result from failure to comply fully with other requirements of this standard will not in every case warrant rejection. Specific failure definition and scoring criteria are also contained in Volume II.

9.4.1 Test Categories

The qualification test procedure is presented in several parts:

  • Functionality testing;
  • Hardware testing;
  • Software evaluation;
  • System-level integration tests, including audits; and
  • Examination of documented vendor practices for quality assurance and for configuration management.

In practice, there may be concurrent indications of hardware and software function, or failure to function, during certain examinations and tests. Operating tests of hardware partially exercise the software as well and therefore supplement software qualification. Security tests exercise hardware, software and communications capabilities. Documentation review conducted during software qualification supplements the review undertaken for system-level testing.

The qualification test procedures are presented in these categories because test authorities frequently focus separately on each. The following subsections provide information that test authorities need to conduct testing.

Not all systems being tested are required to complete all categories of testing. For example, if a previously-qualified system has had hardware modifications, the system may be subject only to non-operating environmental stress testing of the modified component, and a partial system-level test. If a system consisting of general purpose COTS hardware or one that was previously qualified has had modifications to its software, the system is subject only to software qualification and system-level tests, not hardware testing. However, in all cases the system documentation and configuration management records will be examined to confirm that they completely and accurately reflect the components and component versions that comprise the voting system.

9.4.1.1 Focus of Functionality Tests

Functionality testing is performed to confirm the functional capabilities of a voting system submitted for qualification. The ITA designs and performs procedures to test a voting system against the requirements outlined in Section 2. In order to best compliment the diversity of the voting systems industry, this part of the qualification testing process is not rigidly defined. Although there are basic functionality testing requirements, additions or variations in testing are appropriate depending on the system's use of specific technologies and configurations, the system capabilities, and the outcomes of previous testing.

9.4.1.2 Focus of Hardware Tests

Hardware testing begins with non-operating tests that require the use of an environmental test facility. These are followed by operating tests that are performed partly in an environmental facility and partly in a standard test laboratory or shop environment.

The non-operating tests are intended to evaluate the ability of the system hardware to withstand exposure to the various environmental conditions incidental to voting system storage, maintenance, and transportation. The procedures are based on test methods contained in Military Standards (MIL-STD) 810D, modified where appropriate, and include such tests as: Bench handling, vibration, low and high temperature, and humidity.

The operating tests involve running the system for an extended period of time under varying temperatures and voltages. This period of operation ensures with confidence that the hardware meets or exceeds the minimum requirements for reliability, data reading, and processing accuracy contained in Section 3. The procedure emphasizes equipment operability and data accuracy; it is not an exhaustive evaluation of all system functions. Moreover, the severity of the test conditions, in most cases, has been reduced from that specified in the Military Standards to reflect commercial and industrial, rather than military and aerospace, practice.

9.4.1.3 Focus of Software Evaluation

The software qualification tests encompass a number of interrelated examinations, involving assessment of application source code for its compliance with the requirements spelled out in Volume I, Section 4. Essentially, the ITA will look at programming completeness, consistency, correctness, modifiability, structuredness and traceability, along with its modularity and construction. The code inspection will be followed by a series of functional tests to verify the proper performance of all system functions controlled by the software.

The ITA may inspect COTS generated software source code in the preparation of test plans and to provide some minimal scanning or sampling to check for embedded code or unauthorized changes. Otherwise, the COTS source code is not subject to the full code review and testing. For purposes of code analysis, the COTS units shall be treated as unexpanded macros.

9.4.1.4 Focus of System-Level Integration Tests

The functionality, hardware, and software qualification tests supplement a fuller evaluation performed by the system-level integration tests. System-level tests focus on these aspects jointly, throughout the full range of system operations. They include tests of fully integrated system components, internal and external system interfaces, usability and accessibility, and security. During this process election management functions, ballot-counting logic, and system capacity are exercised. The process also includes the Physical Configuration Audit (PCA) and the Functional Configuration Audit (FCA).

The ITA tests the interface of all system modules and subsystems with each other against the vendor's specifications. Some, but not all, systems use telecommunications capabilities as defined in Section 5. For those systems that do use such capabilities, components that are located at the poll site or separate vote counting site are tested for effective Start Printed Page 18993interface, accurate vote transmission, failure detection, and failure recovery. For voting systems that use telecommunications lines or networks that are not under the control of the vendor (e.g., public telephone networks), the ITA tests the interface of vendor-supplied components with these external components for effective interface, vote transmission, failure detection, and failure recovery.

The security tests focus on the ability of the system to detect, prevent, log, and recover from a broad range of security risks as identified in Section 6. The range of risks tested is determined by the design of the system and potential exposure to risk. Regardless of system design and risk profile, all systems are tested for effective access control and physical data security. For systems that use public telecommunications networks, to transmit election management data or official election results (such as ballots or tabulated results), security tests are conducted to ensure that the system provides the necessary identity-proofing, confidentiality, and integrity of transmitted data. The tests determine if the system is capable of detecting, logging, preventing, and recovering from types of attacks known at the time the system is submitted for qualification. The ITA may meet these testing requirements by confirming the proper implementation of proven commercial security software.

The interface between the voting system and its users, both voters and election officials, is a key element of effective system operation and confidence in the system. At this time, general standards for the usability of voting systems by the average voter and election officials have not been defined, but are to be addressed in the next update of the Standards. However, standards for usability by individual voters with disabilities have been defined in Section 2.7 based on Section 508 of the Rehabilitation Act Amendments of 1998. Voting systems are tested to ensure that an accessible voting station is included in the system configuration and that its design and operation conforms with these standards.

The Physical Configuration Audit (PCA) compares the voting system components submitted for qualification to the vendor's technical documentation and confirms that the documentation submitted meets the requirements of the Standards. As part of the PCA, the ITA also witnesses the build of the executable system to ensure that the qualified executable release is built from the tested components.

The Functional Configuration Audit (FCA) is an exhaustive verification of every system function and combination of functions cited in the vendors' documentation. Through use, the FCA verifies the accuracy and completeness of the system's TDP. The various options of software counting logic that are claimed in the vendor's documentation shall be tested during the system-level FCA. Generic test ballots or test entry data for DRE systems, representing particular sequences of ballot-counting events, will test the counting logic during this audit.

9.4.1.5 Focus of Vendor Documentation Examination

The ITA reviews the documentation submitted by the vendor to evaluate the extent to which it conforms to the requirements outlined in Sections 7 and 8 for vendor configuration and quality assurance practices. The ITA also evaluates the conformance of other documentation and information provided by the vendor with the vendor's documented practices for quality assurance and configuration management.

The Standards do not require on-site examination of the vendor's quality assurance and configuration management practices during the system development process. However, the ITA conducts several activities while at the vendor site to witness the system build that enable assessment of the vendor's quality assurance and configuration management practices and conformance with them. These include surveys, interviews with individuals at all levels of the development team, and examination of selected internal work products such as system change requests and problem tracking logs.

9.4.2 Sequence of Tests and Audits

There is no required sequence for performing the system qualification tests and audits. For a new system, not previously qualified, a test using the generic test ballot decks might be performed before undertaking any of the more lengthy and expensive tests or documentation review. The ITA or vendor may, however, schedule the PCA, FCA, or other tests in any convenient order, provided that the prerequisite conditions for each test have been met before it is initiated.

9.5 Test Applicability

Qualification tests are conducted for new systems seeking initial qualification as well as for systems that are modified after qualification.

9.5.1 General Applicability

Voting system hardware, software, communications and documentation are examined and tested to determine suitability for elections use. Examination and testing addresses the broad range of system functionality and components, including system functionality for pre-voting, voting, and post-voting functions described in Section 2. All products custom designed for election use shall be tested in accordance with the applicable procedures contained in this section. COTS hardware, system software and communications components with proven performance in commercial applications other than elections, however, are exempted from certain portions of the test as long as such products are not modified for use in a voting system. Compatibility of these products all other components of the voting system shall be determined through functional tests integrating these products with the remainder of the system.

9.5.1.1 Hardware

Specifically, the hardware test requirements shall apply in full to all equipment used in a voting system with the exception of the following:

a. Commercially available models of general purpose information technology equipment that have been designed to an ANSI or IEEE standard, have a documented history of successful performance for relevant requirements of the standards, and have demonstrated compatibility with the voting system components with which they interface;

b. Production models of special purpose information technology equipment that have a documented history of successful performance under conditions equivalent to election use for relevant requirements of the standards and that have demonstrated compatibility with the voting system components with which they interface; and

c. Any ancillary devices that do not perform ballot definition, election database maintenance, ballot reading, ballot data processing, or the production of an official output report; and that do not interact with these system functions (e.g.; modems used to broadcast results to the press, printers used to generate unofficial reports, or CRTs used to monitor the vote counting process).

This equipment shall be subject to functional and operating tests performed during software evaluation and system-level testing. However, it need not undergo hardware non-operating tests. If the system is Start Printed Page 18994composed entirely of off-the-shelf hardware, then the system also shall not be subject to the 48-hour environmental chamber segment of the hardware operating tests.

9.5.1.2 Software

Software qualification is applicable to the following:

a. Application programs that control and carry out ballot processing, commencing with the definition of a ballot, and including processing of the ballot image (either from physical ballots or electronically activated images), and ending with the system's access to memory for the generation of output reports;

b. Specialized compilers and specialized operating systems associated with ballot processing; and

c. Standard compilers and operating systems that have been modified for use in the vote counting process.

Specialized software for ballot preparation, election programming, vote recording, vote tabulation, vote consolidation and reporting, and audit trail production shall be subjected to code inspection. Functional testing of all these programs during software evaluation and system-level testing shall exercise any specially tailored software off-line from the ballot counting process (e.g.; software for preparing ballots and broadcasting results).

9.5.2 Modifications to Qualified Systems

Changes introduced after the system has completed qualification under these Standards or earlier versions of the national Voting System Standards will necessitate further review.

9.5.2.1 General Requirements for Modifications

The ITA will determine tests necessary for to qualify the modified system based on a review of the nature and scope of changes, and other submitted information including the system documentation, vendor test documentation, configuration management records, and quality assurance information. Based on this review, the ITA may:

a. Determine that a review of all change documentation against the baseline materials is sufficient for recommendation for qualification; or

b. Determine that all changes must be retested against the previously qualified version (this will include review of changes to source code, review of all updates to the TDP, and a performance of system-level and functional tests); or

c. Determine that the scope of the changes is substantial and will require a complete retest of the hardware, software, and/or telecommunications.

9.5.2.2 Basis for Limited Testing Determinations

The ITA may determine that a modified system will be subject only to limited qualification testing if the vendor demonstrates that the change does not affect demonstrated compliance with these Standards for:

a. Performance of voting system functions;

b. Voting system security and privacy;

c. Overall flow of system control; and

d. The manner in which ballots are defined and interpreted, or voting data are processed.

Limited qualification testing is intended to facilitate the correction of defects, the incorporation of improvements, the enhancement of portability and flexibility, and the integration of vote-counting software with other systems and election software.

9.6 Qualification Test Process

The qualification test process may be performed by one or more ITAs that together perform the full scope of tests required by the Standards. Where multiple ITAs are involved, testing shall be conducted first for the voting system hardware, firmware, and related documentation; then for the system software and communications; and finally for the integrated system as a whole. Voting system hardware and firmware testing may be performed by one ITA independently of the other testing performed by other ITAs. Testing may be coordinated across ITAs so that hardware/firmware tested by one ITA can be used in the overall system tests performed by another ITA.

Whether one or more ITAs are used, the testing generally consists of three phases:

◆ Pre-test Activities;

◆ Qualification Testing; and

◆ Qualification Report Issuance and Post-test Activities.

9.6.1 Pre-test Activities

Pre-test activities include the request for initiation of testing and the pre-test preparation.

9.6.1.1 Initiation of Testing

Qualification testing shall be conducted at the request of the vendor, consistent with the provision of the Standards. The vendor shall:

a. Request the performance of qualification testing from among the certified ITAs,

b. Enter into formal agreement with the ITAs for the performance of testing, and

c. Prepare and submit materials required for testing consistent with the requirements of the Standards.

Qualification testing shall be conducted for the initial version of a voting system as well as for all subsequent changes to the system prior to release for sale or for installation. As described in Section 9.5.2, the nature and scope of testing for system changes or new versions shall be determined by the ITA based on the nature and scope of the modifications to the system and on the quality of system documentation and configuration management records submitted by the vendor.

9.6.1.2 Pre-test Preparation

Pre-test preparation encompasses the following activities:

a. The vendor shall prepare and submit a complete TDP to the ITA. The TDP should consist of the items listed in Section 9.2 and specified in greater detail in Standards Volume II;

b. The ITA shall perform an initial review of the TDP for completeness and clarity and request additional information as required;

c. The vendor shall provide additional information, if requested by the ITA;

d. The vendor and ITA shall enter into an agreement for the testing to be performed by the ITA in exchange for payment by the vendor; and

e. The vendor shall deliver to the ITA all hardware and software needed to perform testing.

9.6.2 Qualification Testing

Qualification testing encompasses the preparation of a test plan, the establishment of the appropriate test conditions, the use of appropriate test fixtures, the witness of the system build and installation, the maintenance of qualification test data, and the evaluation of the data resulting from tests and examinations.

9.6.2.1 Qualification Test Plan

The ITA shall prepare a Qualification Test Plan to define all tests and procedures required to demonstrate compliance with Standards, including:

a. Verifying or checking equipment operational status by means of manufacturer operating procedures;

b. Establishing the test environment or the special environment required to perform the test;

c. Initiating and completing operating modes or conditions necessary to evaluate the specific performance characteristic under test;

d. Measuring and recording the value or range of values for the characteristic to be tested, demonstrating expected performance levels; Start Printed Page 18995

e. Verifying, as above, that the equipment is still in normal condition and status after all required measurements have been obtained;

f. Confirming that documentation submitted by the vendor corresponds to the actual configuration and operation of the system; and

g. Confirming that documented vendor practices for quality assurance and configuration management comply with the Standards.

A recommended outline for the test plan and the details of required testing are contained in Standards Volume II.

9.6.2.2 Qualification Test Conditions

The ITA may perform Qualification tests in any facility capable of supporting the test environment. The following practices shall be employed:

a. Preparations for testing, arrangement of equipment, verification of equipment status, and the execution of procedures shall be witnessed by at least one independent, qualified observer, who shall certify that all test and data acquisition requirements have been satisfied;

b. When a test is to be performed at “standard” or “ambient” conditions, this requirement shall refer to a nominal laboratory or office environment, with a temperature in the range of 68 to 75 degrees Fahrenheit, and prevailing atmospheric pressure and relative humidity; and

c. Otherwise, all tests shall be performed at the required temperature and electrical supply voltage, regulated within the following tolerances:

(1) Temperature +/−4 degrees F

(2) Electrical supply voltage +/−2 vac.

9.6.2.3 Qualification Test Fixtures

ITAs may use test fixtures or ancillary devices to facilitate qualification testing. These fixtures and devices may include arrangements for automating the operation of voting devices and the acquisition of test data:

a. For systems that use a light source as a means of detecting voter selections, the generation of a suitable optical signal by an external device is acceptable. For systems that rely on the physical activation of a switch, a mechanical fixture with suitable motion generators is acceptable;

b. ITAs may use a simulation device, and appropriate software, to speed up the process of testing and eliminate human error in casting test ballots, provided that the simulation covers all voting data detection and control paths that are used in casting an actual ballot. In the event that only partial simulation is achieved, then an independent method and test procedure shall be used to validate the proper operation of those portions of the system not tested by the simulator; and

c. If the vendor provides a means of simulating the casting of ballots, the simulation device is subject to the same performance, reliability, and quality requirements that apply to the voting device itself.

9.6.2.4 Witness of System Build and Installation

Although most testing is conducted at facilities operated by the ITA, a key element of voting system testing shall be conducted at the vendor site. The ITA responsible for testing voting system software, telecommunications, and integrated system operation (i.e., system wide testing) shall witness the final system build, encompassing hardware, software and communications, and the version of associated records and documentation. The system elements witnessed, including their specific versions, shall become the specific system version that is recommended for qualification.

9.6.2.5 Qualification Test Data Requirements

The following qualification test data practices shall be employed:

a. A test log of the procedure shall be maintained. This log shall identify the system and equipment by model and serial number;

b. Test environment conditions shall be noted; and

c. All operating steps, the identity and quantity of simulated ballots, annotations of output reports, the elapsed time for each procedure step, and observations of equipment performance and, in the case of non-operating hardware tests, the condition of the equipment shall be recorded.

9.6.2.6 Qualification Test Practices

The ITA shall conduct the examinations and tests defined in the Test Plan such that all applicable tests identified in Standards Volume II are executed to determine compliance with the requirements in Sections 2-8 of the Standards. The ITA shall evaluate data resulting from examinations and tests, employing the following practices:

a. If any malfunction or data error is detected that would be classified as a relevant failure using the criteria in Volume II, its occurrence, and the duration of operating time preceding it, shall be recorded for inclusion in the analysis of data obtained from the test, and the test shall be interrupted;

b. If a malfunction is due to a defect in software, then the test shall be terminated and system returned to the vendor for correction;

c. If the malfunction is other than a software defect, and if corrective action is taken to restore the equipment to a fully operational condition within 8 hours, then the test may be resumed at the point of suspension;

d. If the test is suspended for an extended period of time, the ITA shall maintain a record of the procedures that have been satisfactorily completed. When testing is resumed at a later date, repetition of the successfully completed procedures may be waived, provided that no design or manufacturing change has been made that would invalidate the earlier test results;

e. Any and all failures that occurred as a result of a deficiency shall be classified as purged, and test results shall be evaluated as though the failure or failures had not occurred, if the:

(1) Vendor submits a design, manufacturing, or packaging change notice to correct the deficiency, together with test data to verify the adequacy of the change;

(2) Examiner of the equipment agrees that the proposed change will correct the deficiency; and

(3) Vendor certifies that the change will be incorporated into all existing and future production units; and

f. If corrective action cannot be successfully taken as defined above, then the test shall be terminated, and the equipment shall be rejected.

9.6.3 Qualification Report Issuance and Post-Test Activities

Qualification report issuance and post-test activities encompass the activities described below:

a. The ITA may issue interim reports to the vendor, informing the vendor of the testing status, findings to date, and other information. Such reports do not constitute official test reports for voting system qualification;

b. The ITA shall prepare a Qualification Test Report that confirms the voting has passed the testing conducted by the ITA. The ITA shall include in the Qualification Test Report the date testing was completed, the specific system version addressed by the report, the version numbers of all system elements separately identified with a version number by the vendor, and the scope of tests conducted. A recommended outline for the test report is contained in Volume II;

c. Where a system is tested by multiple ITAs, each ITA shall prepare a Qualification Test Report;

d. The ITA shall deliver the Qualification Test Report to the vendor and to NASED; Start Printed Page 18996

e. NASED shall issue a single Qualification Number for the system to the vendor and to the ITAs. The issuance of a Qualification Number indicates that the system has been tested by certified ITAs for compliance with the national test standards and qualifies for the certification process of states that have adopted the national standards;

f. This number applies to the system as a whole only for the configuration and versions of the system elements tested by the ITAs and identified in the Qualification Test Reports. The Qualification Number does not apply to individual system components or untested configurations; and

g. The Qualification Number is intended for use by the states and their jurisdictions to support state and jurisdiction processes concerning voting systems. States and their jurisdictions shall request ITA Qualification Test Reports based on the Qualification Number as part of their voting system certification and procurement processes systems that rely on the Standards.

9.6.4 Resolution of Testing Issues

The NASED Voting Systems Board (the Board) is responsible for resolving questions about the application of the Standards in the testing of voting systems. The Secretariat for the Board will relay its decisions to the NASED certified ITAs and voting system vendors. The Federal Election Commission will monitor these decisions in order to determine which of them, if any, should be reflected in a subsequent version of the standards.

Table of Contents

Volume I, Appendix A

A Glossary for Voting Systems

A.1 Glossary

A.2 Sources

A.3 List of Associations

A.4 List of Deprecated Terms

Glossary for Voting Systems

This glossary contains terms from the VSS-2002 as well as the inclusion of additional terms needed to understand voting and related areas such as security, human factors, and testing. Each term includes a definition and its source as well as an association, where

  • Source is the source from which the definition originates. A list of these sources is found in section A.2.
  • Association is the domain for which the term applies, e.g., voting, testing, security. There may be multiple domains identified for a term. There is no relevance given to the order in which the domains are listed. A list of these associations is found in section A.3.

At this time, a term may contain multiple definitions. The intent is to eventually select one definition per term, unless multiple definitions are necessary to convey the appropriate meanings of the term.

Some of the terms in the VSS-2002 have been deprecated due to changes in voting systems, voting process and/or mandates in HAVA. A list of these deprecated terms is in section A.4 List of Deprecated Terms.

A.1 Glossary

A

Abandoned Ballot: Ballot that the voter did not cast into the ballot box or record vote on DRE before leaving the polling place. See also fled voter.

Association: Voting.

Source: No attribution.

Absentee Ballot: Ballot prepared or designed for an absentee voter. Definition of an absentee ballot is jurisdiction dependent.

Association: Voting.

Source: No attribution.

Acceptance Testing: Examination of a voting system and its components by the purchasing election authority (usually in a simulated-use environment) to validate performance of delivered units in accordance with procurement requirements, and to validate that the delivered system is, in fact, the certified or qualified system purchased.

Association: Testing, voting.

Source: VSS.

Access Board: Independent federal agency devoted to accessibility for people with disabilities.

Association: Human factors, HF: Accessibility.

Source: No attribution.

Accessibility: Measurable characteristic that indicates the degree to which a system is available to, and usable by, individuals with disabilities. The most common disabilities include those associated with vision, hearing and mobility, as well as cognitive disabilities. The HAVA also includes accessibility requirements for Native American and Alaska Native citizens and alternative language access for voters with limited English proficiency.

Association: Human factors, HF: Accessibility.

Source: NIST HF Rpt, HAVA.

Accessible Voting Station (Acc-VS): Voting Station equipped for individuals with disabilities referred to in HAVA 301(a)(3)(B)

Association: HF: Accessibility, voting.

Source: HAVA.

Accreditation: (1) Formal recognition that a laboratory is competent to carry out specific tests or calibrations or types of tests or calibrations. (2) Procedure by which an authoritative body gives formal recognition that a body or person is competent to carry out specific tasks.

Association: Testing, standardization.

Source: (1) NIST HB 150, (2) ISO Guide 2-6.

Accreditation Body: (1) Authoritative body that performs accreditation. (2) An independent organization responsible for assessing the performance of other organizations against a recognized standard, and for formally confirming the status of those that meet the standard.

Association: Testing, conformity assessment.

Source: (1) ISO 17000, (2) IEEE 1583.

Accuracy: (1) Extent to which a given measurement agrees with an accepted standard for that measurement. (2) Closeness of the agreement between the result of a measurement and a true value of the particular quantity subject to measurement.

Note 1:

Accuracy is a qualitative concept. NOTE 2: The term precision should not be used for accuracy.

Association: Testing.

Source: (1) IEEE 1583, (2) VIM.

Accuracy for Voting Systems: Ability of the system to capture, record, store, consolidate and report the specific selections and absence of selections, made by the voter for each ballot position without error. Required accuracy is defined in terms of an error rate that for testing purposes represents the maximum number of errors allowed while processing a specified volume of data.

Association: Voting, testing.

Source: VSS.

Adequate Security: Security commensurate with the risk and the magnitude of harm resulting from the loss, misuse, or unauthorized access to or modification of information. See also risk assessment.

Association: Computer security.

Source: OMB A130.

Alternative Formats: In the context of voting systems, the ballot or accompanying information is said to be in an alternative format if it is in a representation other than the written English normally displayed to non-disabled English-literate voters. NOTE: The usual purpose of these formats is to provide accessibility to voters with disabilities or those with limited English proficiency. Examples include, but are not limited to, Braille, ASCII text, large print, recorded audio, and electronic formats that comply with Part 1194 of the standards for Section 508 of the Rehabilitation Act Amendments. Start Printed Page 18997

Association: HF: Accessibility.

Source: IEEE 1583, Section 508.

Alternative Language Voting Station (ALVS): voting station designed to be usable by voters who have limited English proficiency, i.e., cannot read English.

Association: HF: Accessibility, voting.

Source: No attribution.

Approval: Permission for a product or process to be marketed or used for stated purposes or under stated conditions. NOTE: Approval can be based on fulfillment of specified requirements or completion of specified procedures.

Association: Testing, conformity assessment.

Source: ISO 17000.

Attestation: Issue of a statement, based on a decision following review, that fulfillment of specified requirements has been demonstrated. NOTE: The resulting statement is also known as a statement of conformity.

Association: Testing, conformity assessment.

Source: ISO 17000.

Audio Ballot: Voter interface which provides the voter with audio stimuli and allows the voter to communicate intent to the voting system through vocalization or physical actions. See also ballot.

Association: Voting, human factors, HF: Accessibility.

Source: FL Statutes.

Audio-Tactile Interface (ATI): Voter interface designed so as not to require visual reading of a ballot. Audio is used to convey information to the voter and sensitive tactile controls allow the voter to convey information to the voting system.

Association: HF: Accessibility, voting.

Source: No attribution.

Audit: Systematic, independent, documented process for obtaining records, statements of fact or other relevant information and assessing them objectively to determine the extent to which specified requirements are fulfilled. NOTE: While audit applies to management systems, assessment applies to conformity assessment bodies as well as more generally.

Association: Testing, conformity assessment, security.

Source: ISO 17000.

Audit Trail: Recorded information that allows election officials to view the steps that occurred on the equipment included in an election to verify or reconstruct the steps followed without compromising the ballot or voter secrecy.

Association: Voting, security.

Source: No attribution.

Audit Trail for DRE: Paper printout of votes cast, produced by direct response electronic (DRE) voting machines, which election officials may use to crosscheck electronically tabulated totals.

Association: Voting, security.

Source: NASS.

Availability: Ensuring timely and reliable access to and use of information.

Association: Security.

Source: 44 U.S.C.

B

Ballot: (1) Physical record of the selections made by a voter in all of the races or contests in a particular election. Typically used in the context of hand-counted paper, punched card, or optical mark-sense ballots. When the ballot is recorded in electronic form, the term ballot image is preferred. (2) An official presentation of all of the contests to be decided in a particular election. These may be printed on the ballot (sense 1), printed on a ballot label (as used for punched-card and mechanical-lever voting machines), presented on a computer display screen, or in some alternative form such as audio. See also, audio ballot, ballot image, video ballot, electronic voter interface.

Association: Voting.

Source: No attribution.

Ballot Configuration: Particular set of contests to appear on the ballot for a particular election district, their order, the list of ballot positions for each contest, and the binding of candidate names to ballot positions.

Association: Voting.

Source: No attribution.

Ballot Counter: Counter in a voting device that counts the ballots cast in a single election or election test.

Association: Voting.

Source: VSS.

Ballot Counting Logic: Software logic that defines the combinations of voter choices that are valid and invalid on a given ballot and that determines how the vote choices are totaled in a given election. States differ from each other in the way they define valid and invalid votes and in their vote-counting procedures.

Association: Voting.

Source: VSS.

Ballot Format: One of any number of specific ballot configurations issued to the appropriate precinct. At a minimum, ballot formats differ from one another in content. They may also differ in size of type, graphical presentation, language used, or method of presentation (e.g., visual or audio). Also referred to as ballot style.

Association: Voting.

Source: VSS.

Ballot Image: (1) Electronically produced record of all votes cast by a single voter. (2) Record of all votes produced by a single voter. See also Cast Vote Record

Association: Voting.

Source: (1) VSS, (2) no attribution.

Ballot Instructions: The official instructional material presented with the ballot (sense 2) to the voter. In some contexts, this is in the form of an instructional poster in the voting booth, in some contexts, as text on the ballot label, in any form, presented to voters for expressing their selections in an election. This may be printed on the ballot (sense 1), presented in audio form, posted in the voting booth, printed on the ballot label or presented with the ballot presentation.

Association: Voting.

Source: No attribution.

Ballot Measure: A contest on ballot where the voter may vote yes or no. This term is typically used for referenda, amendments to state constitutions and tax questions, but not for yes/no votes in judicial retention races.

Association: Voting.

Source: No attribution.

Ballot Preparation: Process of using election databases or other means to select the specific contests and questions to be contained in a ballot format and related instructions; preparing and testing election-specific software containing these selections; producing all possible ballot formats; and validating the correctness of ballot materials and software containing these selections for an upcoming election.

Association: Voting.

Source: VSS.

Ballot Position: Abstract choice that is represented by a single line item where a vote may be recorded in a ballot or ballot image.

Association: Voting.

Source: VSS.

Ballot Production: Process of converting the ballot format to a medium ready for use in the physical ballot production or electronic presentation.

Association: Voting.

Source: VSS.

Ballot Rotation: Process of varying the order of the candidate names within a given contest to reduce the impact of voter bias towards the candidate(s) listed first.

Association: Voting.

Source: VSS.

Ballot Set: See ballot image.

Association: Voting. Start Printed Page 18998

Source: VSS.

Ballot Scanner: Device used to read the data from a marksense ballot.

Association: Voting.

Source: VSS.

Ballot Style: See ballot format.

Association: Voting.

Source: VSS.

Baseline: Product configuration that has been formally submitted for review against the VVSG, which thereafter serves as the basis for further development; and can be changed and offered to jurisdictions only through formal change control and requalification procedures (and/or recertification procedures where applicable).

Association: Voting, testing.

Source: VSS.

C

Calibration: Set of operations that establish, under specified conditions, the relationship between values indicated by a measuring instrument or measuring system, or values represented by a material measure, and the corresponding known values of a quantity intended to be measured.

Association: Testing.

Source: NIST HB 150.

Candidate: Person contending in a race for office. A candidate may be explicitly presented as one of the choices on the ballot or may be a write-in candidate.

Association: Voting.

Source: NIST HF Rpt.

Candidate Register: Record that reflects the total votes cast for the candidate. This record is augmented as each ballot is cast on a DRE or as digital signals from the conversion of voted paper ballots are logically interpreted and recorded.

Association: Voting.

Source: VSS, IEEE 1583.

Canvass: (1) Compilation of election returns and validation of the outcome that form the basis of the official results by political subdivision. (2) Compilation of election returns for validation and approval by the political subdivision of the outcome, which form the basis for the official results.

Association: Voting.

Source: (1) VSS, IEEE 1583, (2) no attribution.

Cast Ballot: Ballot in which voter has taken final action in the selection of candidates and measures and submits the ballot to the appropriate jurisdiction.

Association: Voting.

Source: No attribution.

Cast Vote Record (CVR): Permanent record of all votes produced by a single voter whether in electronic or paper copy form. Used for counting votes. Also referred to as ballot set or ballot image when used to refer to electronic ballots.

Association: Voting.

Source: (1) IEEE 1583.

Catastrophic System Failure: Total loss of function or functions, such as the loss or unrecoverable corruption of voting data or the failure of an on-board battery of volatile memory.

Association: Voting.

Source: VSS.

Central Counting: Counting of ballots in one or more locations selected by the election authority for the processing or counting, or both, of ballots.

Association: Voting.

Source: IL Statutes.

Certification: (1) Procedure by which a third party gives written assurance that a product, process or service conforms to specified requirements. (2) Third-party attestation related to products, processes, systems or persons. See also State Certification and EAC Certification.

Association: Testing, conformity assessment.

Source: (1) ISO Guide 2-6, (2) ISO 17000.

Certification Testing: Deprecated, replaced by State Certification. Note: This term is being clarified with respect to testing State or Federal Standards. See also EAC Certification.

Association: Testing, conformity assessment, voting.

Source: VSS.

Challenged Ballot: Ballot provided to individuals whose eligibility to vote has been questioned. Once voted, such ballots are not included in the tabulation until after the voter's eligibility is confirmed. See also provisional ballot.

Association: Voting.

Source: VSS.

Checksum: Computed value representing the sum of the contents of an instance of digital data; used to check whether errors have occurred in transmission or storage.

Association: Security.

Source: No attribution.

Claim of Conformance: Statement by a vendor proclaiming that a specific product conforms to a particular standard or set of standard profiles, a claim which is verified or refuted by a testing authority.

Association: Testing, conformity assessment.

Source: No attribution.

Client: Any person or organization that engages the services of a testing or calibration laboratory.

Association: Testing.

Source: NIST HB 150.

Closed Primary: Primary election in which voters receive a ballot listing only those candidates running for office in the political party with which the voters are affiliated, along with nonpartisan offices and ballot issues presented at the same election.

Association: Voting.

Source: VSS.

Commercial Off-the-Shelf (COTS): Commercial, readily available hardware devices (which may be electrical, electronic, mechanical, etc.; such as card readers, printers, or personal computers) or software products (such as operating systems, programming language compilers, database management systems, subsystems, components; software, etc.).

Association: IT.

Source: VSS, IEEE 1583.

Common Industry Format (CIF): Refers to the format described in ANSI/INCITS 354-2001 “Common Industry Format (CIF) for Usability Test Reports.”

Association: HF: Usability.

Source: ANSI 354.

Compliance point: Identified, testable requirement.

Association: Testing, conformity assessment.

Source: No attribution.

Component: (1) Element within a larger system; a component can be hardware or software. For hardware, a physical part of a subsystem that can be used to compose larger systems (e.g., circuit boards, internal modems, processors, computer memory). For software, a module of executable code that performs a well-defined function and interacts with other components. (2) Individual elements or items that collectively comprise a device, e.g., circuit boards, internal modems, processors, disk drives, and computer memory.

Association: IT.

Source: (1) No attribution, (2) VSS.

Confidentiality: (1) Prevention of unauthorized disclosure of information. (2) Preserving authorized restrictions on information access and disclosure, including means for protecting personal privacy and proprietary information.

Association: Security.

Source: (1) IEEE 1583, (2) 44 U.S.C.

Configuration Identification: Element of configuration management, consisting of selecting the configuration items for a system and recording their functional and physical characteristics in technical documentation.

Association: Testing, software engineering. Start Printed Page 18999

Source: IEEE 1583.

Configuration Item: Aggregation of hardware, software, or both that is designated for configuration management and treated as a single entity in the configuration management process.

Association: Testing, software engineering.

Source: IEEE 1583.

Configuration Management: Discipline applying technical and administrative direction and surveillance to identify and document functional and physical characteristics of a configuration item, control changes to these characteristics, record and report change processing and implementation status, and verify compliance with specified requirements.

Association: Testing, software engineering.

Source: IEEE 1583.

Configuration Management Plan: Document detailing the process for identifying, controlling and managing various released items (code, hardware, documentation etc.)

Association: Testing, software engineering.

Source: IEEE 1583.

Conformance: See conformity

Association: Testing, standardization.

Source: No attribution.

Conformance Testing: Process of testing an implementation against the requirements specified in one or more standards. The outcomes of a conformance test are generally a pass or fail result, possibly including reports of problems encountered during the execution. Also known as conformity assessment.

Association: Testing, standardization.

Source: NIST HB 150.

Conformity: Fulfillment by a product, process or service of specified requirements.

Association: Testing, standardization.

Source: ISO Guide 2-6.

Conformity Assessment: Demonstration that specified requirements relating to a product, process, system, person or body are fulfilled. See also testing, inspection, certification, accreditation, conformity assessment bodies.

Association: Testing, standardization.

Source: ISO 17000.

Conformity Assessment Body: Body that performs conformity assessment services. NOTE: An accreditation body is not a conformity assessment body.

Association: Testing, standardization.

Source: ISO 17000.

Consensus: General agreement, characterized by the absence of sustained opposition to substantial issues by any important part of the concerned interests and by a process that involves seeking to take into account the views of all parties concerned and to reconcile any conflicting arguments.

Association: Standardization.

Source: ISO Guide 2-4.

Contest: Decision to be made within an election, which may be a race for office or a referendum, propositions and/or questions. A single ballot may contain one or more contests.

Association: Voting.

Source: No attribution.

Count: Process of totaling votes.

Association: Voting.

Source: VSS, IEEE 1583.

Counted Ballot: Ballot that has been processed and whose votes are included in the candidate and measures vote totals.

Association: Voting.

Source: No attribution.

Corrective Action: Action taken to eliminate the causes of an existing deficiency or other undesirable situation in order to prevent recurrence.

Association: Testing.

Source: NIST HB 143.

Cross Filing: See Cross-party Endorsement.

Association: Voting.

Source: VSS.

Cross-party Endorsement: Endorsement of a single candidate or slate of candidates by more than one political party. The candidate or slate appears on the ballot representing each endorsing political party. Also referred to as cross filing.

Association: Voting.

Source: VSS, IEEE 1583.

Cryptographic Key: Value used to control cryptographic operations, such as decryption, encryption, signature generation or signature verification.

Association: Security.

Source: NIST SP 800-63.

Cryptography: Discipline that embodies the principles, means, and methods for the transformation of data in order to hide their semantic content, prevent their unauthorized use, or prevent their undetected modification.

Association: Security.

Source: NIST SP 800-59.

Cumulative Voting: Practice where voters are permitted to cast as many votes as there are seats to be filled. Voters are not limited to giving only one vote to a candidate. Instead, they can put multiple votes on one or more candidates.

Association: Voting.

Source: VSS, IEEE 1583.

D

Data Accuracy: (1) Data accuracy is defined in terms of ballot position error rate. This rate applies to the voting functions and supporting equipment that capture, record, store, consolidate and report the specific selections, and absence of selections, made by the voter for each ballot position. (2) The system's ability to process voting data absent internal errors generated by the system. It is distinguished from data integrity, which encompasses errors introduced by an outside source.

Association: Testing, security.

Source: (1) VSS, (2) IEEE 1583.

Data Integrity: Invulnerability of the system to accidental intervention or deliberate, fraudulent manipulation that would result in errors in the processing of data. It is distinguished from data accuracy that encompasses internal, system-generated errors.

Association: Security.

Source: IEEE 1583.

Decertification: Withdrawal of certification of voting system hardware and software.

Association: Testing, conformity assessment.

Source: HAVA.

Design Entity: Component of a design, named and referenced uniquely, that is both structurally and functionally different from other elements.

Association: Software engineering.

Source: IEEE 1583.

Design Entity Attributes: Named characteristic or property of a design entity, which provides a statement of fact about the entity. Attributes define the design entity and not the design process.

Association: Software engineering.

Source: IEEE 1583.

Designating Authority: Body established within government or empowered by government to designate conformity assessment bodies, suspend or withdraw their designation or remove their suspension from designation.

Association: Testing, conformity assessment.

Source: ISO 17000.

Designation: Governmental authorization of a conformity assessment body to perform specified conformity assessment activities.

Association: Testing, conformity assessment.

Source: ISO 17000.

Device: Functional unit that performs its assigned tasks as an integrated whole.

Association: IT.

Source: VSS.

Digital Signature: Asymmetric key operation where the private key is used Start Printed Page 19000to digitally sign an electronic document and the public key is used to verify the signature. Digital signatures provide authentication and integrity protection.

Association: Security.

Source: SP 800-63.

Direct Record Electronic (DRE) Voting System: Voting system that records votes by means of a ballot display provided with mechanical or electro-optical components that can be actuated by the voter, that processes the data by means of a computer program, and that records voting data and cast vote records in internal and/or external memory components. It produces a tabulation of the voting data stored in a removable memory component and/or in printed copy.

Association: Voting

Source: VSS, IEEE 1583.

Directly Verified: Voting system that allows the voter to verify at least one representation of his or her ballot with his/her own senses, not using any software or hardware intermediary. Examples of a directly verified voting system include DRE with a voter verified paper trail or marksense system. This is in contrast with an indirectly verified voting system.

Association: Voting, security.

Source: No attribution.

Disability: Disability means, with respect to an individual, (a) a physical or mental impairment that substantially limits one or more of the major life activities of such individual, (b) a record of such an impairment, or (c) being regarded as having such an impairment.

Association: Human factors, HF: Accessibility

Source: ADA.

DRE Display: Part of the DRE that displays the electronic record.

Association: Security, voting.

Source: No attribution.

DRE-VVPAT: DRE voting system containing VVPAT capability. See also Direct Record Electronic Voting System and Voter Verified Paper Audit Trail.

Association: Security, voting.

Source: No attribution.

Dynamic Voting System Software: Software that changes over time once it is installed on the voting equipment. See also voting system software.

Association: Voting.

Source: No attribution.

E

EAC: Election Assistance Commission.

Early Voting: Voter completes the ballot in person at a county office or other designated polling site or ballot drop site prior to Election Day. The ballot is cast and not retrievable. NOTE: Early voting is not the same as absentee voting. Also known as Early In-Person Voting.

Association: Voting.

Source: Electionline.

Election Coding: See Election Programming.

Association: Voting.

Source: IEEE 1583.

Election Databases: Data file or set of files that contain geographic information about political subdivisions and boundaries, all contests and questions to be included in an election, and the candidates for each contest.

Association: Voting.

Source: VSS, IEEE 1583.

Election Definition: Abstract definition of the races and questions that may appear on ballot forms.

Association: Voting.

Source: No attribution.

Election District: Geographic area represented by a public official who is elected by voters residing within the district boundaries. The district may cover an entire state or political subdivision, may be a portion of the state or political subdivision, or may include portions of more than one political subdivision.

Association: Voting.

Source: VSS, IEEE 1583.

Election Management System: Set of processing functions and databases within a Voting System that define, develop and maintain election databases, perform election definition and setup functions, format ballots, count votes, consolidate and report results, and maintain audit trails.

Association: Voting.

Source: VSS, IEEE 1583.

Election Officials: Term used to designate the group of people associated with conducting an election, including election personnel and poll workers.

Association: Voting.

Source: No attribution.

Election Programming: Process by which election officials or their designees use voting system software to logically define the ballot for a specific election.

Association: Voting.

Source: VSS, IEEE 1583.

Electronic Ballot Printer (EBP): DRE-like device that fully prints paper-based ballots with selected vote choices for tabulation by a separate ballot scanner.

Association: Voting.

Source: IEEE 1583.

Electronic Cast Vote Record (ECVR): Deprecated, replaced by Cast Vote Record (CVR).

Association: Voting.

Source: IEEE 1583.

Electronic Vote Capture System (EVCS): Election system that encompasses DREs as well as accessible ballot printers (ABPs) when they are combined with the ballot scanner that processes the printed ballot. See also Voter Verified Paper Audit.

Association: Voting.

Source: IEEE 1583.

Electronic Voter Interface: Subsystem within a DRE voting system which communicates ballot information to a voter in video, audio or Braille form and which allows the voter to select candidates and issues by means of vocalization or physical actions.

Association: Voting, Human factors, HF: Accessibility.

Source: FL Statutes.

Electronic Voting Machine: Any system that utilizes an electronic component. Term is generally used to refer to DREs. See also Voting Equipment, Voting System.

Association: Voting.

Source: NASS.

Electronically-Assisted Ballot Marker (EBM): Machines that provide assistance to voters who are visually impaired, who have difficulty reading English, or in other cases where a voter has difficulty correctly marking by hand a preprinted paper ballot that is to be counted in optical scan systems. The device marks, or helps to mark selected vote choices on a previously inserted, preprinted paper ballot. The machine then provides audio, tactile, or visual feedback to the voter on what choices they have made on the ballot. The resulting ballots are later tabulated on the same unit that processes ordinary hand-marked paper ballots.

Association: Voting, human factors.

Source: IEEE 1583.

Entity Relationship Diagram (ERD): A data modeling technique that creates a graphical representation of the entities, and the relationships between entities, within an information system.

Association: Software engineering.

Source: IEEE 1583.

Error correction code: Coding system that incorporates extra parity bits in order to detect errors.

Association: Security.

Source: WordNet.

E-Voting: (1) Term frequently used to refer to DREs and other types of electronic voting equipment, but may be misleading as it implies remote access via a computer network or the Internet. (2) Election system that allows a voter to record his or her secure and secret ballot electronically. See also DRE, Electronic Voting Machine. Start Printed Page 19001

Association: Voting.

Source: (1) NASS, (2) Whatis.com.

F

Federal Information Processing Standard (FIPS): Standard for adoption and use by federal agencies that has been developed within the National Institute of Standards and Technology (NIST) Information Technology Laboratory and published by NIST, an part of the U.S. Department of Commerce.

Association: Security, standardization.

Source: No attribution.

Firmware: Computer programs (software) stored in read-only memory (ROM) devices embedded in the system and not capable of being altered during system operation.

Association: IT.

Source: IEEE 1583.

Fled Voter: Voter who has begun the process of using voting equipment to cast a ballot and has exited the polling site without completing the casting of the ballot, thereby leaving the voting equipment in a state in which election procedures must be used to decide whether the fled voter's incomplete ballot will be cast before the voting equipment is reset. See also abandoned ballot.

Association: Voting.

Source: No attribution.

Font: Family or assortment of characters of a given size and style, e.g., 9-point Bodoni modern. See type font.

Association: Human factors, typography.

Source: ANSI Dict.

Functional Configuration Audit (FCA): Exhaustive verification of every system function and combination of functions cited in the vendor's documentation. Through use the FCA verifies the accuracy and completeness of the system's Voter Manual, Operations Procedures, Maintenance Procedures, and Diagnostic Testing Procedures.

Association: testing, voting.

Source: VSS, IEEE 1583.

Functional Test: Test performed to verify or validate the accomplishment of a function or a series of functions.

Association: Testing.

Source: VSS, IEEE 1583.

G

General Election: Election in which voters, regardless of party affiliation, are permitted to select persons to fill public office and vote on ballot issues. Where the public office may be filled by a candidate affiliated with a political party or when permitted by law, unaffiliated candidate and voters choose among the candidates.

Association: Voting.

Source: VSS, IEEE 1583.

H

Hash: Algorithm that maps a bit string of arbitrary length to a fixed-length bit string. Approved hash functions satisfy the following properties: (a) It is computationally infeasible to find any input that map to any prespecified output, and (b) it is computationally infeasible to find any two distinct inputs that map to the same output.

Association: Voting.

Source: NIST SP 800-63.

HAVA: Help America Vote Act of 2002.

Association: Voting.

Source: No attribution.

Human Computer Interaction: Discipline concerned with the design, evaluation and implementation of interactive computing systems for human use and with the study of major phenomena surrounding them.

Association: Human factors.

Source: ACM SIGCHI.

Human Factors (or Ergonomics): Scientific discipline concerned with the understanding of interactions among humans and other elements of a system, and the profession that applies theory, principles, data and methods to design in order to optimize human well-being and overall system performance.

Association: Human factors.

Source: IEA.

I

Indirectly Verified: Voting system that allows a voter to verify the ballot produced by his or her vote only via hardware or software intermediary. An example of an indirectly verified voting system is a touch screen DRE where the voter verifies the ballot through the assistance of audio stimuli. This is in contrast to directly verified voting systems.

Association: Voting, security.

Source: No attribution.

Implementation Conformance Statement: See Implementation Statement.

Implementation Statement: Statement by a vendor indicating the capabilities, features, and optional functions as well as extensions that have been implemented. Also known as implementation conformance statement.

Association: Testing.

Source: No attribution.

Independent Testing Authority (ITA): Deprecated, replaced by Voting System Testing Laboratory. Organization certified by the National Association of State Election Directors (NASED) to perform qualification testing.

Association: Testing, Voting.

Source: VSS.

Information Security: Protecting information and information systems from unauthorized access, use, disclosure, disruption, modification, or destruction in order to provide integrity, confidentiality, and availability.

Association: Security.

Source: 44 U.S.C.

Inspection: Examination of a product design, product, process or installation and determination of its conformity with specific requirements or, on the basis of professional judgment, with general requirements. NOTE: Inspection of a process may include inspection of persons, facilities, technology and methodology.

Association: Testing, conformity assessment.

Source: ISO 17000.

Integrity: (1) Prevention of unauthorized modification of information. (2) Guarding against improper information modification or destruction, and includes ensuring information non-repudiation and authenticity.

Association: Security.

Source: (1) IEEE 1583, (2) 44 U.S.C.

K

Key Management: Activities involving the handling of cryptographic keys and other related security parameters (e.g., passwords) during the entire life cycle of the keys, including their generation, storage, establishment, entry and output, and zeroization.

Association: Security.

Source: FIPS 140-2.

L

Logic and Accuracy Testing: Testing of the tabulator setups of a new election definition to ensure that the content correctly reflects the election being held (i.e., contests, candidates, number to be elected, ballot styles, etc.) and that all voting positions can be voted for the maximum number of eligible candidates and that results are accurately tabulated and reported.

Association: Voting, testing.

Source: IEEE 1583.

Logical Correctness: Condition signifying that, for a given input, a computer program will satisfy the program specification (produce the required output).

Association: Testing.

Source: VSS, IEEE 1583.

M

Marksense: System by which votes are recorded by means of marks made in Start Printed Page 19002voting response fields designated on one or both faces of a ballot card or series of cards. Marksense systems may use an optical scanner or similar sensor to read the ballots. Also known as Optical Scan.

Association: Voting.

Source: VSS, IEEE 1583.

Measure Register: Record that reflects the total votes cast for and against a specific ballot issue. This record is augmented as each ballot is cast on a DRE or as digital signals from the conversion of voted paper ballots are logically interpreted and recorded.

Association: Voting.

Source: VSS, IEEE 1583.

Mechanical Lever Voting Machine: Machine that directly records a voter's choices via mechanical level-actuated controls into a counting mechanism that tallies the votes without using a physical ballot.

Association: Voting.

Source: ME Statutes.