Your browser does not appear to support Javascript, please update your browser or contact your system administrator to enable Javascript on your Internet browser. Thank you. Chapter 4: Security and Audit Architecture — U.S. Election Assistance Commission
Skip to content

U.S. Election Assistance Commission

Personal tools
You are here: Home TGDC Recommended Guidelines Part 1: Equipment Requirements Chapter 4: Security and Audit Architecture
TGDC Recommended
Guidelines

VVSG Navigation
 

Chapter 4: Security and Audit Architecture

4.1 Overview

This chapter contains requirements pertaining to independent voter-verifiable record (IVVR) voting systems to ensure that they can be audited independently of their software. As part of this material, this chapter also includes basic requirements for voter-verifiable paper audit trail voting systems (VVPATs) that have been updated from [VVSG2005].

The requirements in this chapter are necessary to ensure that IVVR systems fully meet the definition of software independence. IVVR systems in general meet the SI definition because they produce two records that can be compared against each other: (1) the electronic version of the CVR, and (2) the IVVR summary of the electronic CVR that the voter has the opportunity to compare against the voting system’s display of the electronic CVR.

However, additional requirements are still needed for IVVR systems to ensure that the audits can be independently verifiable. IVVR records must be constructed carefully for this purpose; IVVR systems must produce other supporting records for the purposes of verifying that the number of electronic CVRs is correct and for the purposes of being able to verify that the records are indeed authentic and have been produced by the appropriate authorized voting systems. Accordingly, this chapter contains the following sections:

  • Section 4.2: high-level requirements to ensure that IVVR voting systems produce records that can be used in certain general types of independent audits;
  • Section 4.3: requirements for electronic records created and exported by IVVR voting systems; and
  • Section 4.4: requirements for IVVR and for VVPAT and PCOS voting systems that use voter-verifiable paper records (VVPR), i.e., paper IVVR.

4.2 Requirements for Supporting Auditing

This section presents requirements on voting system devices to provide the capability for certain general types of audits described herein. The audits work together to ensure independent agreement between what is presented to the voters by the IVVR vote-capture devices, what is counted by tabulators, and what is reported by the EMS as a final ballot count and vote totals.

Note: This section does not include requirements on election officials to perform the audits described herein. Audits are considered part of election procedures and cannot be mandated by the VVSG. The requirements in this section focus on ensuring that IVVR voting systems produce records that are capable of being used in independent audits so that the voting systems will meet. It is left to election procedures to mandate whether the audits are to be performed.

Auditing procedures for IVVR systems imposes requirements on the voting system in several ways, including:

  1. Some auditing procedures need to reconcile that the number of electronic CVRs captured by the voting system is indeed accurate, that this number agrees with the number of voters who have cast a ballots.
  2. Some auditing procedures need specific information or behavior from voting systems in order to be possible or practical. For example, hand auditing the correspondence between IVVR and electronic CVRs is only possible if the voting system produces IVVR and electronic CVRs that include the same information.
  3. Some auditing procedures require certain assurances about the operation of the voting devices in order to be meaningful. For example, the hand audit of the paper and electronic records from VVPATs is meaningful only because voters had the opportunity to both view and verify the paper records.

Accordingly, there are three general types of audits anticipated for IVVR voting systems to ensure that the electronic CVRs and IVVRs fully agree. These are as follows:

  1. Verifying that the number of voters for each reporting context and ballot style agrees with the totals reported by the tabulator. This guards against a tabulator reporting more votes than it had voters, or reassigning some voters to the wrong precinct or ballot style. This type of audit is referred to here as the pollbook audit.
  2. Verifying by hand that the IVVR agree with the reported totals from the tabulator. This guards against a voting device silently misrecording votes.
  3. Comparing IVVR vote-capture device records against final ballot and vote totals to verify that the electronic records from the tabulators agree with the final reported totals. This guards against a compromised EMS misreporting the final results.

4.2.1 Pollbook audit

The purpose of the pollbook audit is to verify that:

  • The total number of ballots recorded by the voting system in some location is the same as the total number of voters who have cast ballots.
  • The total number of ballots recorded for each ballot configuration, and for each reporting context, is the same as the number of such voters authorized to vote with that ballot configuration, in those reporting contexts.
  • This mitigates the threat that a tampered tabulator (such as a PCOS scanner) might have inserted or deleted votes, and also the threat that it may have assigned some voters the wrong reporting context or ballot configuration to prevent them voting in certain elections or to dilute the effect of their votes.
4.2.1-A Voting system, support for pollbook audit

The voting system SHALL support a secure pollbook audit that can detect differences in ballot counts between the pollbooks, vote-capture devices, activation devices, and tabulators.

Applies To: Voting system

Test Reference: Part 3: 4.3 “Verification of Design Requirements”, 5.2 “Functional Testing”, 5.3 “Benchmarks”

DISCUSSION

The pollbook audit is critical for blocking various threats on voting systems, such as simply inserting additional votes into the voting system. This requirement and its subrequirement are high-level “goal” requirements whose aim is to ensure that the voting system produces records that are adequate and usable by election officials for conducting pollbook audits. This requirement is supported by various other requirements for general reporting and in Part 1:4.3 “Electronic Records”. It can be tested as part of the volume tests discussed in Part 1:7.8 “Reporting” and Part 3:5.3 “Benchmarks”; this type of testing may be useful for assessing the usability of the audit records for typical election environments.

Source: [VVSG2005] I.2.1.5.1

4.2.1-A.1 Records and reports for pollbook audit

Vote-capture devices, activation devices, and tabulators SHALL support production and retention of records and reports that support the pollbook audit.

Applies To: Vote-capture device, Tabulator, Activation device

Test Reference: Part 3: 5.2 “Functional Testing”, 5.3 “Benchmarks”

DISCUSSION

The pollbook audit is only practical when the number of ballots, and of each distinct type of ballot, is available from both the pollbooks and the tabulators.

Source: [VVSG2005] I.5.4.4

4.2.2 Hand audit of IVVR record

The hand audit of verifies that the IVVRs and reported totals from a tabulator are in agreement. The hand audit addresses the threats that the voting device might record and report results electronically that disagree with the choices indicated by the voter.

4.2.2-A IVVR, support for hand audit

The voting system SHALL support a hand audit of IVVRs that can detect differences between the IVVR and the electronic CVR.

Applies To: Voting system

Test Reference: Part 3: 5.2 “Functional Testing”, 5.3 “Benchmarks”

DISCUSSION

Hand auditing verifies the reported electronic records; IVVR offer voters an opportunity to discover attempts to misrecord their votes on the IVVR, and the hand audit ensures that devices that misrecord votes on the electronic record but not the IVVR are very likely to be caught.

Hand auditing draws on the results from the pollbook audit and the ballot count and vote total. For example, the hand audit cannot detect insertion of identical invalid votes in both paper and electronic records in a VVPAT, but the pollbook audit can detect this since it reconciles the electronic CVR count with the number of voters who cast ballots. Similarly, the hand audit cannot detect that the summary of reported ballots from the tabulator or polling place agrees with the final election result, but this can be checked by the ballot count and vote total audit.

This requirement and its subrequirement are high-level “goal” requirements whose aim is to ensure that the voting system produces records that are adequate and usable by election officials for conducting audits of IVVR records by hand. It can be tested as part of the volume tests discussed in Part 1: 7.8 “Reporting” and Part 3: 5.3 “Benchmarks”; this type of testing may be useful for assessing the usability of the audit records for manual audits in typical election volumes.

Source: [VVSG2005] I.2.1.5.1

4.2.2-A.1 IVVR, information to support hand auditing

IVVR vote-capture devices and tabulators SHALL provide information to support hand auditing of IVVR.

Applies To: IVVR vote-capture device, Tabulator

Test Reference: Part 3: 4.3 “Verification of Design Requirements”, 5.2 “Functional Testing”, 5.3 “Benchmarks”

DISCUSSION

