Chapter 4: Security and Audit Architecture

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

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

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

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

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.

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.

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

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

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

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

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

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

Applies To: Tabulator

Test Reference: Part 3: 5.2 “Functional Testing”

Source: New requirement

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

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

Applies To: Tabulator

Test Reference: Part 3: 5.2 “Functional Testing”

Source: New requirement

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

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

Applies To: EMS

Test Reference: Part 3: 5.2 “Functional Testing”

DISCUSSION

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

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

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

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

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

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

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

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

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

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

Applies To: IVVR vote-capture device

Test Reference: Part 3: 5.2 “Functional Testing”

Source: New requirement

Applies To: IVVR vote-capture device

Test Reference: Part 3: 5.2 “Functional Testing”

Source: New requirement

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

Applies To: IVVR vote-capture device

Test Reference: Part 3: 5.2 “Functional Testing”

Source: New requirement

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

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.

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

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

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

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

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

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

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

Applies To: VVPAT

Test Reference: Part 3: 5.2 “Functional Testing”

Source: [VVSG2005] I.7.9.1-a

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

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

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

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

Applies To: VVPAT

Test Reference: Part 3: 5.2 “Functional Testing”

Source: [VVSG2005] I.7.9.2-a

Applies To: VVPAT

Test Reference: Part 3: 5.2 “Functional Testing”

Source: [VVSG2005] I.7.9.6-b

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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