Chapter 1: Introduction

This part of the VVSG, Equipment Requirements, contains requirements applying to the voting system and the voting devices that it contains. It is intended primarily for use by manufacturers and testing labs. The Equipment Requirements may also be of use to election officials in setting requirements for voting systems in requests for proposals.

This part contains 8 chapters, organized as follows:

• Chapter 2: conformance-related information and requirements;
• Chapter 3: usability, accessibility, and privacy requirements;
• Chapter 4: auditing and records-related requirements;
• Chapter 5: security-related requirements;
• Chapter 6: core requirements;
• Chapter 7: requirements arranged by voting activity; and
• Chapter 8: reference models – process model, vote-capture device state model, and logic model.

No Comments for this section -- Comments Closed

1.1 Changes from VVSG 2005 and Previous Versions of the Standards

1.1.1 Conformance clause

The conformance clause has been expanded to define classes of voting systems and devices. Classes are an evolution of the notion of voting system "categories" that appeared in previous Guidelines. Those categories were paper-based, DRE, precinct count and central count.

The conformance clause also contains requirements for software independence, and the two methods for satisfying software independence in the VVSG:

• Use of independent voter-verified records (IVVR);
• The Innovation Class.

IVVR is a general category; voter-verified paper records (VVPR) is the only type of IVVR used by voting systems. In essence, only voting systems that use VVPR can currently conform to the VVSG unless new types of IVVR are developed.

The Innovation Class is a method for specifying new and innovative voting systems that meet the definition of software independence but in other ways besides IVVR.

No Comments for this section -- Comments Closed

1.1.2 Usability Performance Benchmarks

The usability requirements in VVSG 2005 contained requirements that are design-based. This version of the VVSG retains some of those requirements but also uses a new method based on summative usability testing that may more directly addresses the usability of the voting system, based on how accurately test participants are able to vote. The features of this new method include:

• The definition of a standard testing protocol, including a test ballot, set of tasks to be performed, and demographic characteristics of the test participants. The protocol supports the test procedure as a repeatable controlled experiment;
• The use of a substantial number of human subjects attempting to perform those typical voting tasks on the systems being tested, in order to achieve statistically significant results;
• The gathering of detailed data on the subjects' task performance, including data on accuracy, speed, and confidence;
• The precise definition of the usability metrics to be derived from the experimental data;
• The definition of effectiveness benchmarks against which systems will be evaluated.

No Comments for this section -- Comments Closed

1.1.3 Security requirements

The security requirements for voting systems have been expanded from VVSG 2005 to provide more complete coverage for different types of voting devices and for all phases of voting. Three entirely new sections have been added for voting device cryptography, event logging, and system integrity management. A number of other sections of security material from VVSG 2005 have been reworked and expanded.

VVSG 2005 contained a section on independent verification systems and VVPAT. This material has been largely reworked to focus on requirements on voting system records for voting systems that use independent voter-verifiable records (IVVR), including VVPAT and optical scan (which use one form of IVVR, voter-verifiable paper records (VVPR)). The concept of independent verification has been broadened to software independence.

The new section on voting device cryptography specifies that signatures for protecting electronic voting records used in audits be generated in an embedded hardware signature module, and includes a basic key management scheme. The new section on event logging expands logging requirements for voting devices and using secure log techniques.

The new section on system integrity management deals with operating system and application software security all system modes of voting. Some of the requirements are based on controls specified on technical standards for gaming machines [NGC06]. The requirements mandate secure boot loading and digital signature verification on binaries before loading. There are additional requirements on backups and expanded requirements from VVSG 2005 dealing with malware detection.

The access control section of VVSG 2005 now specifies baseline access controls for voting system resources such as data files, application programs, underlying operating systems, and voting system devices. The section specifies minimum types of authentication for role-based and identity-based access control.

The telecommunications and wireless communication sections of VVSG 2005 have been combined. A major difference is that this version of the VVSG prohibits radio frequency wireless in voting systems; VVSG 2005 restricted but did not prohibit radio frequency wireless.

The setup validation requirements in VVSG 2005 have been reworked into a newer section on software inspection. A major change in this section is that voting systems are no longer required to be capable of supporting a software setup validation technique that operates independently of the voting system. VVSG 2005 I.7.4.6 required this to be performed via a read-only external interface or by other means; this requirement has been removed in favor of requirements to support software independence and that verify digital signatures on binaries prior to loading.

No Comments for this section -- Comments Closed

1.1.4 Epollbooks and ballot activation

Requirements on ballot activation involving epollbooks have been added to Part 1: 7.5.1 “Issuance of voting credentials and ballot activation”. New requirements have been added primarily to protect integrity and privacy of ballot activation credential information and to ensure records on epollbooks and vote-capture devices cannot be aggregated to violate secrecy of the ballot. Epollbooks are permitted to activate the ballot while connected to an external voter registration database; various requirements on network security are included.