The electronic summary information from the DRE or scanner and the IVVRs, must contain sufficient information to carry out the hand audit. Because the hand audit may be carried out at different reporting contexts (for example, a specific tabulator or a whole precinct or polling place may be selected for audit), the voting system must be able to provide reports that support hand auditing at each of the different reporting contexts.

Source: [VVSG2005] I.5.4.4

4.2.3 Ballot count and vote total audit

The purpose of this process is to verify that the ballot counts and vote totals reported by EMSs are correct. This guards against the threat that the EMS used to produce the final results might be compromised. Please see Part 1: 7.8 “Reporting”, Reporting, for information on ballot count and vote total reports.

4.2.3-A EMS, support for reconciling voting device totals

The EMS SHALL support the reconciliation of the tabulator totals and the final ballot count and vote totals according to the following:

  1. A tabulator whose reported totals are not correctly included in the ballot count and vote total reports, and which is audited, SHALL be detectable;
  2. A difference between the final ballot count and vote totals and the audit records for a tabulator that is audited SHALL be detectable;
  3. The disagreements in records SHALL be detectable even when the election management software is acting in a malicious way; and
  4. The EMS SHALL be able to provide reports that support ballot count and vote total auditing for different reporting contexts.

Applies To: EMS

Test Reference: Part 3: 4.3 “Verification of Design Requirements”, 5.2 “Functional Testing”, 5.3 “Benchmarks”

DISCUSSION

This auditing process, part of the canvassing procedure, is a defense against problematic behavior by the voting device computing the final election ballot count and vote totals. Section 4.3 includes requirements to make this procedure easier to carry out and to add cryptographic protection to the records produced by the voting devices. One complication in making a full voting system support this procedure is the likely mixing of old and new voting devices in a full voting system.

When the specific reporting context used is the same as for the hand audit, the ballot count and vote totals audit and hand audit together verify that the votes that appear on the IVVR correspond to the votes that are reported in the final election result.

This requirement and its subrequirement can be tested as part of the volume tests discussed in Part 1 Section 7.8 and Part 3 Section 5.3.

4.2.3-B Records for ballot count/vote total audit

Vote-capture devices, tabulators, and activation devices SHALL produce records that support the ballot count and vote total audit.

Applies To: Vote-capture device, Tabulator, Activation device

Test Reference: Part 3: 5.2 “Functional Testing”, 5.3 “Benchmarks”

DISCUSSION

This auditing step requires that electronic summary records from voting devices can be reconciled with the final election ballot count and vote total reports. The ballot count and vote total records must thus be capable of breaking down totals by voting device as well as by precinct and polling place.

Sections 4.3 and 4.4 specify content of the IVVR and electronic records, respectively, needed to support this requirement.

4.2.4 Additional behavior to support auditing for accessible IVVR voting systems

Another issue in the operational behavior of accessible IVVR voting systems needs to be considered to ensure that they are software independent and independently auditable.

Accessible IVVR systems that provide an audio readback of the IVVR (e.g., a VVPAT’s VVPR) may use the same software base to do the following:

  • Permit the voter to make ballot choices;
  • Create the IVVR of the voter’s ballot choices; and
  • Read back to the voter the IVVR.

To ensure that the accessible IVVR vote-capture device is interacting with the voter properly and recording voting choices accurately, the accessible IVVR voting system must allow for all voters to

  1. Cast their votes using assistive technology such as the audio-tactile interface even if the voters do not require this technology to be able to vote, and
  2. Verify the IVVR record with the audio readback.

Election procedures must actually ensure that sufficient numbers of voters use the accessible IVVR voting system in this way to ensure that the audio readback matches the IVVR record. These voters are able to confirm that both the IVVR and audio ballots contain the same information.This guards against the voting device selectively misrecording votes of voters with disabilities. For the purposes of discussion in this section, this type of voter behavior is referred to as Observational Testing.

4.2.4-A IVVR vote-capture device, observational testing

IVVR vote-capture devices that support assistive technology SHALL support Observational Testing.

Applies To: IVVR vote-capture device ^ Acc-VS

Test Reference: Part 3: 5.2 “Functional Testing”

DISCUSSION

Blind, partial vision, and non-written languages voters may not be able to directly verify the IVVR produced by the voting system. This may be because they are using the audio-tactile interface, magnified screen images, or other assistive technology. This raises the possibility that a malicious IVVR vote-capture device could modify these voters’ votes by simply recording the wrong votes on both electronic records and IVVRs. Observational testing provides a defense by using volunteer voters. When observational testing is in use, a malicious IVVR vote-capture device cannot safely assume that a voter using the audio-tactile interface will be unable to check the IVVR record.

Source: New requirement

4.2.4-B IVVR vote-capture device, authentication for observational testing

The mechanism for authenticating the voter to the accessible IVVR vote-capture device SHALL NOT allow the IVVR vote-capture device to distinguish whether a voter is performing Observational Testing. The pollworker issuing the ballot activation for voters performing Observational Testing SHALL NOT be capable of signaling to the IVVR vote-capture device that it is being tested.

Applies To: IVVR vote-capture device ^ Acc-VS, Activation device

Test Reference: Part 3: 5.2 “Functional Testing”

DISCUSSION

Observational testing would not detect attacks if the IVVR vote-capture device were somehow alerted that the voter was carrying out observational testing. Thus, the authentication mechanism must not permit the device to discover this fact.

Source: New requirement

4.3 Electronic Records

In order to support independent auditing, an IVVR voting system must be able to produce electronic records that contain the needed information in a secure and usable manner. Typically, this includes records such as:

  • Vote counts;
  • Counts of ballots recorded;
  • Information that identifies the electronic record;
  • Event logs and other records of important events or details of how the election was run on this device; or
  • Election archive information.

By ensuring that certain records are produced, secured, and exported, many threats to security can be reduced, including tampering with electronic records in transit from the polling place to the tabulation center, tampering with the operation of the tabulation center, or altering election records after the totals are determined.

There are three types of requirements on electronic records in this section:

  1. Requirements for how electronic records must be protected cryptographically;
  2. Requirements for which electronic records must be produced by tabulators; and
  3. Requirements for printed reports to support auditing steps.

4.3.1 Records produced by voting devices

The following requirements apply to records produced by the voting system for any exchange of information between devices, support of auditing procedures, or reporting of final results. This includes the electronic version of all reports specified in Part 1: 5.1 “Cryptography”.

4.3.1-A All records capable of being exported

The voting system SHALL provide the capability to export its electronic records to files.

Applies To: Voting system

Test Reference: Part 3: 5.2 “Functional Testing”

DISCUSSION

The exported format for the records must meet the requirements for data export in Part 1: 6.6 “Integratability and Data Export/Interchange”.

Source: New requirement

4.3.1-B All records capable of being printed

The voting system SHALL provide the ability to produce printed forms of its electronic records.

  1. The printed forms SHALL retain all required information as specified for each record type other than digital signatures;
  2. The printing MAY be done from a different device than the voting device that produces the electronic record; and
  3. It shall be possible to print records produced by the central tabulator or EMS on a different device.

Applies To: Voting system

Test Reference: Part 3: 5.2 “Functional Testing”

DISCUSSION

Printed versions of all records in this chapter are either necessary or extremely helpful to support required auditing steps. Ensuring that the printing can be done from a machine other than the tabulator used to compute the final totals for the election supports the vote total audit, and is a logical consequence of the requirement for a fully open record format.

Source: [VVSG2005] I.2.1.5.1-a

4.3.1-C Cryptographic protection of records from voting devices

Electronic records SHALL be digitally signed with the Election Signature Key.

Applies To: Voting system

Test Reference: Part 3: 4.5 “Source Code Review”, 5.2 “Functional Testing”

DISCUSSION

The digital signatures address the threat that the records might be tampered with in transit or in storage. When combined with the Election Public Key Certificate, the signature also addresses the threat that a legitimate electronic record might be misinterpreted as coming from the wrong voting device or scanner. The use of per-election keys to sign these records addresses the threat that a compromise of a voting device before or after election day might permit production of a false set of records for the election, which could then be reported to the EMS.

