Chapter 5: General Security Requirements
This chapter contains general requirements relating to security. It contains the following sections:
- Cryptography: Requirements relating to use of cryptography in voting systems, e.g., use of U.S. Government FIPS standards.
- Setup Inspection: Requirements that 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.
- Software Installation: Requirements that support the authentication and integrity of voting system software using digital signatures provided by test labs, National Software Reference Library (NSRL), and notary repositories.
- Access Control: Requirements that address voting system capabilities to 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.
- System Integrity Management: Requirements that address operating system security, secure boot loading, system hardening, etc.
- Communications Security: Requirements that address both the integrity of transmitted information and protect the voting system from communications based threats.
- System Event Logging: Requirements that assist in voting device troubleshooting, recording a history of voting device activity, and detecting unauthorized or malicious activity.
- Physical Security: Requirements that address the physical aspects of voting system security: locks, tamper-evident seals, etc.
5.1 Cryptography
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:
- Confidentiality: where necessary the confidentiality of voting records can be provided by encryption;
- Authentication: data and programs can be authenticated by a digital signature or message authentication codes (MAC), or by comparison of the cryptographic hashes of programs or data with the reliably known hash values of the program or data. If the program or data are altered, then that alteration is detected when the signature or MAC is verified, or the hash on the data or program is compared to the known hash value. Typically the programs loaded on voting systems and the ballot definitions used by voting systems are verified by the voting systems, while voting systems apply digital signatures to authenticate the critical audit data that they output; and
- Random number generation: random numbers are used for several purposes including the creation of cryptographic keys for cryptographic algorithms and methods to provide the services listed above, and as identifiers for voting records that can be used to identify or correlate the records without providing any information that could identify the voter.
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.
5.1.1 General cryptographic implementation
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
5.1.2 Digital signatures for election records
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
5.1.3 Key management for signature keys
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.
5.1.3.1 Device Signature Key (DSK)
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:
- to sign Election Public Key Certificates;
- to sign Election Closeout Records; and
- to sign Device Public Key Certificates.
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
5.1.4 Election Signature Key (ESK)
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:
- The election signature public key (or a message digest of that key);
- The ESK number; and
- The final value of the ESK use counter.
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
5.2 Setup Inspection
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].
5.2.1 Voting device software inspection
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.
5.2.1.1 Software identification verification
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:
- Time and date of the inspection;
- Information that uniquely identifies the software (such as software name, version, build number, etc.);
- Information that identifies the location (such as full path name or memory address); and
- Information that uniquely identifies the programmed device that was inspected.
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
5.2.1.2 Software integrity verification
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:
- Time and date of the inspection;
- Information that uniquely identifies the software (such as software name, version, build number, etc.);
- Information that identifies the software integrity verification technique used;
Results of the software verification, - Including the cryptographic software reference information used for the verification; and
- Information that uniquely identifies the voting device that contained the software that was verified.
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
5.2.2 Voting device election information inspection
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:
- Time and date of the inspection;
- Information that uniquely identifies the storage location of the information inspected;
- The value of each piece of election information; and
- Information that uniquely identifies the voting device that was inspected.
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
5.2.3 Voting equipment properties inspection
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:
- Time and date of the inspection;
- A description of the inspections performed;
- Results of each inspection; and
- Information that uniquely identifies the voting device that was inspected.
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
5.3 Software Installation
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:
- The date and time of the installation;
- The software’s filename and version;
- The location where the software is installed (such as directory path or memory addresses);
- If the software was installed successfully or not; and
- The digital signature validation results including who generated the signature.
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:
- The date and time of the access;
- The configuration file’s filename;
- An indication of the configuration file was modified; and
- The location of the configuration file (such as directory path or memory addresses).
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
5.4 Access Control
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.
5.4.1 General access control
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:
- Accountability of actions by identifying and authenticating users;
- Confidentiality of casting and storing of votes;
- Integrity of event logs, electronic records, and vote reporting; and
- Availability of the voting ballot and the ability to cast, store, and report votes.
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