No Comments for this section -- Comments Closed

1.1.5 Common data format

Requirements dealing with making voting device interfaces and data formats transparent and interchangeable have been added to Part 1: 6.6 “Integratability and Data Export/Interchange”. Although these requirements do not mandate a specific standard data format, manufacturers are encouraged to use consensus-based, publicly available formats such as the OASIS Election Markup Language (EML) standard [OASIS07] or those emanating from the IEEE Voting System Electronic Data Interchange Project 1622 [P1622].

No Comments for this section -- Comments Closed

1.1.6 Core requirements

The core requirements for voting systems to define elections and to collect, count, and report votes have been expanded to specify what functionality must be provided in order to claim support for the many jurisdiction-specific voting variations such as cumulative voting, straight party voting, etc. In previous versions of the guidelines, manufacturers were required to identify which variations were supported and to document how those variations were supported, but the guidelines lacked any functional requirements on the variations. The new requirements define a baseline of functionality for each of the voting variations.

The requirements have been broadened to cover Electronically-assisted Ballot Markers (EBMs) and Electronic Ballot Printers (EBPs). These devices' combination of a DRE-like interface with a paper-based method of recording votes was something that previous versions of the guidelines did not handle.

The metric for reliability has been changed from Mean Time Between Failure (MTBF) to a failure rate based on volume that varies by device class and severity of failure. The metric for accuracy has been changed from ballot position error rate to report total error rate, and separate requirements referring to specific, low-level operations have been replaced with a single, general, end-to-end accuracy requirement. The metrics for multiple feed and rejection of ballots that meet all manufacturer specifications have been merged into a single "misfeed" metric. In each case, revised benchmarks have been derived from input from the Technical Guidelines Development Committee and election officials.

Significant changes have been made to the accuracy requirements for optical scanners. Previous versions of the guidelines required optical scanners to conform to a low error rate requirement when reading marks that were made to manufacturer specifications. This requirement has been retained, but is now supplemented by a requirement to read a standard mark made with a #2 pencil with the same level of accuracy. A related requirement to ignore "extraneous perforations, smudges and folds," which under some interpretations is unattainable with existing technology, has been adjusted to recognize that there is no mechanical way of determining whether a given mark that appears within a voting target is extraneous or not. This ties into the well-known problem of voter intent. Marks appearing outside of voting targets, on the other hand, are always extraneous—at least as far as standard behavior is concerned. Systems that support detection of circled voting targets and other marks that jurisdictions may consider to be valid votes must also support a baseline, standard mode of operation in which such marks are ignored.

Requirements and discussion on the handling of marginal marks have been added. See Part 1: 7.7.5.1 “Marginal marks”.

Requirements on the content of vote data reports, which appeared in several places and in different ways in previous versions of the guidelines, have been unified, harmonized, and clarified. Required contexts for reporting have been specified, and the concepts cast ballot, read ballot and counted ballot have been clearly distinguished. The quantities to be included in vote data reports have been formally defined using a logic model.

Other changes include

• Made compatible with early voting.
• Clarified that the redundant records stored by DREs are for recoverability purposes, and not to be confused with independent voter-verifiable records as specified in Part 1: 4.4 ”Independent Voter-Verifiable Records”.
• Clarified and generalized the prohibition on counter overflow.
• Specified that voting systems should flag any discrepancies in vote data reports that are detectable by the system.
• Added "should" requirements for reporting the count of blank ballots and for combined precinct reporting.
• Separated election administration concerns from product requirements.
• Replaced the term ballot format, which was inherited from [GPO90], with the term used in modern practice, ballot style.

No Comments for this section -- Comments Closed

1.1.7 Coding conventions

Volume 1, Section 5.2 and Volume 2, Section 5.4 of [VVSG2005] define coding conventions and a source code review to be conducted by test labs. That material has been substantially revised in these Guidelines.

[VVSG2005] Volume 1, Section 5.2.6 specifies that manufacturers be permitted to use current best practices in lieu of the coding conventions defined in the VVSG. However, the coding conventions in [VVSG2005] are not aligned with the modern state of the practice, and if followed, could do more harm than good. The misalignments are (1) that the conventions, some of which were carried over from [GPO90], are out of date, and (2) that the conventions, being limited by the requirement to remain language-neutral, are variously incomplete and/or inappropriate in the context of different programming languages with their different idioms and practices. The vast majority of coding conventions used in practice are tailored to specific programming languages.