This requirement mandates a similar optional recommendation in [VVSG2005] 7.9.3-d which applies only to VVPATs. There is no requirement that states that all electronic records must be signed in the [VVSG2005].

Source: [VVSG2005] I.7.9.3-d

4.3.2 Records produced by tabulators

The following requirements apply to records produced by tabulators, such as DREs and optical scanners, for exchange of information between devices, transmission of results to the EMS, support of auditing procedures, or reporting of intermediate election results.

4.3.2-A Tabulator, summary count record

Each tabulator SHALL produce a tabulator Summary Count record including the following:

  1. Device unique identifier from the X.509 certificate;
  2. Time and date of summary record;
  3. The following, both in total and broken down by ballot configuration and precinct:
    1. Number of read ballots;
    2. Number of counted ballots;
    3. Number of rejected electronic CVRs; and
    4. For each N-of-M (including 1-of-M) or cumulative voting contest appearing in any ballot configuration handled by the tabulator:
      1. Number of counted ballots that included that contest, per the definition of K(j,r,t) in Part 1: Table 8-2 ;
      2. Vote totals for each non-write-in contest choice per the definition of T(c,j,r,t) in Part 1: Table 8-2 ;
      3. Number of write-in votes;
      4. Number of overvotes per the definition of O(j,r,t) in Part 1: Table 8-2 ; and
      5. Number of undervotes per the definition of U(j,r,t) in Part 1: Table 8-2.

In producing this summary count record, the tabulator shall assume that no provisional or challenged ballots are accepted.

Applies To: Tabulator

Test Reference: Part 3: 4.5 “Source Code Review”, 5.2 “Functional Testing”

DISCUSSION

The Tabulator Summary Count Record is essentially an estimated summary report from the viewpoint of the individual tabulator, for auditing purposes. Since the eventual disposition of provisional ballots, challenged ballots, and write-in votes is unknown at the close of polls, arbitrary assumptions are made in order to make a summary possible. All provisional and challenged ballots are assumed rejected, and all write-in votes are effectively aliased to a single contest choice that is not one of the choices "on the ballot." The quantities provided for each contest should balance in the sense that

N × K = sum of non-write-in vote totals (T) + write-ins + overvotes (O) + undervotes (U).

In addition to the reporting context corresponding to the tabulator itself, reporting contexts corresponding to the different ballot configurations handled by that tabulator are synthesized. These contexts are quite narrow in scope as they include only the ballots of a specific configuration that were counted by a specific tabulator. The tabulator is not required to handle the complexities of reporting contexts that are outside of its scope.

This record is sufficient to support random audits of paper records. The record will not contain the results of election official review of review-required ballots, so auditors can use this record to verify that the number of these ballots is correct, but will need to do further steps to verify that these ballots were handled correctly. This record can be used to verify a correct result from a system under parallel testing. This record can be used to randomly check electronic totals, when the final results are given broken out by voting system or scanner. When used in the Ballot Count and Vote Total Audit, this record blocks the class of attacks that involves tampering with the EMS computer used to compute the final totals. The tabulator summary could in principle be published for each voting system, along with corrected final totals for each precinct and for absentee ballots, to show how the final election outcomes were computed, though care would have to be taken to avoid violations of voter privacy.

For auditing, this record must be output in a human-readable format, such as a printed report.

This requirement clarifies [VVSG2005] I.2.4.3, which describes the vote data summary reports that all voting systems are required to produce. While [VVSG2005] I.2.4.3 applies to voting systems as a whole, this requirement specifically requires that all vote tabulators produce such a report.

Source: [VVSG2005] I.2.4.3

4.3.2-B Tabulator, summary count record handling

The tabulator SHALL handle the summary count record according to the following:

  1. The record SHALL be transmitted to the EMS with the other electronic records;
  2. It SHALL be stored in the election archive, if available; and
  3. It SHALL be stored in the voting systems event log.

Applies To: Tabulator

Test Reference: Part 3: 5.2 “Functional Testing”

Source: New requirement

4.3.2-C Tabulator, collection of ballot images record

Tabulators SHOULD produce a record of ballot images that includes:

  1. Time and date of creation of complete ballot image record; and
  2. ballot images recorded in randomized order by the DRE for the election. For each voted ballot, this includes:
    1. ballot configuration and counting context;
    2. Whether the ballot is accepted or rejected;
    3. For each contest:
      1. The choice recorded, including undervotes and write-ins; and
      2. Any information collected by the vote-capture device electronically about each write-in;
    4. Information specifying whether the ballot is provisional, and providing unique identifier for the ballot, as well as provisional category information required to support Requirement Part 1: 7.7.2-A.6.

Applies To: Tabulator

Test Reference: Part 3: 5.2 “Functional Testing”

DISCUSSION

This record is not required for auditing, however it is useful.

Source: New requirement

4.3.2-C.1 DRE, collection of ballot images record

DREs SHALL produce a record of ballot images that includes:

  1. Time and date at poll closing; and
  2. ballot images recorded in randomized order by the DRE for the election. For each voted ballot, this includes:
    1. ballot configuration and counting context;
    2. Whether the ballot is accepted or rejected;
    3. For each contest:
      1. The choice recorded, including undervotes and write-ins; and
      2. Any information collected by the vote-capture device electronically about each write-in;
    4. Information specifying whether the ballot is provisional, and providing unique identifier for the ballot, as well as provisional category information required to support Requirement Part 1: 7.7.2-A.6.

Applies To: DRE

Test Reference: Part 3: 5.2 “Functional Testing”

DISCUSSION

DREs already contain the information to create the ballot image records.

This requirement extends [VVSG2005] I.7.9.3-b by requiring an audit record containing electronic ballot images, and specifies other information that must be contained in this record. This requirement extends [VVSG2005] I.7.9.3-e by requiring that VVPATs produce an audit record containing electronic ballot images. [VVSG2005] I.7.9.3-e only requires that electronic ballot images be exportable for auditing purposes.

Source: [VVSG2005] I.7.9.3-b, I.7.9.3-e

4.3.2-C.2 Tabulator. collection of cast votes handling

Tabulators that produce the collection of ballot images record SHALL handle the record according to the following:

  1. The record SHALL be transmitted to the EMS with the other electronic records;
  2. It SHALL be stored in the election archive, if available; and
  3. It SHALL be stored in the voting systems event log.

Applies To: Tabulator

Test Reference: Part 3: 5.2 “Functional Testing”

Source: New requirement

The tabulator SHALL digitally sign the event log, transmit the signed event log to an EMS, and retain a record of the transmission.

Applies To: Tabulator

Test Reference: Part 3: 5.2 “Functional Testing”

DISCUSSION

The EMS can verify that the event log record is received and that the digital signature and per election key and certificate are valid.

Source: New requirement

4.3.3 Records produced by the EMS

The following requirements apply to the records produced by an EMS. EMSs include both DREs used as accumulators in the polling place, called a Precinct EMS, as well as EMSs used as jurisdiction-wide accumulators. All of the requirements for tabulators apply to EMSs. This section addresses additional requirements based on an EMSs role as an accumulator of ballot counts and vote totals.

4.3.3-A EMS tabulator summary count record

The EMS tabulator Summary Count Record SHALL include:

  1. Unique identifiers for each tabulator contained in the summary;
  2. For tabulators with public keys:
    1. The public key for each tabulator in the summary;
    2. The Election Signature Key certification and closeout record; and
    3. Signed tabulator summary count record.
  3. Summary ballot counts and vote totals by tabulator, precinct, and polling place.
    1. Precinct totals include subtotals from each tabulator used in the precinct.

Applies To: EMS

Test Reference: Part 3: 4.5 “Source Code Review”, 5.2 “Functional Testing”

DISCUSSION

