This chapter contains general requirements relating to security. It contains the following sections:
This section establishes general cryptography requirements for voting systems, specifies that signatures for protecting electronic voting records used in audits be generated in an embedded hardware signature module, and specifies the requirements for that module. These requirements include a key management scheme for the signature keys used by the signature cryptographic module, and requirements to help ensure that the signatures are reliable even if the voting device software has bugs or is tampered with.
Cryptography typically serves several purposes in voting systems. They include:
This section establishes general technical requirements for the cryptographic functionality of voting systems, and some more specific requirements that certain cryptographic functions (digital signatures and key management for digital signatures) be performed in a protected hardware cryptographic module that is isolated from the voting system software, so that it is unlikely that the keys will be revealed or the cryptographic functionality compromised, even in the presence of a bug or malicious code in the other parts of the voting system and even if an adversary (possibly a corrupt insider) gains physical access to or control of the voting system for a period of time. The purpose of the signatures is to authenticate election records, and hardware cryptographic modules are not required for other cryptographic operations.
Cryptographic functionality SHALL be implemented in a FIPS 140-2 validated cryptographic module operating in FIPS mode.
Applies To: Programmed device
Test Reference: Part 3: 3.1 “Inspection”, 4.1 “Initial Review of Documentation”, 4.2 “Physical Configuration Audit”, 4.5 “Source Code Review”
DISCUSSION
Use of validated cryptographic modules ensures that the cryptographic algorithms used are secure and their correct implementation has been validated. Moreover, the security module security requirements have been validated to a specified security level. The current version of FIPS 140 and information about the NIST Cryptographic Module Verification Program are available at: http://csrc.nist.gov/cryptval/. Note that a voting device may use more than one cryptographic module, and quite commonly will use a “software” module for some functions, and a “hardware” module for other functions.
This requirement is a generalization of [VVSG2005] I.7.5.1-b, which is a cryptographic requirement with a limited scope to the encryption of data across public communication networks. That requirement mandated use of "an encryption standard currently documented and validated for use by an agency of the U.S. government". Use of public communication networks is forbidden in this document except for transmitting unofficial results or communicating with an electronic pollbook.
This requirement extends and strengthens [VVSG2005] I.7.8.2, which required use of a validated cryptographic module if signature signatures were used in voting system with independent verification. Use of digital signatures is required in this document, and this requirement mandates the use of a FIPS validated module.
This requirement is a generalization of [VVSG2005] I.7.4.6-d, which is a cryptographic requirement with a limited scope. That requirement mandated the use of FIPS 140-2 level 1 or higher validated cryptographic modules if hash functions or digital signatures are used during software validation.
Lastly, this requirement restates and strengthens [VVSG2005] I.7.9.3-a by requiring all cryptographic functionality be implemented in FIPS validated modules. [VVSG2005] I.7.9.3-a provides an exception when a cryptographic voting system uses cryptographic algorithms that are necessarily different from any algorithms that have approved CMVP implementations.
Source: [VVSG2005] I.7.5.1-b, I.7.8.2, I.7.4.6-d, I.7.9.3-a
Programmed devices that apply cryptographic protection SHALL employ NIST approved algorithms with a security strength of at least 112-bits to protect sensitive voting information and election records. Message Authentication Codes of 96-bits are conventional in standardized secure communications protocols, and acceptable to protect voting records and systems; however, the key used with such MACs SHALL also have a security strength of at least 112 bits.
Applies To: Programmed device
Test Reference: Part 3: 3.2 “Functional Testing”, 4.5 ”Source Code Review”
DISCUSSION
As of February 2006, NIST specifies the security strength of algorithms in SP 800-57, Part 1 <http://csrc.nist.gov/publications/nistpubs/index.html>. This NIST recommendation will be revised or updated as new algorithms are added, and if cryptographic analysis indicates that some algorithms are weaker than presently believed. The security strengths of SP 800-57 are based on estimates of the amount of computation required to successfully attack the particular algorithm. The specified strength should be sufficient for several decades.
This requirement is not intended to forbid all incidental use of non-approved algorithms by OS software or standardized network security protocols.
Source: New requirement
This section states the requirements for digital signatures generated by voting devices to sign election records. The purpose of signing election records is to authenticate them and prevent their subsequent alteration. This makes it more difficult to falsify election records so that a careful audit would not detect evidence of the alteration or would not detect that election fraud had occurred. It also makes it more difficult to forge electronic CVRs that would be accepted in the normal vote counting process. The specific requirements for the records that must be signed are given in Part 1: 5.2.2 “Voting device election information inspection” and 5.2.3 “Voting equipment properties inspection”. A separate hardware Signature Module (SM) protects the private signature keys and the signature process should the election system software be compromised. The module is “embedded in” (permanently attached to) the voting device to make it difficult to substitute another module.
This guideline does not require that the SM implement all of the cryptographic functionality of the voting device (although the SM might do so), nor does it require that the SM process the signed records directly. It is conventional and acceptable for a host computer system to provide a message digest generated from the record to be signed by a cryptographic hash function and the signature cryptographic module conventionally signs that. Standardized digital signature algorithms all apply the private signature key to a message digest rather than the message itself.
The SM is required only in those devices that digitally sign election records. Signature verification and other cryptographic functions need not be implemented in hardware. Moreover, digital signature operations can be used for authentication in challenge-response protocols, and the hardware requirements of this section do not apply to such uses of digital signatures. In such cases the signature is not normally retained as a part of the record of the election.
Digital signatures used to sign election records SHALL be generated in an embedded hardware Signature Module (SM).
Applies To: Programmed device
Test Reference: Part 3: 3.2 “Functional Testing”, 4.5 “Source Code Review”
DISCUSSION
The use of an embedded hardware module for the generation of signatures on election records protects the signature keys and helps to protect the integrity of those records even if the general voting device software is compromised. This makes it more difficult to create spurious election records.
Note that in some cases digital signature operations may be used in ways that do not “sign” election records – for example, in the authentication processes of communications protocols. Such digital signature operations may be performed in other crypto modules, which, while they must be validated as per Part 1: 7.7.1 “Integrity” above, need not be hardware modules.
Source: New requirement
Programmed devices that sign election records SHALL contain a hardware cryptographic module, the Signature Module (SM), that is capable of generating and protecting signature key pairs and generating digital signatures.
Applies To: Programmed device
Test Reference: Part 3: 3.1 “Inspection”, 4.1 “Initial Review of Documentation”, 4.2 “Physical Configuration Audit”
DISCUSSION
For the purpose of this requirement a “hardware” cryptographic module means a distinct electronic device, typically a preprogrammed, dedicated microcomputer that holds keying material and performs cryptographic operations. Although today this might typically be a single chip, soldered onto a larger motherboard, it is not the intent of this guideline to preclude higher levels of integration. It is expected that future voting devices may integrate the SM onto the same die as the rest of the voting device, as long as the SM is clearly physically and logically separated on the die from the rest of the voting device so that there is a distinct cryptographic module boundary, and there is no way for the rest of the device to access signature private keys except through the defined cryptographic module interface.
Signature verification and other cryptographic operations need not be implemented in hardware, but may also be implemented on the embedded signature module if desired.
Source: New requirement
Signatures Modules (SMs) SHALL be an integral, permanently attached component of a programmed device.
Applies To: Programmed device
Test Reference: Part 3: 3.1 “Inspection”
DISCUSSION
The SM is an integral, nonreplicable part of the voting device, to prevent tampering by replacing or substituting another device. For example, if there is a motherboard, the SM would typically be soldered to the motherboard of the voting device. If the core of the voting device is contained on a single chip computer, the module would be a distinct, integral, but independent processor on that chip that does not share logic or memory with other functions.
Source: New requirement
Signature Modules SHALL be validated under FIPS 140-2 with FIPS 140 level 2 overall security and FIPS 140 level 3 physical security.
Applies To: Programmed device
Test Reference: Part 3: 3.1 “Inspection”, 4.1 “Initial Review of Documentation”
DISCUSSION
FIPS 140 level 3 physical security requires tamper resistance.
Source: New requirement
Digital signatures require the generation and management of signature key-pairs: a private key and a related public key. The private key is used to sign a message (or, more precisely, the cryptographic message digest of the message), while the associated public key is used to verify the signature on a message. Public key-pairs are certified by public key certificates, electronic documents that are generated and digitally signed by some issuer (often called a Certification Authority or “CA”). The certificates bind a name and other associated data to a public key. Each voting device that generates digitally signed election records contains a Signature Module (SM) contains a single permanent Device Signature Key (DSK) and, at any one time, up to one Election Signature Key (ESK).
A new ESK is generated by the embedded signature module for every election. An ESK public key certificate is signed with the device key, and binds an election key to the name of the voting device and an election identifier. As a part of the election closeout procedure, a signed count of the number of signature operations performed with the ESK is produced, and the private component of the ESK is destroyed, to preclude later addition to the signed election records.
The SM is provisioned by the voting device manufacturer with a public key certificate for its DSK, which is exported on commend from the SM; however, the SM creates its own signature keys internally and does not permit the export of private signature keys. The SM maintains a copy of its device key certificate and its current election key certificate, and outputs them on request.
The Device Signature Key (DSK), a public key-pair, is internally generated by the voting device as a part of its initial configuration. The DSK has a Device Public Key Certificate that certifies the DSK public key. The Device Public Key Certificate may be externally (to the SM) generated and signed by the voting device manufacturer, then installed in the SM by the manufacturer, or, alternately, it may be generated internally by the SM and signed by the DSK private key as a self-signed certificate. The purpose of the DSK is to sign certificates for election keys, and Election Closeout Records. Once generated or installed in the DSK, the DSK certificate is permanently stored in the SM and never altered, although copies of it may be exported from the SM. The DSK certificate is an electronic record that binds the DSK to the unique identification of a single voting device (typically the manufacturer’s name, the model number of the device, the unique serial number of the device, and its date of manufacture), for the service life of the voting device.
Signature Modules SHALL securely generate a permanent DSK in the module, using an integral nondeterministic random bit generator.
Applies To: Programmed device
Test Reference: Part 3: 3.2 “Functional Testing”, 4.1 “Initial Review of Documentation”, 4.5 “Source Code Review”
DISCUSSION
FIPS 186-3 and NIST Special Publication 800-89 give technical requirements for the generation of secure digital signature keys.
Source: New requirement
There SHALL be a process or mechanism for generating an X.509 Device Certificate that binds the DSK public key to the unique identification of the programmed device, the certificate’s date of issue, the name of the issuer of the certificate and other relevant permanent information.
Applies To: Programmed device
Test Reference: Part 3: 3.2 “Functional Testing”, 4.1 “Initial Review of Documentation”
DISCUSSION
The Device Certificate may be generated in the SM and self-signed by the DSK, or it may be signed by a separate external Certification Authority (CA) and installed in the SM by the manufacturer. That CA could be maintained by or for the voting device manufacturer, or on the behalf of the manufacturer. Alternatively, it could be maintained by or for the election authority that purchases the voting device. If the Device Certificate is self-signed, then election authorities should maintain accurate, reliable records of the self-signed certificates of its voting devices. The Device Certificate permanently binds the device’s public key to the unique identification of the individual voting device (the same make, model, serial number information placarded on the case of the voting device). The device certificate might also optionally include the name of the owner of the machine, and any other relevant information that would not change over the service life of the voting device.
This guideline does not prescribe a specific Public Key Infrastructure for keeping and verifying the Device Certificates. A public key certificate is not a secret or confidential record, and the device certificate can be stored or distributed in any convenient manner. If the device certificate is self-signed, then election authorities should maintain independent, accurate, reliable records of the self-signed certificates of its voting devices. If a CA signs the certificate, then the public key of the CA should be securely established and maintained. No revocation or certificate status mechanism is required for the Device Certificates.
Although this standard does not require this, a hash (or at least 64-bits from the hash) of the device public key could be used as the device serial number, making the Device Public Key effectively the device serial number.
Note that the requirement to internally generate private keys and certificates implies requirements to implement an approved hash function, and a nondeterministic random number generator.
Also note that nothing in this section is intended to preclude a cryptographic module manufacturer from delivering SMs already initialized with a DSK and device certificate, perhaps accompanied by a placard (see below), to a voting device manufacturer for incorporation in the voting device.
Source: New requirement
Device Certificates SHALL be stored permanently in the SM and be readable on demand by the programmed device.
Applies To: Programmed device
Test Reference: Part 3: 3.2 “Functional Testing”, 4.1 “Initial Review of Documentation”
DISCUSSION
Although a copy of the Device Certificate may also be kept elsewhere (e.g., in a directory) a copy is always available with the device itself. Note that while there is ordinarily no concept of an “original” public key certificate since it is the signature on the key that validates it, but because the device certificate may be self-signed, the authenticity of a self-signed Device Certificate may be an issue, and the copy stored in the SM can be regarded as authoritative.
Source: New requirement
A human readable identification placard SHALL be permanently affixed to the external frame of any programmed device containing an SM that states, at a minimum, the same unique identification of the voting device contained in the device certificate.
Applies To: Programmed device
Test Reference: Part 3: 3.1 “Inspection”, 3.2 “Functional Testing ”
DISCUSSION
It is important that election workers be able to identify and track specific voting devices and correlate them with election records. The placard and the device certificate identity the same device in the same way. The placard may also contain other information and machine-readable information as may be convenient.
Source: New requirement
Signature Modules and the process for generating DSKs SHALL be implemented so that the private component of DSK is created and exists only inside the protected cryptographic module boundary of the SM, and the key cannot be altered or exported from the SM.
Applies To: Programmed device
Test Reference: Part 3: 4.1 “Initial Review of Documentation”, 4.5 “Source Code Review”
DISCUSSION
Once the key is installed in the SM it cannot be changed or read out from the module, and any external copy of the key must be destroyed as a part of the process of initializing the SM. The entire process of generating the key may take place in the SM; otherwise, a strictly controlled, secure process is required to generate the keys, install them in the modules, and destroy any external copies of the keys.
Source: New requirement
Signature Modules SHALL implement and permit only three uses of the DSK:
Applies To: Programmed device
Test Reference: Part 3: 3.2 “Functional Testing”, 4.1 “Initial Review of Documentation”, 4.5 “Source Code Review”
DISCUSSION
Each generation of a new Election Signature Key is an auditable event, and the two purposes of the DSK are to certify the new ESK and to certify that an ESK private key has been closed out (destroyed). While the ESK simply signs hashes presented to it by the voting device software, the SM generates, hashes and signs Election Public Key Certificates and Election Closeout Records, although partially from text inputs supplied by the voting device.
Source: New requirement
The purpose of an ESK is to sign election records in the course of an election. A voting device that signs election records generates its own ESKs and maintains only one ESK at a time. The public component of every ESK generated by the embedded signature module is signed by the DSK to create an Election Public Key Certificate, and when an election is closed out, the private component of that election key is destroyed by the SM, which produces an Election Closeout Record attesting to that destruction, signed by the DSK.
In the context of this section, an “election” may be held on a single day, for a single precinct or voting district, with a single ballot style, or it may span a period of days or weeks, and may involve a number of precincts and voting districts and ballot styles, if the voting device is intended to be so used (e.g., in voting centers or for early polling).
The SM is not aware of the context of its use, it simply creates a new ESK when requested by the voting device, signs hashes as requested by the voting device while keeping a count of the number of signatures for the ESK, and finally, when requested by the voting device, the SM destroys the ESK and produces a signed Election Closeout Record stating the number of times the ESK was used. The specific minimum requirements for this are specified below.
However, nothing in this section is intended to preclude the creation of other manufacturer defined signed records by the SM to support the overall election records and audit strategy for these more complex cases. For example, the SM might implement signed daily subtotals ESK use similar to those of the Election Closeout Record for use in multi-day elections. Alternatively, the SM might accumulate and output as a part of the closeout process signed totals by ballot style or some other identifier (which implies that the SM would have to include a way to input ballot style information in its API).
Signature Modules SHALL internally generate election signature key-pairs (ESK) using an integral nondeterministic random bit generator.
Applies To: Programmed device
Test Reference: Part 3: 3.2 “Functional Testing”, 4.1 “Initial Review of Documentation”, 4.5 “Source Code Review”
DISCUSSION
The ESK private key exists only in the embedded signature module. It is used with the cryptographic hashes of election records, to create signatures for election records. The ESK public key is exported from the embedded signature module in an election certificate signed by the DSK.
Source: New requirement
Signature Modules SHALL generate and output an X.509 public key certificate for each ESK generated, binding public key to the unique identification of the election, the date of issue of the certificate, the identification of the voting device (the issuer of the certificate), and, optionally, to other election relevant information.
Applies To: Programmed device
Test Reference: Part 3: 3.2 “Functional Testing”, 4.1 “Initial Review of Documentation”
DISCUSSION
An Election Public Key Certificate binds an ESK public key to a specific election and the unique name of the individual voting device (the issuer of the certificate). The issuer name should be consistent with the name in the Device Certificate. This guideline does not establish a name format for identifying elections, which might differ from jurisdiction to jurisdiction. No revocation or certificate status mechanism is required for the Election Certificates.
Source: New requirement
Signature Modules SHALL maintain an election counter that maintains a running count of each ESK generated.
Applies To: Programmed device
Test Reference: Part 3: 3.2 “Functional Testing”, 4.5 “Source Code Review”
DISCUSSION
Every election signature key created by the SM is numbered and this number is contained in the public key certificate for that key.
Source: New requirement
Embedded signature modules SHALL maintain a counter of the number of times that an ESK is used.
Applies To: Programmed device
Test Reference: Part 3: 3.2 “Functional Testing”, 4.5 “Source Code Review”
Source: New requirement
Signature Modules SHALL implement a closeout command that causes an Election Key Closeout record to be created and output, and the private component of the ESK to be destroyed.
Applies To: Programmed device
Test Reference: Part 3: 3.2 “Functional Testing”, 4.5 “Source Code Review”
DISCUSSION
When the election is complete, the ESK private key is destroyed so that election records cannot be forged at a later time.
Source: New requirement
The Election Key Closeout record SHALL be signed by the DSK and contain at least:
Applies To: Programmed device
Test Reference: Part 3: 3.2 “Functional Testing”
DISCUSSION
The Election Key Closeout Record provides a signed record attesting to the destruction of the particular ESK and the number of signatures executed with the ESK. The number of signed election records should match the ESK use counter; this should be checked by tally devices, and any discrepancies flagged and investigated. The format of the Election Key Closeout Record is not specified and might be either a signed XML object or it might, potentially, use another signed format such as the ASN.1 Cryptographic Message Syntax.
Source: New requirement
This section provides requirements supporting the capability to verify properties of voting devices to help with the management and maintenance of voting devices during the election process. The requirements support the inspection of a voting device to determine that: (a) software installed on the voting device can be identified and verified; (b) the contents of the voting device’s registers and variables can be determined; and (c) components of the voting device (such as touch screens, batteries, power supplies, etc.) are within proper tolerances, functioning properly, and ready for use. The requirements found in this section are derived from requirements found in commercial and federal standards such as Voluntary Voting System Guidelines 2005 [VVSG2005] and IEEE P1583 Draft Standard for the Evaluation of Voting Equipment [P1583].
The requirements found in this section provide the ability to identify and verify voting system software installed on programmed devices of the voting system.
Programmed devices can be inspected to locate and identify the software stored on the device. Programmed devices that store software on devices with a file system can use directory paths and filenames to locate and identify software. When programmed devices store software on devices without file systems, a device’s storage locations (such as memory addresses) can be used to locate the software. However, other information (such as byte strings) may be needed to identify software residing in the storage locations of the device.
The integrity of software installed on programmed devices can be inspected to determine if software has been modified. Software verification techniques use software reference information (such as digital signatures) to determine if the software has been modified. Although software validation techniques can detect modifications, they cannot determine the reason a modification to the software occurs – malicious intent or accidental error. Software reference information (such as digital signatures) from the test lab, National Software Reference Library (NSRL), or other notary repositories can be used to determine if software has been modified.
The voting device SHALL be able to identify all software installed on programmed devices of the voting device.
Applies To: Voting device
Test Reference: Part 3: 5.2 “Functional Testing”
DISCUSSION
Software stored on programmed devices with file systems can use directory paths and filenames to locate and identify software. When software is stored on programmed devices without file systems, a device’s storage locations (such as memory addresses) can be used to locate the software. However, other information (such as byte strings) may be needed to identify software residing in the storage locations of the programmed device. This requirement generalizes [VVSG2005] I.7.4.6-c by not assuming that the software being identified is stored in a device with a file system.
Source: [VVSG2005] I.7.4.6 (c)
Voting devices SHALL be capable of a software identification verification inspection that records, minimally, the following information to the device’s event log:
Applies To: Voting device
Test Reference: Part 3: 5.2 “Functional Testing”
Source: [VVSG2005] I.5.4.2
EMSs and other programmed devices that identify and authenticate individuals also SHALL record identifying information of the individual and role that performed the inspection.
Applies To: Programmed device
Test Reference: Part 3: 5.2 “Functional Testing”
Source: [VVSG2005] I.5.4.2
The voting device SHALL verify the integrity of software installed on programmed devices using cryptographic software reference information from the National Software Reference Library (NSRL), voting device owner, or designated notary repositories.
Applies To: Voting device
Test Reference: Part 3: 5.2 “Functional Testing”
DISCUSSION
Cryptographic software reference information includes digital signatures and hash values. Notary repositories use software they receive to generate software integrity information (such as digital signatures or hash values) which can be used to verify the integrity of the piece of software. Notary repositories distribute software integrity information but they do not distribute the voting software or the software used to generate the software integrity information. This requirement updates [VVSG2005] I.7.4.6-b by creating a stand-alone requirement to verify that software installed on programmed devices of the voting device has not been modified.
Source: [VVSG2005] I.7.4.6 (b)
Voting devices SHALL be capable of performing a software integrity verification inspection that records, minimally, the following information to the device’s event log:
Applies To: Voting device
Test Reference: Part 3: 5.2 “Functional Testing”
Source: [VVSG2005] I.5.4.2
EMSs and other programmed devices that identify and authenticate individuals also SHALL record identifying information of the individual and role that performed the inspection.
Applies To: Programmed device
Test Reference: Part 3: 5.2 “Functional Testing”
Source: [VVSG2005] I.5.4.2
The requirements found in this section provide the ability to inspect contents of storage locations that hold election information for a voting device.
Voting devices can be inspected to determine the content for storage locations that hold election information. Storage locations can hold election information that changes, such as accumulation registers, or information that does not change during an election. The proper initial and constant values of storage locations use to hold election information can be determined from documentation provided by manufacturers and jurisdictions before a voting device is used during an election.
The voting device SHALL be able to determine the values contained in storage locations used to hold election information that changes during the election such as the number of ballots cast or total for a given contest.
Applies To: Voting device
Test Reference: Part 3: 5.2 “Functional Testing”
DISCUSSION
This requirement restates [VVSG2005] I.7.4.6-f with some word changes.
Source: [VVSG2005] I.7.4.6 (f), I.2.2.5 (e), I.2.2.6 (b)
Voting devices SHALL be capable of performing an election information inspection that records, minimally, the following information to the device’s event log:
Applies To: Voting device
Test Reference: Part 3: 5.2 “Functional Testing”
Source: [VVSG2005] I.5.4.2, I.2.2.5, I.2.2.6
EMSs and programmed devices that identify and authenticate individuals also SHALL record identifying information of the individual and role that performed the inspection.
Applies To: Programmed device
Test Reference: Part 3: 5.2 “Functional Testing”
Source: [VVSG2005] I.5.4.2, I.2.2.5, I.2.2.6
In addition to the inspection of the software, registers, and variables, other properties can be inspected to determine if a voting device is ready. These other properties that can be inspected include: (a) the connections of the cables (network, power, etc.); (b) the calibration and function of input and output interfaces such as touch screens; (c) the current level of consumables (paper, ink, battery, etc.); and (d) the state of physical mechanisms (such as locks, tamper evident tape, enclosure panels, etc.) used to protect input and output interfaces. In addition, a voting device can perform tests to exercise the functionality of voting equipment components to determine if the components are malfunctioning or misconfigured.
The voting device SHALL indicate the remaining charge of backup power sources in quarterly increments (i.e. full, three-quarters full, half-full, quarter full, empty) at a minimum without the use of software.
Applies To: Voting device
Test Reference: Part 3: 5.2 “Functional Testing”
DISCUSSION
Backup power sources for voting equipment include but are not limited to batteries.
Source: New requirement
The voting device SHALL indicate the connectivity of cabling attached to the voting device without the use of software.
Applies To: Voting device
Test Reference: Part 3: 5.2 “Functional Testing”
DISCUSSION
For example, LEDs can be used to indicate when power cables are connected and conducting electricity. LEDs can also be used to indicate when network cables are connected and can transmit information.
Source: New requirement
The voting device SHALL indicate the operational status of the communications capability of the voting device.
The voting device SHALL indicate when the communications capability of the voting device is on/off without the use of software.
Applies To: Voting device
Test Reference: Part 3: 5.2 “Functional Testing”
DISCUSSION
For example, LEDs can be used to indicate when a given device is on or off. Physical switches can be used to physically turn on or off devices.
Source: New requirement
The voting device SHALL indicate the remaining amount of voting device consumables (i.e. ink, paper, etc.) in quarterly increments (i.e. full, three-quarters full, half-full, quarter full, empty) at a minimum.
The voting device SHALL be able to determine the calibration of voting device components that require calibration.
Applies To: Voting device
Test Reference: Part 3: 5.2 “Functional Testing”
DISCUSSION
Examples of voting device components that may require calibration are touch screens and optical scan sensors.
Source: New requirement
The voting device SHALL be able adjust the calibration of voting device components that require calibration.
Voting devices SHALL be capable of performing a device properties inspection that records, minimally, the following information to the device’s event log:
Applies To: Voting device
Test Reference: Part 3: 5.2 “Functional Testing”
Source: [VVSG2005] I.5.4.2
EMSs and other programmed devices that identify and authenticate individuals also SHALL record identifying information of the individual and role that performed the inspection.
Applies To: Programmed device
Test Reference: Part 3: 5.2 “Functional Testing”
Source: [VVSG2005] I.5.4.2
The following requirements support the installation of voting system software on programmed devices of the voting system. The requirements support the authentication and integrity of voting system software using digital signatures provided by test labs, National Software Reference Library (NSRL), and notary repositories. Notary repositories distribute software integrity information (such as digital signatures and hash values) they generate. However, notary repositories do not distribute the voting software they receive or the software used to generate the software integrity information.
Vote-capture devices SHALL only allow software to be installed while in the pre-voting state.
Applies To: Vote-capture device
Test Reference: Part 3: 5.2 “Functional Testing”
DISCUSSION
See Part 1: 8.2 “Vote-Capture Device State Model (informative)” for modes specified for vote-capture devices.
Source: New requirement
Programmed devices SHALL allow only authenticated administrators to install software on voting equipment.
Applies To: Programmed device
Test Reference: Part 3: 4.5 “Source Code Review”, 5.2 “Functional Testing”
DISCUSSION
This requirement mandates that, for all programmed devices, authentication of an administrator must be performed for allowing software to be installed.
Source: New requirement
The EMS SHALL uniquely authenticate individuals associated with the administrator role before allowing software to be installed on the voting equipment.
Applies To: EMS
Test Reference: Part 3: 4.5 “Source Code Review”, 5.2 “Functional Testing”
DISCUSSION
The EMS must authenticate the individual administrator, e.g., the administrator’s user account name.
Source: New requirements
Programmed devices SHALL only allow authenticated central election officials to install election-specific software and data files on voting equipment.
Applies To: Programmed device
Test Reference: Part 3: 4.5 “Source Code Review”, 5.2 “Functional Testing”
DISCUSSION
This requirement strengthens the base authentication required for software installation by requiring additional authentication to perform updates to election-specific software by the central election official role.
Source: New requirement
The EMS SHALL uniquely authenticate individuals associated with the central election official role before allowing election-specific software and data files to be installed on the voting equipment.
Applies To: EMS
Test Reference: Part 3: 5.2 “Functional Testing”
DISCUSSION
This requirement strengthens the base authentication required for software installation by requiring additional individual authentication for election-specific software installation by the central election official role.
Source: New requirement
Software on programmed devices of the voting system SHALL only be able to be installed using the procedures in the user documentation.
Applies To: Programmed device
Test Reference: Part 3: 5.2 “Functional Testing”
DISCUSSION
Requirement Part 2: 4.3.3-F requires manufacturers to document the procedures used to install software on programmed devices of the voting system
Source: New requirement
A test lab, National Software Reference Library (NSRL), or notary repository digital signature associated with the software SHALL be successfully validated before placing the software on programmed devices of voting systems.
Applies To: Programmed device
Test Reference: Part 3: 5.2 “Functional Testing”
DISCUSSION
This requirement checks that software is an unaltered version of the software traceable back to a test lab, National Software Reference Library (NSRL), or notary repository. Notary repositories such as the NSRL use software they receive to generate software integrity information (such as digital signatures or hash values) which can be used to verify the integrity of the piece of software. Notary repositories distribute software integrity information but they do not distribute the voting software or the software used to generate the software integrity information. This requirement modifies [VVSG2005] 7.4.6-b, which requires manufacturers to have a process to verify software using reference information from the NSRL or from a state designated repository. This requirement instead requires that software must be validated using information from the NSRL prior to installation on the voting device.
Source: [VVSG2005] I.7.4.6-b
Software installation programs SHALL validate a test lab, National Software Reference Library (NSRL), or notary repository digital signature of the software before installing software on programmed devices of voting systems.
Applies To: Programmed device
Test Reference: Part 3: 4.5 “Source Code Review”, 5.2 “Functional Testing”
Source: New requirement
The results of digital signature verifications including who generated the signature SHALL be part of the software installation record.
Applies To: Programmed device
Test Reference: Part 3: 5.2 “Functional Testing” as part of Requirement Part 1: 5.3-G
Source: New requirement
When installation of software fails, software installation programs SHALL provide an externally visible error message identifying the software that has failed to be installed on programmed devices of the voting system.
Applies To: Programmed device
Test Reference: Part 3: 5.2 “Functional Testing”
Source: New requirement
Programmed devices SHALL be able to log, minimally, the following information associated with each piece of software installed to the device’s event log:
Applies To: Programmed device
Test Reference: Part 3: 5.2 “Functional Testing”
Source: New requirement
EMSs and other programmed devices that identify and authenticate individuals also SHALL record identifying information of the individual and role performing the software installation.
Applies To: Programmed device
Test Reference: Part 3: 5.2 “Functional Testing”
Source: New requirement
Programmed devices SHALL allow only authenticated administrators to access and modify voting device configuration file(s).
Applies To: Programmed device
Test Reference: Part 3: 4.5 “Source Code Review”, 5.2 “Functional Testing”
Source: New requirement
The EMS SHALL uniquely authenticate individuals associated with the administrator role before allowing them to access and modify voting device configuration files.
Applies To: EMS
Test Reference: Part 3: 4.5 “Source Code Review”, 5.2 “Functional Testing”
Source: New requirement
Programmed device SHALL allow authenticated only central election officials to access and modify election specific configuration files.
Applies To: Programmed device
Test Reference: Part 3: 4.5 “Source Code Review”, 5.2 “Functional Testing”
Source: New requirement
The EMS SHALL uniquely authenticate individuals associated with the central election official role before allowing them to access and modify voting device configuration files.
Applies To: EMS
Test Reference: Part 3: 4.5 “Source Code Review”, 5.2 “Functional Testing”
Source: New requirement
Programmed devices SHALL be able to log, minimally, the following information associated with configuration file accesses:
Applies To: Programmed device
Test Reference: Part 3: 5.2 “Functional Testing”
Source: New requirement
EMSs and other Programmed devices that identify and authenticate individuals also SHALL record identifying information of the individual and role accessing the configuration file.
Applies To: Programmed device
Test Reference: Part 3: 5.2 “Functional Testing”
Source: New requirement
The purpose of access controls is to limit the rights of authorized users, applications, or processes and prevent unauthorized use of a resource or use of a resource in an unauthorized manner. The core components of access control include identification, authentication, enforcement, and policy. Access control mechanisms authenticate, authorize, and log access to resources to protect voting system integrity, availability, confidentiality, and accountability. The intent of the standard is that access controls should provide reasonable assurance that voting system resources such as data files, application programs, underlying operating systems, and voting system devices are protected against unauthorized access, operation, modification, disclosure, loss, or impairment.
This section addresses voting system capabilities that limit and detect access to critical voting system components in order to guard against loss of system and data integrity, availability, confidentiality, and accountability in voting systems. Access controls may be implemented in the voting software or provided by the underlying operating system or separate application programs.
Access controls include physical controls, such as keeping voting devices in locked rooms to limit physical access, and technical controls, such as security software programs designed to prevent and detect unauthorized access to resources.
General requirements address the high-level functionality of a voting system. These are the fundamental access control requirements upon which other requirements in this section are based.
The voting device SHALL provide access control mechanisms designed to permit authorized access to the voting system and to prevent unauthorized access to the voting system.
Applies To: Voting device
Test Reference: Part 3: 5.2 “Functional Testing”
DISCUSSION
Access controls support the following security principles in terms of voting systems:
This requirement extends [VVSG2005] I.7.2.1.2 by requiring controlled access to voting device components and by requiring access control mechanisms.
Source: [VVSG2005] I.7.2.1.2-1, I.7.2.1.2-2
The access control mechanisms of the voting device SHALL be capable of identifying and authenticating roles from Part 1: Table 5-1 permitted to perform operations on the voting device.
Applies To: Voting device
Test Reference: Part 3: 4.5 “Source Code Review”, 5.2 “Functional Testing”
DISCUSSION
Part 1: Table 5-1 provides the roles that must be supported by the voting device. Role-based identification identifies users, applications, and processes based on roles in an organization. Each role has defined permissions within the voting system. Users may authenticate to the voting system using a user account, then assume a role. Accountability is provided for each role within the voting system. The role-based access control method uses rules to define permissions.
Source: New requirement
Table 5-1 Voting system minimum groups and roles
Group or Role |
Description |
Voter |
The voter role is a restricted process in the vote-capture device. It allows the vote-capture device to enter the Activated state for voting activities. |
Election Judge |
The election judge has the ability to open the polls, close the polls, handle fled voters, recover from errors, and generate reports. |
Poll Worker |
The poll worker checks in voters and activates the ballot style. |
Central Election Official |
The central election official loads ballot definition files. |
Administrator |
The administrator updates and configures the voting devices and troubleshoots system problems. |
The access control mechanisms of the EMS SHALL be capable of identifying and authenticating individuals permitted to perform operations on the EMS.
Applies To: EMS
Test Reference: Part 3: 4.5 “Source Code Review”, 5.2 “Functional Testing”
DISCUSSION
Identity-based identification explicitly identifies a user, application, or process by the use of a unique system-wide identifier, such as an account. Each identity has defined permissions in the voting system. Accountability is provided for each identity within the voting system. Identity-based access control methods use rules to define permissions. Rules may be used in a voting system to provide access policies for identity-based access control.
Source: New requirement
The voting device SHALL provide controls that permit or deny access to the device’s software and files.
Applies To: Voting device
Test Reference: Part 3: 5.2 “Functional Testing”
DISCUSSION
A voting device’s software includes voting application software and third party software such as the operating system, drivers, and databases. This requirement extends [VVSG2005].
Source: [VVSG2005] I.7.2.1.2-1
The vote-capture device’s access control mechanisms SHALL distinguish at least the following voting states from Part 1: Table 5-2:
Applies To: Vote-capture device
Test Reference: Part 3: 5.2 “Functional Testing”
DISCUSSION
Part 1: Table 5-2 shows the minimum states based on Part 1 Sections 8.1 and 8.2. See Part 1 Section 8.2 for additional description of the voting states for vote-capture devices.
Source: [VVSG2005] I.7.2.1,I.7.2.1.1
Table 5-2 Vote-capture device minimum states
State |
Description |
Pre-voting |
Power-on, loading and configuring device software, maintenance, loading election-specific files, preparing for election day usage. |
Activated |
Activating the ballot, printing, casting, spoiling the ballot. |
Suspended |
Entered when an election official suspends voting. |
Post-voting |
Closing polls, tabulation, printing records, power-off. |
The Vote-capture device SHALL allow the administrator group or role to configure different access control policies available in each voting state.
Applies To: Vote-capture device
Test Reference: Part 3: 5.2 “Functional Testing”
DISCUSSION
Activated state should offer a strict subset of functions limited to voting only. Pre-voting and post-voting states and other defined states may be used for other functions such as defining the ballot, collecting votes, updating software, and performing other administrative and maintenance functions. For more examples, see Part 1: Table 5-3. This requirement extends [VVSG2005] I. 7.2 by establishing vote-capture device policies for each voting state in relation to access control.
Source: [VVSG2005] I.7.2.1.1
The voting device’s default access control permissions SHALL implement the minimum permissions needed for each role or group.
Applies To: Voting device
Test Reference: Part 3: 5.2 “Functional Testing”
DISCUSSION
Minimum permissions restrict the group or role to access only the information and resources that are necessary for its purpose. This requirement extends [VVSG2005] I. 7.2.1.1 and I.7.2.1.2 by requiring minimum default access control permissions.
Source: [VVSG2005] I.7.2.1.1, I.7.2.1.2-1
The voting device SHALL prevent a lower-privilege process from modifying a higher-privilege process.
Applies To: Voting device
Test Reference: Part 3: 5.2 “Functional Testing”
DISCUSSION
This requirement extends [VVSG2005] I.7.2.1 by preventing unauthorized process modification.
The voting device SHALL ensure that an administrator authorizes each privileged operation.
Applies To: Voting device
Test Reference: Part 3: 5.2 “Functional Testing”
DISCUSSION
This requirement extends [VVSG2005] I.7.2 by requiring authorization of privileged operations.
The voting device SHALL prevent modification to or tampering with software or firmware through any means other than the documented procedure for software upgrade.
Applies To: Voting device
Test Reference: Part 3: 5.2 “Functional Testing”
DISCUSSION
This requirement is intended to ensure that there are no ways, other than the documented procedure for software upgrade, to upgrade or modify the software. This requirement aims to protect against software vulnerabilities that would allow an unauthorized individual to secretly update, modify, or tamper with the installed software. This requirement extends [VVSG2005] I.7.2 by requiring prevention of modification and tampering with software and firmware.
Identification requirements provide controls for accountability when operating and administering a voting system. Identification applies to users, applications, and processes.
The voting device SHALL identify users, applications, and processes to which access is granted and the specific functions and data to which each entity holds authorized access.
Applies To: Voting device
Test Reference: Part 3: 5.2 “Functional Testing”
DISCUSSION
This requirement updates [VVSG2005] I.7.2.1.1-a by requiring that the voting device identify users, applications, and processes. It also requires that identification use either identity-based or role-based methods.
Source: [VVSG2005] I.7.2.1.1
Voting devices that implement role-based access control SHALL support the recommendations for Core RBAC in the ANSI INCITS 359-2004 American National Standard for Information Technology – Role Based Access Control document.
Applies To: Voting device
Test Reference: Part 3: 5.2 “Functional Testing”
DISCUSSION
This requirement extends [VVSG2005] I. 7.2.1.1-a by requiring role-based methods to follow ANSI INCITS 359-2004.
Source: [VVSG2005] I.7.2.1.1
The voting device SHALL identify, at a minimum, the groups or roles outlined in Part 1: Table 5-1.
Applies To: Voting device
Test Reference: Part 3: 5.2 “Functional Testing”
DISCUSSION
A group in a voting system is defined as a set of users, applications, or processes who share the same set of privileges and access permissions. In role-based access control methods a role serves the same purpose as a group. In identity-based access control methods groups are created, members are assigned to the groups, and permissions and privileges are applied to the group as a whole. The term groups and roles are often used interchangeably. provides example activities for each role and is not meant to include all activities performed by each role.
This requirement extends [VVSG2005] I.7.2.1.1-a by establishing minimum group or role categories. It also allows each category to apply to different voting states of operation and perform different functions.
Source: [VVSG2005] I.7.2.1.1
The EMS SHALL individually identify the members within all groups or roles except the voting group.
Applies To: EMS
Test Reference: Part 3: 4.4 “Manufacturer Practices for Quality Assurance and Configuration Management”
DISCUSSION
This requirement extends [VVSG2005] I.7.2.1.1-a by requiring members of groups or roles to be identified explicitly.
Source: [VVSG2005] I.7.2.1.1
The voting device SHALL allow the administrator group or role to configure the permissions and functionality for each identity, group or role to include account and group/role creation, modification, and deletion.
Applies To: Voting device
Test Reference: Part 3: 5.2 “Functional Testing”
DISCUSSION
For vote-capture devices, each group/role may or may not have permissions for every voting state. Additionally the permissions that a group/role has for a voting state may be restricted to certain functions. Part 1: Table 5-3 shows an example matrix of group or role to voting state access rights; the table is not meant to include all activities. This requirement extends [VVSG2005] I.7.2.1.1-a by allowing configuration flexibility for permissions and functionality for each identity, group, or role.
Source: [VVSG2005] I.7.2.1.1
Table 5-3 Roles and voting states access matrix
Role |
Pre-voting |
Activated |
Suspended |
Post-voting |
Voter |
N/A |
Cast and cancel ballots |
N/A |
N/A |
Election Judge |
Open polls |
Close polls, enter suspended state, handle fled voters, and recover from errors |
Exit suspended state |
Generate reports |
Poll Worker |
N/A |
Activate ballot |
N/A |
N/A |
Central Election Official |
Define and load ballot |
N/A |
N/A |
Reconcile Provisional-challenged ballots, write-ins, Generate reports |
Administrator |
Full access |
Full access |
Full access |
Full access |
Application or Process |
Custom per application or process |
Custom per application or process |
Custom per application or process |
Custom per application or process |
Authentication establishes the validity of the identity of the user, application, or process interacting with the voting device. Authentication is based on the identification provided by the user, application, or process interacting with the voting device. User authentication is generally classified in one of the following three categories:
(a) Something the user knows – this is usually a password, pass phrase, or PIN
(b) Something the user has – this is usually a token that may be either hardware or software based, such as a smart card
(c) Something the user is – this is usually a fingerprint, retina patter, voice pattern or other biometric data
Traditional password authentication is a single factor authentication method. A more secure method of authentication combines the various methods of authentication into two-factor authentication, or multi-factor authentication. For example, a user may use a authentication token and a passphrase for authentication. Using multi-factor provides stronger authentication than single factor. There are also cryptographic-based authentication methods such as digital signatures and challenge-response authentication, which are either software or hardware-based based tokens. Applications and processes use programmatic methods of authentication such as digital signatures and certificates.
The voting device SHALL authenticate users per the minimum authentication methods outlined in Part 1: Table 5-4.
Applies To: Voting device
Test Reference: Part 3: 5.2 “Functional Testing”
DISCUSSION
Part 1: Table 5-4 provides the minimum authentication methods required for each group or role. Stronger authentication methods than the minimum may be used for each group or role. This requirement extends [VVSG2005] I.7.2.1.2-e by requiring a minimum level of robustness for user authentication mechanisms.
Source: [VVSG2005] I.7.2.1.2-1
The voting device SHALL provide multiple authentication methods to support multi-factor authentication.
Applies To: Voting device
Test Reference: Part 3: 5.2 “Functional Testing”
DISCUSSION
This requirement is needed to support the multi-factor authentication of the administrator group or role.
Source: [VVSG2005] I.7.2.1.2-1
The voting device SHALL authenticate the administrator group or role with a multi-factor authentication mechanism.
Applies To: Voting device
Test Reference: Part 3: 5.2 “Functional Testing”
DISCUSSION
This requirement extends [VVSG2005] I.7.2.1.2-e by requiring multi-factor authentication for the voting device administrator group or role.
Source: [VVSG2005] I.7.2.1.2-1
Table 5-4 Minimum authentication methods for groups and roles
Group or Role |
Minimum Authentication Method |
Election Judge |
User name and password |
Poll Worker |
N/A – poll worker does not authenticate to voting system |
Central Election Official |
User name and password |
Administrator |
Two-factor authentication |
Application or Process |
Digital certificate or signature |
When private or secret authentication data is stored in the voting device, the data SHALL be protected to ensure that the confidentiality and integrity of the data is not violated.
Applies To: Voting device
Test Reference: Part 3: 4.5 “Source Code Review”, 5.2 “Functional Testing”
DISCUSSION
Ensuring the privacy and secrecy of stored data may involve the use of encryption. This requirement extends [VVSG2005] I.7.2.1.2-g by requiring securely stored private or secret authentication data.
Source: [VVSG2005] I.7.2.1.2-1
The voting device SHALL allow the administrator group or role to set and change passwords, pass phrases, and keys.
Applies To: Voting device
Test Reference: Part 3: 5.2 “Functional Testing”
DISCUSSION
This requirement support jurisdictions have different policies regarding passwords, pass phrases, and keys. This requirement extends [VVSG2005] I.7.2.1.2-e by allowing the administrator group or role flexibility in creation and modification of passwords, pass phrases, and keys.
Source: [VVSG2005] I.7.2.1.2-1
The voting device SHALL allow privileged groups or roles to be disabled and allow new individual privileged groups or roles to be created.
Applies To: Voting device
Test Reference: Part 3: 5.2 “Functional Testing”
DISCUSSION
Privileged accounts include any accounts within the operating system, voting device software, or other third party software with elevated privileges such as administrator, root, and maintenance accounts. This requirement extends [VVSG2005] I.7.2.1.2 by allowing the creation and disabling of privileged accounts.
Source: [VVSG2005] I.7.2.1.2-1
The voting device SHALL lock out groups, roles, or individuals after a specified number ofconsecutivefailed authentications attempts within a pre-defined time period.
Applies To: Voting device
Test Reference: Part 3: 5.2 “Functional Testing”
DISCUSSION
This requirement extends [VVSG2005] I.7.2.1.2 by requiring account lockout after a specified number of consecutive failed access attempts.
Source: [VVSG2005] I.7.2.1.2-1
The voting device SHALL allow the administrator group or role to configure the account lock out policy including the time period within which failed attempts must occur, the number of consecutive failed access attempts allowed before lock out, and the length of time the account is locked out.
Applies To: Voting device
Test Reference: Part 3: 5.2 “Functional Testing”
DISCUSSION
This requirement extends [VVSG2005] I.7.2.1.2 by allowing the administrator group or role flexibility in configuring the account lockout policy.
Source: [VVSG2005] I.7.2.1.2-1
If the voting device uses a user name and password authentication method, the voting device SHALL allow the administrator to enforce password strength, histories, and expiration.
Applies To: Voting device
Test Reference: Part 3: 5.2 “Functional Testing”
DISCUSSION
This requirement extends [VVSG2005] I.7.2.1.2-e by requiring strong passwords, password histories, and password expiration.
Source: [VVSG2005] I.7.2.1.2-1
The voting device SHALL allow the administrator group or role to specify password strength for all accounts including minimum password length, use of capitalized letters, use of numeric characters, and use of non-alphanumeric characters per NIST 800-63 Electronic Authentication Guideline standards.
Applies To: Voting device
Test Reference: Part 3: 5.2 “Functional Testing”
DISCUSSION
This requirement extends [VVSG2005] I.7.2.1.2-e by allowing the administrator group or role flexibility in configuring password strength. It also requires the use of NIST 800-63 standards.
Source: [VVSG2005] I.7.2.1.2-1
The voting device SHALL enforce password histories and allow the administrator to configure the history length.
Applies To: Voting device
Test Reference: Part 3: 5.2 “Functional Testing”
DISCUSSION
Password histories are a log of previously used passwords for automatic comparison with a new chosen password. The password history is used to ensure that recently used passwords are not used again within a pre-defined number of password changes (i.e., history length). This requirement extends [VVSG2005] I.7.2.1.2-e by allowing the administrator group or role flexibility in configuring password history.
Source: [VVSG2005] I.7.2.1.2-1
The voting device SHALL ensure that the username is not used in the password.
Applies To: Voting device
Test Reference: Part 3: 5.2 “Functional Testing”
DISCUSSION
This requirement extends [VVSG2005] I.7.2.1.2-e by restricting the use or usernames and related information in passwords.
Source: [VVSG2005] I.7.2.1.2-1
The voting device SHALL provide a means to automatically expire passwords in accordance with the voting jurisdiction’s policies.
Applies To: Voting device
Test Reference: Part 3: 5.2 “Functional Testing”
DISCUSSION
Jurisdiction policies often expire passwords after each election. This requirement extends [VVSG2005] I.7.2.1.2-e by requiring the expiration of unchanged passwords.
Source: [VVSG2005] I.7.2.1.2-1
Authorization is the process of determining access rights based on authentication of a user, application, or process within a voting device. Authorization permits or denies access to an object by a subject. Subjects may be users, applications, or processes that interact with the voting device. Objects may be files or programs within the voting device.
The voting device SHALL ensure that only authorized roles, groups, or individuals have access to election data.
Applies To: Voting device
Test Reference: Part 3: 5.2 “Functional Testing”
DISCUSSION
This requirement extends [VVSG2005] I.7.2.1.2-a by restricting access to election data to authorized accounts.
Source: [VVSG2005] I.7.2.1.2-1
The voting device SHALL enforce separation of duty across subjects based on user identity, groups, or roles.
Applies To: Voting device
Test Reference: Part 3: 5.2 “Functional Testing”
DISCUSSION
This requirement extends [VVSG2005] I.7.2.1.2 by requiring separation of duty.
Source: [VVSG2005] I.7.2.1.2-1
The voting device SHALL provide dual person control for administrative activities.
Applies To: Voting device
Test Reference: Part 3: 5.2 “Functional Testing”
DISCUSSION
This requirement extends [VVSG2005] I.7.2.1.2-a by requiring dual person control for administrative activities.
Source: [VVSG2005] I.7.2.1.2-1
The voting device SHALL explicitly authorize subjects’ access based on access control lists or policies.
Applies To: Voting device
Test Reference: Part 3: 5.2 “Functional Testing”
DISCUSSION
This requirement extends [VVSG2005] I.7.2.1.2-a by requiring explicit authorization of subjects based on access control policies.
Source: [VVSG2005] I.7.2.1.2-1
The voting device SHALL explicitly deny subjects access based on access control lists or policies.
Applies To: Voting device
Test Reference: Part 3: 5.2 “Functional Testing”
DISCUSSION
This requirement extends [VVSG2005] I.7.2.1.2-a by requiring explicit denying of subjects access based on access control policies.
Source: [VVSG2005] I.7.2.1.2-1
The voting device SHALL limit the length of authorization to a specific time, time interval, or voting state.
Applies To: Voting device
Test Reference: Part 3: 5.2 “Functional Testing”
DISCUSSION
This requirement extends [VVSG2005] I.7.2.1.1-b by requiring limitations on authorization by time or voting state.
Source: [VVSG2005] I.7.2.1.2-1
This chapter is a guideline for securely deploying and maintaining voting system electronic devices across all system modes of voting. It is inclusive of platform security configuration including network interfaces. In many ways, security of the electronic devices is subject to the current voting system state. Perhaps more importantly, the voting system state is an indicator of who requires access to any given device. This factor significantly influences security measures.
There are some similarities between voting machines and gaming machines. As a method of assuring completeness of requirements, the Nevada Gaming Commission’s [NGC06] technical standards on gaming machines were consulted for applicability.
Electronic device requirements are minimum safeguards for voting platforms once the platform is deployed.
Before boot up or initialization, electronic devices SHALL verify the integrity of the components used to boot up or initialize the electronic device using a tamper-resistant hardware module.
Applies To: Electronic device
Test Reference: Part 3: 4.5 “Source Code Review”, 5.2 “Functional Testing”
DISCUSSION
A tamper-resistant hardware module, such as a trusted platform module (TPM), can be used to store the cryptographic software reference information of the components that are required to boot the electronic device. The specific types of components required for booting vary by device type, but examples of these components are boot loader files and kernel modules on a PC. The device will not boot if the files have been modified or the boot storage has been removed from the voting sys