In these Guidelines, the few coding conventions that have significant impact on integrity and transparency and that generalize relatively well to different programming languages have been retained, expanded, and made mandatory, while the many coding conventions that are language-sensitive and stylistic in nature, and are made redundant by more recent, publicly available coding conventions, have been removed in favor of the published conventions. Meanwhile, the evaluation of logical correctness that was underspecified in [VVSG2005] has been greatly enhanced (see Part 1: 6.4.1 “Software engineering practices”).

Prominent among the requirements addressing logical transparency is the requirement to use high-level control constructs and to refrain from using the low-level arbitrary branch (a.k.a. goto). As is reflected in Part 1: Table 6-4 , most high-level concepts for control flow were established by the time the first edition of the guidelines was published and are supported by all of the programming languages that were examined as probable candidates for voting system use as of this iteration. However, two additional concepts have been slower to gain universal support.

No Comments for this section -- Comments Closed

1.1.8 Applicability to COTS and borderline COTS products

To clarify the treatment of components that are neither manufacturer-developed nor unmodified COTS and to allow different levels of scrutiny to be applied depending on the sensitivity of the components being reviewed, new terminology has been introduced: application logic, border logic, configuration data, core logic, COTS (revised definition), hardwired logic, and third-party logic. Using this terminology, requirements have been scoped more precisely than they were in previous iterations of the Guidelines.

The new terminology obviates the software vs. firmware distinction that in practice has sometimes caused confusion. The requirements applying to application logic are not relaxed in any way if that logic is realized in firmware or hardwired logic instead of software. Consequently, the use of hardwired logic in an application logic capacity is all but prohibited, as it is unlikely to meet requirements such as Requirement Part 1: 6.4.1.2-A. It is expected that hardwired logic will be limited to COTS and border logic.

By requiring "many different applications," the definition of COTS deliberately prevents any application logic from receiving a COTS designation.

Details regarding the testing implications of these revisions are provided in Part 3: 1.1.2 “Applicability to COTS and borderline COTS products”.

No Comments for this section -- Comments Closed

1.1.9 Reference models

Part 1: 8.1 “Process Model (informative)” provides an informative model of the entire voting process.

Part 1: 8.2 “Vote-Capture Device State Model (informative)” provides an informative state model for vote-capture devices to clarify the definitions of voting session and active period, particularly for the case of early voting.

Part 1: 8.3 “Logic Model (normative)” provides normative terms and constraints for use in evaluating the correctness of voting system logic. Part 3: 4.6 “Logic Verification” describes the verification procedure.

No Comments for this section -- Comments Closed

1.1.10 Deletions

Requirements regarding the system's handling of unofficial data and reports have been deleted or converted to procedural requirements because the distinction between unofficial and official data is often outside the scope of the voting system. It is now assumed that any vote data present on a voting system and any reports that it generates are potentially official. Requirements on the reconciliation of provisional ballots and other activities involved in the creation of official data are unaffected by this change.

As discussed, prescriptive coding conventions not directly related to integrity and transparency have been deleted in favor of published, credible conventions.

Requirements on system and device availability have been deleted because they did not reflect the logistical overhead of repairing equipment on election day and because it is generally impossible to place precinct equipment back into service after it has been repaired on election day without raising concerns about possible tampering. Instead, Requirement Part 1: 6.3.1 “Reliability” has been tightened to discourage equipment from failing in the first place.

A requirement to designate one set of redundant electronic CVRs in a DRE as the "primary" set has been deleted because it prejudices the result of an audit.

Requirements that were redundant with the definitions of device classes (e.g., [VSS2002] I.2.4.3.2.1.b, all paper-based systems shall allow the voter to punch or mark the ballot to register a vote) have been deleted.

Requirements predicated on state law, local practices, software developed by the voting jurisdiction, and other variables that are indeterminate and untestable in the federal certification process have been deleted.

Requirements that were stated in terms of vague generalities, such as "appropriate" or "intended" options or behavior, for which no precise replacement could be determined and to which no testing value could be ascribed, have been deleted.

Vacuous requirements, such as "Be of any size and shape consistent with its intended use," have been deleted.

Redundant requirements, such as "Comply with the requirements of Section Y" when Section Y is already known to be applicable, have been deleted.

Informative text that was overtaken by changes in the requirements or the structure of the Guidelines has been deleted.

Definitions and requirements pertaining to punchcard technology have been deleted.

No Comments for this section -- Comments Closed

1.1.11 Supplemental Guidance

Throughout Part 1 are informative subsections titled "Procedures required for correct system functioning." The requirements in these subsections provide context for what the functional requirements specify or, more often, for what they omit. These requirements do not pertain to the voting system and are not tested by an accredited test lab.

No Comments for this section -- Comments Closed

Chapter 1: No Comments for this section -- Comments Closed