Requirements in Part 1 Section 7.8 ensure that the EMS is capable of producing a report containing this information. This report is required to allow checking of the final ballot counts and vote totals, based on their agreement with local totals, without relying on the correct operation of equipment and execution of procedures at the tabulation center. The goal is to provide cryptographic support for a process that is currently done in a manual, procedural way, which may be subject to undetected error or tampering. This record can be used to detect most problems at the tabulation center. Item c.1 is needed for cases when a tabulator, such as a DRE, contains votes from multiple precincts. Note: The requirement supports older voting systems to allow for transitioned upgrades of fielded equipment.

This requirement extends [VVSG2005] I.2.4.3; this requirement specifically requires that each tabulation center EMS produce this report.

Source: [VVSG2005] I.2.4.3

4.3.3-A.1 Tabulator, report combination for privacy

The EMS SHALL be capable of combining tabulator reports to protect voter privacy in cases when there are tabulators with few votes.

Applies To: EMS

Test Reference: Part 3: 5.2 “Functional Testing”

DISCUSSION

4.3.3-B EMS, precinct summary count records

The EMS SHALL produce a report for each precinct including:

  1. Each tabulator included in the precinct with its unique identifier;
  2. Number of read ballots;
  3. Number of counted ballots;
  4. Number of rejected electronic CVRs; and
  5. For each N-of-M (including 1-of-M) or cumulative voting contest appearing in any ballot configuration handled by the tabulator:
    1. Number of counted ballots that included that contest, per the definition of K(j,r,t) in Part 1: Table 8-2 ;
    2. Vote totals for each non-write-in contest choice per the definition of T(c,j,r,t) in Part 1: Table 8-2 ; and
    3. Number of write-in votes

Applies To: EMS

Test Reference: Part 3: 4.5 “Source Code Review”, 5.2 “Functional Testing”

DISCUSSION

This report supports hand auditing of paper records against the final totals, the ballot count and vote totals audit, and the pollbook audit.

This requirement extends [VVSG2005] I.2.4.3; this requirement specifically requires that each tabulation center EMS produce the report.

Source: [VVSG2005] I.2.4.3

4.3.3-C EMS, precinct adjustment record

The EMS SHALL produce a report showing the changes made to each contest based on the resolution of provisional ballot, challenged ballots, write-in choices, and the date and time of the report.

Applies To: EMS

Test Reference: Part 3: 5.2 “Functional Testing”

DISCUSSION

This report may be produced more than once during the course of an election as the resolution of provisional ballots, challenged ballots, and write-in choices are processed. This report can be used to support pollbook audit showing that number of ballots processed do not exceed the total recorded by the tabulator as well as to support the ballot total and vote count audit. Many jurisdictions resolve provisional and challenged ballots in groups to protect voter privacy.

Source: New requirement

4.3.4 Digital signature verification

4.3.4-A Tabulator, verify signed records

For each tabulator producing electronic records, the EMS SHALL verify:

  1. The Election Public Key Certificate associated with the record is valid for the current election, using the public key of the tabulator to verify the certificate as specified in Part 1: 5.1 “Cryptography”;
  2. The election ID and timestamp of the record agrees with the current election and the values in the Election Public Key Certificate; and
  3. The digital signature on the record is correct, using the Election Public Key to verify it.

Applies To: EMS

Test Reference: Part 3: 4.5 “Source Code Review”, 5.2 “Functional Testing”

DISCUSSION

The digital signature applied to the electronic records from the voting devices is only useful if it is verified before the EMS accepts electronic records. A DRE that accumulates results at a precinct or polling place is serving as a precinct level EMS.

Source: New requirement

4.3.5 Ballot counter

4.3.5-A Ballot counter

Tabulators and vote-capture devices SHALL maintain a count of the number of ballots read at all times during a particular test cycle or election.

Applies To: Tabulator, Vote-capture device

Test Reference: Part 3: 3.2 “Functional Testing”

DISCUSSION

For auditability, the ballot count must be maintained (incremented each time a ballot is read) rather than calculated on demand (by counting the ballots currently in storage). This requirement restates [VVSG2005] I.2.1.8.

Source: Implied by design requirements in [VSS2002] I.2.2.9, [VVSG2005] I.2.1.8

4.3.5-B Ballot counter, availability

Tabulators SHALL enable election judges to determine the number of ballots read at all times during a particular test cycle or election without disrupting any operations in progress.

Applies To: Tabulator, Vote-capture device

Test Reference: Part 3: 3.2 “Functional Testing”

DISCUSSION

[VSS2002] I.2.4 refers to separate “election counter” and “life-cycle counter;” the latter was an error (intended to delete). This requirement clarifies [VVSG2005] I.2.1.8 by stating that reading the ballot counter must not disrupt voting system operations.

Source: Implied by design requirements in [VSS2002] I.2.2.9, I.2.1.8

4.4 Independent Voter-Verifiable Records

This chapter contains requirements for voting systems that produce and use independent voter-verifiable records (IVVR). IVVR are generally understood to mean voter-verifiable paper records (VVPR); however non-paper IVVR, once developed, could be used to still satisfy these requirements. There are two broad categories of paper-based IVVR, i.e., VVPR:

  • VVPATs couple an electronic voting device with a printer. The voter makes selections on the voting device, but is given the opportunity to review and verify choices on a paper record. The paper record may be a continuous roll or cut sheets.
  • Optical scan voting systems use paper ballots that are human-readable and may be marked by either hand or device, along with an electronic scanner that checks the ballot for problems such as under- and over-votes, and also records the votes.

For all IVVR systems, the records are available to the voter to review and verify, and these records are retained for later auditing or recounts as needed. This chapter addresses the use of the records for auditing and security. The chapter first presents the requirements for IVVR systems and then presents specific requirements for VVPR systems.

4.4.1 General requirements

Voter-verifiable records exist to provide an independent record of the voter’s choices that can be used to verify the correctness of the electronic record produced by the voting device.

4.4.1-A IVVR vote-capture device, IVVR creation

The IVVR vote-capture device SHALL create an independent voter verifiable record.

Applies To: IVVR vote-capture device

Test Reference: Part 3: 5.2 “Functional Testing”

DISCUSSION

This requirement is further defined by its subrequirements. Its purpose is to ensure that a single IVVR meets all requirements and all properties as outlined in the following subrequirements.

Source: New requirement

4.4.1-A.1 IVVR vote-capture device, IVVR direct verification by voters

IVVR vote-capture devices SHALL create an IVVR that voters can verify (a) without software, or (b) without programmable devices excepting assistive technology.

Applies To: IVVR vote-capture device

Test Reference: Part 3: 5.2 “Functional Testing”

DISCUSSION

The exclusion of software or programmable devices from the voter verification process is necessary for the system to be software independent. It suffices to meet this requirement that most voters can review the record directly. Voters who use some assistive technologies may not be able to directly review the record. This requirement allows for Observational Testing to be able to determine whether the assistive technology is operating without error or fraud.

Source: New requirement

4.4.1-A.2 IVVR vote-capture device, IVVR direct review by election officials

IVVR vote-capture devices SHALL create an IVVR that election officials and auditors can review without software or programmable devices.

Applies To: IVVR vote-capture device

Test Reference: Part 3: 5.2 “Functional Testing”

DISCUSSION

The exclusion of programmable devices from the voter verification process is necessary for the system to be software independent.

Source: New requirement

4.4.1-A.3 IVVR vote-capture device, support for hand auditing

IVVR vote-capture devices SHALL create an IVVR that election officials can use without software or programmable devices to verify that the reported electronic totals are correct.

Applies To: IVVR vote-capture device

Test Reference: Part 3: 5.2 “Functional Testing”

DISCUSSION

The records must support a hand audit that uses no programmable devices to read or interpret the records. The hand audit may provide a statistical basis for other larger audits or recounts performed using technology (such as OCR).

Source: New requirement

4.4.1-A.4 IVVR vote-capture device, IVVR use in recounts

IVVR vote-capture devices SHALL create an IVVR that election officials can use to reconstruct the full set of totals from the election.

Applies To: IVVR vote-capture device

Test Reference: Part 3: 5.2 “Functional Testing”

DISCUSSION

This requirement addresses the completeness of the records, rather than their technology independence.

Source: New requirement

4.4.1-A.5 IVVR vote-capture device, IVVR durability

IVVR vote-capture devices SHALL create an IVVR that will remain unchanged for minimally 22 months unaffected by power failure, software failure, or other technology failure.

Applies To: IVVR vote-capture device

Test Reference: Part 3: 5.2 “Functional Testing”

Source: New requirement

4.4.1-A.6 IVVR vote-capture device, IVVR tamper evidence

IVVR vote-capture devices SHALL create an IVVR that show evidence of tampering or change by the voting system.

Applies To: IVVR vote-capture device

Test Reference: Part 3: 5.2 “Functional Testing”

Source: New requirement

4.4.1-A.7 IVVR vote-capture device, IVVR support for privacy

IVVR vote-capture devices SHALL create an IVVR for which procedures or technology can be used to protect voter privacy.

Applies To: IVVR vote-capture device

Test Reference: Part 3: 5.2 “Functional Testing”

DISCUSSION

Privacy protection includes a method to separate the order of voters from the order of records or procedural means to ensure that information relating to the order of voters, including time a record is created, can be protected. Privacy also includes other methods to make records hard to identify, normally by having them be indistinguishable from each other.

Source: New requirement

4.4.1-A.8 IVVR vote-capture device, IVVR public format

IVVR vote-capture devices SHALL create an IVVR in a non-restrictive, publicly-available format, readable without confidential, proprietary, or trade secret information.

Applies To: IVVR vote-capture device

Test Reference: Part 3: 5.2 “Functional Testing”

Source: New requirement

4.4.1-A.9 IVVR vote-capture device, IVVR unambiguous interpretation of cast vote

Each IVVR SHALL contain a human-readable summary of the electronic CVR. In addition, all IVVR SHALL contain audit-related information including:

  1. Polling place;
  2. Reporting context;
  3. ballot configuration;
  4. Date of election; and
  5. Complete summary of voter’s choices.

Applies To: IVVR vote-capture device

Test Reference: Part 3: 5.2 “Functional Testing”

DISCUSSION

All IVVR contain some human-readable content. In addition, some IVVR may use machine-readable content to make counting or recounting more efficient. For example, PCOS systems place a human-readable representation of the votes beside a machine-readable set of ovals to be marked by a human or a machine.

The human-readable content of the IVVR must contain all information needed to interpret the cast vote. This is necessary to ensure that hand audits and recounts can be done using only the human-readable parts of the paper records.

This requirement generalizes [VVSG2005] I.7.9.1-b, I.7.9.1-c and I.7.9.3-h by extending its provisions to include all IVVR.

Source: [VVSG2005] I.7.9.1-b, I.7.9.1-c, I.7.9.3-h

4.4.1-A.10 IVVR vote-capture device, no codebook required to interpret

The human-readable ballot contest and choice information on the IVVR SHALL NOT require additional information, such as a codebook, lookup table, or other information, to unambiguously determine the voter’s ballot choices.

Applies To: IVVR vote-capture device

Test Reference: Part 3: 5.2 “Functional Testing”

DISCUSSION

The hand audit of records requires the ability for auditors to verify that the electronic CVR as seen and verified by voters is the same as the electronic CVR that was counted. This requires that the auditor have all information necessary on the IVVR to interpret completely how the contests were voted. If an external codebook or lookup table were needed to interpret the IVVR, there would be no way for the auditor to be certain that the codebook had not changed since the voter used it.

4.4.1-A.11 IVVR vote-capture device, multiple physical media

When a single IVVR spans multiple physical media, each physical piece of media SHALL include polling place, reporting context, ballot configuration, date of election, and number of the media and total number of the media (e.g. page 1 of 4).

Applies To: IVVR vote-capture device

Test Reference: Part 3: 5.2 “Functional Testing”

DISCUSSION

This requirement generalizes [VVSG2005] I.7.9.6-f by describing the information that must be included on each piece of physical media for an IVVR spread across multiple pieces of media and extends its provisions to include all IVVR.

Source: [VVSG2005] I.7.9.6-f

4.4.1-A.12 IVVR vote-capture device, IVVR accepted or rejected

The IVVR SHALL be marked as accepted or rejected in the presence of the voter.

Applies To: IVVR vote-capture device

Test Reference: Part 3: 5.2 “Functional Testing”

DISCUSSION

Unambiguous verification or rejection markings address the threat that the voting device might attempt to accept or reject ballot summaries without the voter’s approval. This requirement extends [VVSG2005] I.7.9.2-b to all IVVR voting systems.

Source: [VVSG2005] I.7.9.2-b

4.4.1-A.13 IVVR vote-capture device, IVVR accepted or rejected for multiple physical media

Each piece of IVVR physical media or SHALL be individually accepted or rejected by the voter.

Applies To: IVVR vote-capture device

Test Reference: Part 3: 5.2 “Functional Testing”

DISCUSSION

It must be unambiguous that all choices were rejected or accepted. This can be done at the end of physical media (e.g., a cut sheet VVPAT) or per contest.

Source: New requirement

4.4.1-A.14 IVVR vote-capture device, IVVR non-human-readable contents permitted

The IVVR MAY include machine-readable encodings of the electronic CVR and other information that is not human-readable.

Applies To: IVVR vote-capture device

Test Reference: Part 3: 5.2 “Functional Testing”

DISCUSSION

This requirement extends [VVSG2005] I.7.9.3-g to include all IVVR.

Source: [VVSG2005] I.7.9.3-g

4.4.1-A.15 IVVR vote-capture device, IVVR machine-readable part contains same information as human-readable part

If a non-human-readable encoding is used on the IVVR, it SHALL contain the entirety of the human-readable information on the record.

Applies To: IVVR vote-capture device

Test Reference: Part 3: 5.2 “Functional Testing”

DISCUSSION

The machine-readable part of the IVVR must permit the reconstruction of the human-readable part of the record.

Source: New requirement

4.4.1-A.16 IVVR vote-capture device, IVVR machine-readable contents may include error correction/detection information

If a non-human-readable encoding is used on the IVVR, the encoding MAY also contain information intended to ensure the correct decoding of the information stored within, including:

  1. Checksums;
  2. Error correcting codes;
  3. Digital signatures; and
  4. Message Authentication Codes.

Applies To: IVVR vote-capture device

Test Reference: Part 3: 5.2 “Functional Testing”

DISCUSSION

Error correction/detection information is used to protect digital data from error or tampering. This information would not be meaningful to a human, so there is no reason to demand that it also appear in the human-readable part of the record.

This requirement extends [VVSG2005] 7.9.3-g to include all IVVR.

Source: [VVSG2005] I.7.9.3-g

4.4.1-A.17 IVVR vote-capture device, public format for IVVR non-human-readable data

Any non-human-readable information on the IVVR SHALL be presented in a fully disclosed public format.

Applies To: IVVR vote-capture device

Test Reference: Part 3: 5.2 “Functional Testing”

DISCUSSION

Meaningful automated auditing requires full disclosure of any non-human-readable encodings on the IVVR. However, hand auditing does not require disclosure of this kind. This requirement extends [VVSG2005] I.7.9.3-e to include all IVVR.

Source: [VVSG2005] I.7.9.3-f

4.4.2 VVPAT

This section contains requirements for the basic components and operation of voting devices of the class VVPAT (Voter-verifiable Paper Audit Trail). VVPAT is one implementation of the system class IVVR, using voter-verifiable paper records (VVPR), i.e., paper IVVR. Voting devices of this class typically consist of a DRE-like vote-capture device with an attached printer and a capability for displaying a VVPR to the voter and for storing the VVPR. In this configuration, prior to casting the ballot on the DRE, voters are given the ability to verify their selections on the VVPR in a private and independent manner. After a VVPR is produced, but before the voter's electronic CVR is recorded, the voter must have the opportunity to accept or reject the contents of the VVPR. If a voter does not accept the contents of the VVPR, the voter must be permitted to redo the electronic CVR as displayed to the voter. In storing the VVPRs, the VVPAT must distinguish a voter’s rejected VVPR from an accepted VVPR. The VVPR must be able to be used in independent (from the VVPAT’s software) audits of the electronic CVRs and in recounts, and capable of being used as the official ballot in tabulations if required by state law.

4.4.2.1 VVPAT components and definitions

4.4.2.1-A VVPAT, definition and components

A VVPAT SHALL consist minimally of the following fundamental components:

  1. A voting device, on which a voter makes selections and prepares to cast a ballot;
  2. A printer that prints a VVPR summary of the voter’s ballot selections, and that allows the voter to compare it with the electronic ballot selections;
  3. A mechanism by which the voter may indicate acceptance or rejection of the VVPR;
  4. Ballot box/cartridge to contain accepted and voided VVPRs; and
  5. A VVPR for each electronic CVR. The VVPR may be printed on a separate sheet for each VVPR (“cut-sheet VVPAT”) or on a continuous paper roll (“paper-roll VVPAT”).

Applies To: VVPAT

Test Reference: Part 3: 5.2 “Functional Testing”

Source: [VVSG2005] I.7.9.1-a

4.4.2.2 VVPAT printer/computer interactions

4.4.2.2-A VVPAT, printer connection to voting system

The VVPAT printer SHALL be physically connected via a standard, publicly documented printer port using a standard communications protocol.

Applies To: VVPAT

Test Reference: Part 3: 5.2 “Functional Testing”

DISCUSSION

Examples would be parallel printer ports and USB ports. This requirement extends [VVSG2005] I.7.9.4-a in that only authorized election officials can access that port.

Source: [VVSG2005] I.7.9.4-a

4.4.2.2-B VVPAT, printer able to detect errors

The VVPAT SHALL detect printer errors that may prevent VVPRs from being correctly displayed, printed or stored, such as lack of consumables such as paper, ink, or toner, paper jams/misfeeds, and memory errors.

Applies To: VVPAT

Test Reference: Part 3: 5.2 “Functional Testing”

DISCUSSION

The requirement to detect errors is expanded on in the sub-requirements, which specify requirements on what to do when the errors are detected.

Source: [VVSG2005] I.7.9.4-g

4.4.2.2-C VVPAT, error handling specific requirements

If a printer error or malfunction is detected, the VVPAT SHALL:

  1. Present a clear indication to the voter and election officials of the malfunction. This must indicate clearly whether the current voter’s vote has been cast, discarded, or is waiting to be completed;
  2. Suspend voting operations until the problem is resolved;
  3. Allow canceling of the current voter’s electronic CVR by election officials in the case of an unrecoverable error; and
  4. Protect the privacy of the voter while the error is being resolved.

Applies To: VVPAT

Test Reference: Part 3: 5.2 “Functional Testing”

DISCUSSION

A printer error must not cause the voting device to end up in a state where the election officials cannot determine whether the ballot was cast or not. This requirement restates and extends [VVSG2005] I.7.9.4-h by requiring that in the event of a printer error, privacy must be maintained to the greatest extent possible, and that voting officials need to be able to cancel the voting session.

Source: [VVSG2005] I.7.9.4-h

4.4.2.2-C.1 VVPAT, general recovery from misuse or voter error

Voter actions SHALL NOT be capable of causing a discrepancy between the VVPR and its corresponding electronic CVR.

Applies To: VVPAT

Test Reference: Part 3: 4.5 “Source Code Review”, 5.2 “Functional Testing”

DISCUSSION

This prevents an error or malicious act by a voter from creating the incorrect appearance that election fraud has been attempted.

Source: New requirement

4.4.2.3 Protocol of operation

4.4.2.3-A VVPAT, prints and displays a paper record

The VVPAT SHALL provide capabilities for the voter to print a VVPR and compare with a summary of the voter’s electronic ballot selections prior to the voter casting a ballot.

Applies To: VVPAT

Test Reference: Part 3: 5.2 “Functional Testing”

Source: [VVSG2005] I.7.9.2-a

The VVPAT format and presentation of the VVPR and electronic summaries of ballot selections SHALL be designed to facilitate the voter’s rapid and accurate comparison.

Applies To: VVPAT

Test Reference: Part 3: 5.2 “Functional Testing”

Source: [VVSG2005] I.7.9.6-b

4.4.2.3-C VVPAT, vote acceptance process requirements

When a voter indicates that the VVPR is to be accepted, the VVPAT SHALL:

  1. Immediately print an unambiguous indication that the vote has been accepted, in view of the voter;
  2. Electronically store the CVR as a cast vote; and
  3. Deposit the VVPR into the ballot box or other receptacle.

Applies To: VVPAT

Test Reference: Part 3: 4.5 “Source Code Review”, 5.2 “Functional Testing”

DISCUSSION

Immediately upon acceptance by the voter, the VVPAT commits to accepting the VVPR, in the voter’s sight, and stores the electronic CVR. This defends against the threat that the VVPAT might indicate a rejected vote on the VVPR when the voter cannot observe it. The VVPR must be placed into the receptacle before the next voter arrives, to ensure the previous voter’s privacy.

Source: [VVSG2005] I.7.9.2-b, I.7.9.2-d

4.4.2.3-D VVPAT, vote rejection process requirements

When a voter indicates that the VVPR is to be rejected, the VVPAT SHALL:

  1. Immediately print an unambiguous indication that the vote has been rejected, in view of the voter;
  2. Electronically store a record that the VVPR was rejected including the summary of choices; and
  3. Deposit the rejected VVPR into the ballot box or other receptacle.

Applies To: VVPAT

Test Reference: Part 3: 4.5 “Source Code Review”, 5.2 “Functional Testing”

DISCUSSION

Immediately upon rejection by the voter, the VVPAT commits to rejecting the VVPR, in the voter’s sight, and stores the electronic CVR. This defends against the threat that the VVPAT might indicate an accepted vote on the VVPR when the voter cannot observe it.

This requirement in part restates [VVSG2005] I.7.9.2-c.

Source: [VVSG2005] I.7.9.2-c

4.4.2.3-D.1 VVPAT, rejected vote configurable limits per voter

The VVPAT SHALL have the capacity to be configured to limit the number of times a single voter may reject a VVPR without election official intervention. The VVPAT SHALL support limits between zero (any rejected VVPR requires election official intervention) to five times, and MAY support an unlimited number of rejections without election official intervention.

Applies To: VVPAT

Test Reference: Part 3: 5.2 “Functional Testing”

DISCUSSION

This requirement permits election officials to configure the VVPAT to limit the number of times a single voter can reject VVPRs before election official intervention is required. This allows equipment to be configured to meet election law of the jurisdiction.

This addresses the threat that a single voter may reject a large number of VVPRs, thus depleting supplies.

This also helps to address the threat that a malicious or malfunctioning VVPAT may indicate a different set of voter choices on the screen than it does on paper and in the electronic records. Such an attack can only be detected by the existence of large numbers of rejected VVPRs. Requiring election official intervention each time a voter rejects a VVPR allows election officials to quickly recognize a malfunctioning or malicious machine.

If the VVPAT is behaving maliciously, it can simply ignore this limit. Voters may notice this and complain, and if the VVPAT is chosen for a hand audit, the auditors will notice a large number of rejected VVPRs and may try to verify whether election officials noticed a large number of problems with the VVPAT.

Source: [VVSG2005] I.7.9.2-c

4.4.2.3-D.2 VVPAT, rejected vote limits per machine

The VVPAT SHALL have the capacity to limit the total number of VVPRs that a machine may reject before election official intervention is required. The VVPAT SHALL permit the setting of no limit, so that no number of total rejected VVPRs requires immediate election official intervention.

Applies To: VVPAT

Test Reference: Part 3: 5.2 “Functional Testing”

DISCUSSION

This requirement supports the procedural defense of taking a VVPAT offline when too many voters complain about its behavior.

The requirement also addresses the threat that a malfunctioning or malicious VVPAT might indicate a different set of choices to the voter than it records on paper and in its electronic records. The only way to detect this attack is a large number of rejected VVPRs, as some voters attempt to verify their VVPRs.

A malfunctioning or malicious VVPAT may ignore these limits. However, if the VVPAT ignores the limits, and the local procedures require taking a voting machine out of service when the maximum number of rejected VVPRs is reached, then a hand audit of the VVPAT will detect the its malicious behavior—more rejected VVPRs will be discovered than should be possible from a single VVPAT.

Source: New requirement

4.4.2.3-D.3 VVPAT, rejected vote election official intervention

When a VVPAT reaches a configured limit of rejected VVPRs per voter or per machine, it SHALL do the following:

  1. Remove any indication of the voter’s choices from the screen;
  2. Place the VVPR that has been rejected into the ballot box or other receptacle;
  3. Clearly display that a VVPR has been rejected and indicate the need for election official intervention; and
  4. Suspend normal operations until re-enabled by an authorized election official.

Applies To: VVPAT

Test Reference: Part 3: 5.2 “Functional Testing”

DISCUSSION

When a VVPAT reaches some limit on the number of rejected VVPRs, it must suspend normal operations and require election official intervention. This must be done in a way that protects voter privacy as much as possible, and that minimizes the chances of misunderstanding by the voter.

Source: New requirement

4.4.2.4 Human-readable VVPR contents for VVPAT

The following requirements apply to the human-readable contents of VVPR.

4.4.2.4-A VVPAT, machine readability of VVPAT VVPR

The human-readable contents of the VVPAT VVPR SHALL be created in a manner that is machine-readable by optical character recognition.

Applies To: VVPAT

Test Reference: Part 3: 5.2 “Functional Testing”

DISCUSSION

The user documentation for the VVPAT must include all information necessary to read in the records by optical character recognition. This requirement restates a similar requirement in [VVSG2005] I.7.9.3-g by requiring that VVPRs be machine-readable, at a minimum, through optical character recognition of the human-readable portion of the VVPR.

Source: [VVSG2005] I.7.9.3-g

4.4.2.4-A.1 VVPAT, support for audit of machine-read representations

The VVPAT SHALL include supporting software, hardware, and documentation of procedures to verify the agreement between the machine read content and the content as reviewed directly by an auditor.

Applies To: VVPAT

Test Reference: Part 3: 5.2 “Functional Testing”

DISCUSSION

To achieve software independence, the mechanism reading the VVPRs cannot be trusted to read and record the correct values. Thus, an auditing step is required if this information is to be used in a secure way.

Source: New requirement

4.4.2.4-B VVPAT, paper-roll, required human-readable content per roll

Paper-roll VVPATs SHALL mark paper rolls with the following:

  1. Polling place;
  2. Reporting context;
  3. Date of election;
  4. If multiple paper rolls were produced during this election on this device, the number of the paper roll (e.g., Roll #2); and
  5. A final summary line specifying how many total VVPRs appear on the roll, and how many accepted VVPRs appear on the roll.

Applies To: VVPAT

Test Reference: Part 3: 5.2 “Functional Testing”

DISCUSSION

In order for recounts and audits to work, the auditor must be able to determine which electronic record corresponds to the paper roll or rolls. The above information ensures that the auditor will be able to find the right electronic record, and also supports finding all necessary paper rolls. This requirement requires the voting device either to detect the amount of paper remaining on the roll, or to compute how much paper is left.

Source: New requirement

4.4.2.4-C VVPAT, paper-roll, information per VVPR

Paper-roll VVPATs SHALL include the following on each VVPR:

  1. ballot configuration;
  2. Type of voting (e.g., provisional, early, etc.);
  3. Complete summary of voter’s choices;
  4. For each ballot contest:
    1. contest name (e.g., “Governor”);
    2. Any additional information needed for unambiguous interpretation of the VVPR;
    3. A clear indication, if the contest was undervoted; and
    4. A clear indication, if the choice is a write-in vote.
  5. An unambiguous indication of whether the ballot has been accepted or rejected by the voter.

Applies To: VVPAT

Test Reference: Part 3: 5.2 “Functional Testing”

DISCUSSION

The paper roll and the electronic CVRs, together, must give an auditor all information needed to do a meaningful hand audit or recount. The contents in this requirement ensure that the human-readable parts of the paper rolls are sufficient to recount the election and to audit the device totals.

Source: New requirement

4.4.2.4-D VVPAT, paper-roll, VVPRs on a single roll

Paper-roll VVPATs SHALL NOT split VVPRs across rolls; each VVPR must be contained in its entirety by the paper roll.

Applies To: VVPAT

Test Reference: Part 3: 5.2 “Functional Testing”

DISCUSSION

Allowing a single VVPR to split across rolls would make auditing much harder, and would also make it very difficult for the voter to fully verify the VVPR. This requires that the printer detect the end of the paper roll in time to avoid splitting VVPRs.

Source: [VVSG2005] I.7.9.6-e

4.4.2.4-E VVPAT, cut-sheet, content requirements per electronic CVR

Cut-sheet VVPATs SHALL include the following on each VVPR:

  1. Polling place;
  2. Reporting context;
  3. Date of election;
  4. ballot configuration
  5. Type of voting (e.g., provisional, early, etc.);
  6. Complete summary of voter’s choices;
  7. For each ballot contest:
    1. contest name (e.g., “Governor”);
    2. Any additional information needed for unambiguous interpretation of the VVPR;
    3. A clear indication, if the contest was undervoted; and
    4. A clear indication, if the choice is a write-in vote.
  8. An unambiguous indication of whether each sheet has been accepted or rejected by the voter.

Applies To: VVPAT

Test Reference: Part 3: 5.2 “Functional Testing”

DISCUSSION

The set of detached VVPRs must give an auditor all information needed to do a meaningful hand audit or recount. Each VVPR must include all information needed to identify which device produced it, which type of ballot it is (ballot style, reporting context, etc.). All this information is necessary to support the hand audit. Unambiguous rejection and acceptance markings address the threat that the VVPAT might attempt to reject or accept ballot summaries without the voter’s approval.

Source: New requirement

4.4.2.4-F VVPAT, cut-sheet, VVPR split across sheets

If a cut-sheet VVPAT splits VVPRs across multiple sheets of paper, each sheet SHALL include:

  1. Page number of this sheet and total number of sheets (e.g., page 1 of 4);
  2. ballot configuration
  3. Reporting context
  4. Unambiguous indication that the sheet’s contents have been accepted or rejected by the voter; and
  5. Any correspondence information included to link the VVPR to its corresponding electronic CVR.

Applies To: VVPAT

Test Reference: Part 3: 5.2 “Functional Testing”

DISCUSSION

If a VVPR is split across many sheets, then the voter must be able to verify the individual sheets meaningfully, and auditors during the hand audit must be able to count the votes from the VVPR correctly. This means that each sheet must contain all information to interpret and count the votes on it, including reporting context and ballot style, and including whether the voter accepted or rejected the contents of the sheet.

Source: [VVSG2005] I.7.9.6-f

4.4.2.4-F.1 VVPAT, cut-sheet, ballot contests not split across sheets

If a cut-sheet VVPAT splits VVPRs across multiple sheets of paper, it SHALL NOT split ballot contests across sheets.

Applies To: VVPAT

Test Reference: Part 3: 5.2 “Functional Testing”

DISCUSSION

Splitting a single ballot contest across multiple sheets would make it difficult for auditors to count votes from the VVPRs. In the case of a referendum, the referendum text may cross several sheets, but the vote choice must not be dis-associated from text that identifies it with the referendum.

Source: New requirement

4.4.2.4-F.2 VVPAT, cut-sheet, VVPR sheets verified individually

If a cut-sheet VVPAT splits VVPRs across multiple sheets of paper, the ballot choices on each sheet SHALL be submitted to the voter for verification separately according to the following:

  1. The voter shall be presented a verification screen for the contents of each sheet separately at the same time as the voter is able to verify the contents of the part of the VVPR on the sheet;
  2. When a voter accepts or rejects the contents of a sheet, the votes contained on that sheet and verification screen shall be committed to memory, regardless of the verification of any other sheet by the same voter;
  3. Configurable limits on rejected VVPRs per voter shall count each rejected sheet as a rejected VVPR;
  4. Configurable limits on rejected VVPRs per machine shall not count more than one rejected VVPR per voter; and
  5. When a rejected VVPR requires election official intervention, the VVPAT shall indicate which sheets have been accepted and which rejected.

Applies To: VVPAT

Test Reference: Part 3: 5.2 “Functional Testing”

DISCUSSION

When a VVPR is split across multiple sheets, both the voter and the auditors must be able to determine, unambiguously, whether the votes on each sheet have been accepted or rejected by the voter. This requires verification of each sheet separately. The process of voter verification for cut sheet VVPAT is very similar to the process for multiple page optical scan ballots, in which each sheet may be processed and recounted separately.

Source: New requirement

4.4.2.5 Linking the electronic CVR to the VVPR

A VVPAT is required to support the linking of electronic and VVPRs, but must also be able to disable this linkage.


4.4.2.5-A VVPAT, identification of electronic CVR correspondence

The VVPAT SHALL provide a capability to print information on each VVPR sufficient for auditors to identify from an electronic CVR its corresponding VVPR and from a VVPR its corresponding electronic CVR. This capability SHALL be possible for election officials to enable or disable.

Applies To: VVPAT

Test Reference: Part 3: 5.2 “Functional Testing”

DISCUSSION

All VVPATs are required to support the ability to do this as an option, but this must be configurable, so that election officials can enable or disable it.

Source: [VVSG2005] I.7.9.3-c

4.4.2.5-A.1 VVPAT, CVR correspondence identification hidden from voter

Any information on the VVPAT VVPR that identifies the corresponding electronic CVR SHOULD NOT be possible for the voter to read or copy by hand.

Applies To: VVPAT

Test Reference: Part 3: 5.2 “Functional Testing”

DISCUSSION

This requirement addresses the threat that some voters might copy down the correspondence information to prove to some third party how they have voted. If the correspondence information is not possible for voters to copy down by hand, they must use a camera or similar technology to prove how they voted—in which case, the correspondence information makes vote buying no easier than it already was.

Source: New requirement

4.4.2.5-A.2 VVPAT, CVR correspondence identification viewable to auditors

The VVPAT manufacturer SHALL include a capability for auditors to verify the correspondence between the electronic CVR and VVPR pairs, if the correspondence information is printed on the VVPR.

Applies To: VVPAT

Test Reference: Part 3: 5.2 “Functional Testing”

DISCUSSION

Auditors must be able to decode the correspondence information from the VVPR, in order to determine which electronic CVR corresponds to any given VVPR.

Source: New requirement

4.4.2.5-A.3 VVPAT, CVR correspondence identification in reported ballot images

When electronic CVR correspondence identification is printed on the VVPAT VVPR, the correspondence information SHALL be included in the ballot images sent to the EMS by collection of ballot images record.

Applies To: VVPAT

Test Reference: Part 3: 4.5 “Source Code Review”, 5.2 “Functional Testing”

DISCUSSION

The correspondence information is useful only if it is reported back to the EMS. Including this information ensures that it will also be digitally signed before being returned.

Source: [VVSG2005] I.7.9.3-c

4.4.2.6 Paper-roll VVPAT privacy and audit-support

Paper roll VVPATs may introduce a privacy risk when records are sequentially. However, this risk can be mitigated using a combination of technology and strong election procedures. The following requirements address this threat.

4.4.2.6-A VVPAT, paper-roll, VVPRs secured immediately after vote cast

Paper-roll VVPATs SHALL store the part of the paper roll containing VVPRs in a secure, opaque container, immediately after they are verified.

Applies To: VVPAT

Test Reference: Part 3: 5.2 “Functional Testing”

DISCUSSION

Paper rolls containing VVPRs for voters in the order in which they used the voting systems represent a privacy risk. VVPATs that comply with this requirement decrease this risk.

Source: [VVSG2005] I.7.9.5-d, I.7.9.5-g, I.7.9.4-d

4.4.2.6-B VVPAT, paper-roll, privacy during printer errors

Procedures for recovery from printer errors on paper-roll VVPATs SHALL NOT expose the contents of previously cast VVPRs.

Applies To: VVPAT

Test Reference: Part 3: 5.2 “Functional Testing”

DISCUSSION

Printer errors must not result in the loss of ballot secrecy. This is related to the requirement for immediately storing the VVPRs inside a secure, opaque container.

Source: New requirement

4.4.2.6-C VVPAT, paper-roll, support tamper-seals and locks

Paper-roll VVPATs SHALL be designed so that when the rolls are removed from the voting device according to the following:

  1. All paper containing VVPRs are contained inside the secure, opaque container;
  2. The container supports being tamper-sealed and locked; and
  3. The container supports being labeled with the device serial number, precinct, and other identifying information to support audits and recounts.

Applies To: VVPAT

Test Reference: Part 3: 5.2 “Functional Testing”

DISCUSSION

Paper-roll VVPAT must support good procedures to protect the voters’ privacy. The supported procedure in this case is immediately locking and tamper sealing each VVPAT container upon removing it from the voting device. This is consistent with the goal of having the paper rolls with VVPRs on them treated like paper ballots, stored in a locked and sealed box.

If the paper roll cartridge is locked and sealed before the start of voting, and some mechanism in the cartridge prevents extraction of the used paper roll collected inside the cartridge, locking and sealing the cartridge a second time at poll closing would be necessary only for preventing further VVPRs being printed on the paper roll.

Source: [VVSG2005] I.7.9.5-g

4.4.2.6-D VVPAT, paper-roll, mechanism to view spooled records

If a continuous paper spool is used to store VVPRs, the manufacturer SHALL provide a mechanism for an auditor to unspool the paper, view each VVPR in its entirety, and then respool the paper, without modifying the paper in any way or causing the paper to become electrically charged.

Applies To: VVPAT

Test Reference: Part 3: 5.2 “Functional Testing”

Source: New requirement

4.4.3 PCOS systems

A PCOS voting system involves paper ballots marked in a way that is both human- and machine-readable. The following requirements apply to optical scan ballots, as required for supporting audit and recount.

4.4.3-A Optical scanner, optional marking

Optical scanners MAY add markings to each paper ballot, such as:

  1. Unique record identifiers to allow individual matching of paper and electronic CVRs;
  2. Digital signatures; and
  3. Batch information.

Applies To: Optical scanner

Test Reference: Part 3: 5.2 “Functional Testing”

Source: New requirement

4.4.3-A.1 Optical scanner, optional marking restrictions

Optical scanners that add markings to paper ballots scanned SHALL NOT be capable of altering the contents of the human-readable CVR on the ballot. Specifically, Optical scanners capable of adding markings to the scanned ballots SHALL NOT permit:

  1. Marking in the regions of the ballot that indicate voter choices;
  2. Marking in the regions of the ballot that contain the human-readable description of the marked choice; and
  3. Marking in regions reserved for timing marks.

Applies To: Optical scanner

Test Reference: Part 3: 5.2 “Functional Testing”

DISCUSSION

If the scanner could alter the human-readable contents of the ballot, or mark the ballot, after scanning, then the paper records stored by the scanner could no longer be considered voter-verifiable, and the optical scan system would no longer be software independent.

Source: New requirement