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
The vote-capture device’s access control mechanisms SHALL distinguish at least the following voting states from Part 1: Table 5-2:
- Pre-voting;
- Activated;
- Suspended; and
- Post-voting.
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.
5.4.2 Access control identification
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 |
5.4.3 Access control authentication
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
5.4.4 Access control authorization
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
5.5 System Integrity Management
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.
5.5.1 Electronic devices
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 system. This requirement augments [VVSG2005] I.7.4.6 by explicitly requiring integrity checking of components used to boot up or initialize an electronic device.
Source: [VVSG2005] I.7.4.6-a, I.7.4.6-b, I.7.4.6-e
Electronic devices SHALL verify the integrity of binaries (e.g., device drivers, library files, applications, and utilities) using a tamper-resistant hardware module and confirm that the binaries have been specified by the manufacturer as being required for the current voting system state before they are executed or loaded into memory.
Applies To: Electronic device
Test Reference: Part 3: 4.5 “Source Code Review”, 5.2 “Functional Testing”
DISCUSSION
Verifying the integrity of binaries prevents modified binaries, such as those infected with malware or inadvertently corrupted by a software or hardware failure, from being executed or loaded. A tamper-resistant hardware module, such as a trusted platform module (TPM), can be used to store the cryptographic software reference information to be used to verify integrity and voting system state specifications. Binaries that are not required for a particular state should not be executed while a device is in that state. The potential impact of permitting the binaries’ execution varies depending on the state and the nature of the binaries – examples include altering or disrupting the functionality of the system.
This requirement augments [VVSG2005] 7.4.6-b by mandating cryptographic software reference information as a mechanism for verifying the integrity of binaries, by specifying that binary integrity checking must be performed before binaries are executed or loaded into memory, and by requiring that only binaries specified as required for a particular voting system mode may be executed or loaded into memory during that mode.
Source: [VVSG2005] I.7.4.6-b
Electronic devices that support multi-processing architectures SHALL logically separate each application such that applications can only access resources necessary for normal functionality.
Applies To: Electronic device
Test Reference: Part 3: 5.2 “Functional Testing”
DISCUSSION
Logically separating applications such that only required resources can be accessed is often referred to as “sandboxing” an application. It is meant to ensure that subversion of an application’s native security will not result in access beyond normal resources.
Source: [NIST05] Security Control AC-6, SC-2
5.5.2 Removable media
While removable media is used in a number of precincts as a part of the voting process, removable media is sometimes a mechanism to propagate malicious code or exfiltrate data from electronic devices. For this reason, removable media requirements focus on enabling use of removable media, while protecting the electronic device.
Electronic devices SHALL disable all removable media interfaces that are not needed for each voting system state.
Applies To: Electronic device
Test Reference: Part 3: 5.2 “Functional Testing”
DISCUSSION
Disabling a removable media interface prevents access to removable media connected to that interface. An interface may be disabled through physical or logical means. Physically securing the removable media interface prevents the insertion and removal of removable media. Logically securing the removable media interface prevents the use of removable media inserted into the electronic device, and also prevents the removal of removable media from the electronic device (e.g., ejecting a CD or dismounting a USB flash drive). See Chapter 14: Physical Security for requirements related to physical security.
Source: [NIST05] Security Control AC-3, AC-6, MP-2
5.5.3 Backup and recovery
Backup and recovery requirements describe minimum authorization, auditing, and protective measures, without regard to specific media.
Electronic devices other than EMSs SHALL NOT provide backup or restore capabilities.
Applies To: Electronic device
Test Reference: Part 3: 5.2 “Functional Testing”
DISCUSSION
Backup and restore capabilities introduce security holes into systems because backup operations could disrupt system functionality (e.g., locking files that the system needs to access) or give an attacker access to the system’s data, and restore operations could alter system functionality or data (e.g., replacing existing files with previous versions). Therefore, use of backup and restore capabilities should be minimized. EMSs are permitted, but are not required, to have backup and restore capabilities because of the types of information they store.
Source: [NIST05] Security Control SC-2
EMSs that provide backup or restore capabilities SHALL only permit backup and restore operations while not in the Activated state.
Applies To: EMS
Test Reference: Part 3: 5.2 “Functional Testing”
DISCUSSION
Backup and restore operations should not be performed while EMSs are in the Activated state because backup operations could disrupt system functionality (e.g., locking files that the system needs to access) and restore operations could alter system functionality, vote data, etc.
Source: [NIST05] Security Control SC-2
EMSs that perform backups SHALL create digital signatures, message authentication codes, or hashes for their backups so that their authenticity and integrity can be verified in the future.
Applies To: EMS
Test Reference: Part 3: 5.2 “Functional Testing”
DISCUSSION
This requirement allows EMSs to verify the authenticity and integrity of backups before restoring them.
Source: [NIST05] Security Control CP-9
EMSs that perform restores SHALL verify the authenticity and integrity of backups before restoring them.
Applies To: EMS
Test Reference: Part 3: 5.2 “Functional Testing”
Source: [NIST05] Security Control CP-10
5.5.4 Malicious software protection
As described in the National Institute of Standards and Technology Special Publication 800-83 [NIST05a], malicious software, also known as malicious code and malware, refers to a program that is inserted into a system, usually covertly, with the intent of compromising the confidentiality, integrity, or availability of the victim’s data, applications, or operating system (OS) or of otherwise annoying or disrupting the victim. For a number of reasons, electronic devices associated with voting systems may be targeted by malware. Malware is inclusive of viruses, worms, Trojan horses, and malicious mobile code, as well as combinations of these, known as blended attacks. Malware also includes attacker tools such as backdoors, rootkits, and keystroke loggers. Given this understanding of malware, requirements focus on preventing occurrences of malware on electronic devices.
EMSs SHALL use malware detection software to protect themselves from common known malware that targets their operating systems, services, and applications.
Applies To: EMS
Test Reference: Part 3: 5.2 “Functional Testing”
DISCUSSION
Off-the-shelf malware detection software, such as antivirus software, anti-spyware software, and rootkit detection, can identify common known malware that attempts to infect an electronic device, as well as identify infections on the device. The scope of this requirement is limited to EMSs because they should have the required resources to use off-the-shelf malware detection software and also because there should be off-the-shelf malware detection software available for their platforms. For many other electronic devices, neither of these conditions is true; also, some platforms do not have common known malware threats, so malware detection software would not be useful.
This requirement augments [VVSG2005] I.7.4.2 by specifying installation of malware detection/scanning software.
Source: [VVSG2005] I.7.4.2
EMSs SHALL provide a mechanism for updating the malware detection software with newer malware signatures.
Applies To: EMS
Test Reference: Part 3: 5.2 “Functional Testing”
DISCUSSION
As new malware threats are discovered, particularly threats specific to voting systems, the election management’s malware detection software may need to be updated so that it can recognize and stop these threats. Many malware detection software products use the Internet by default to retrieve updates; since the use of the Internet by electronic devices is prohibited, another mechanism is needed to distribute updates, such as using a device on the local network to distribute updates, or manually distributing updates through read-only removable media. This requirement augments [VVSG2005] 7.4.2 by specifying the capability to update malware detection software with current malware signatures.
Source: [VVSG2005] I.7.4.2
EMSs SHALL run malware detection software against removable media to verify no common known malware is present before accepting any data from the removable media.
Applies To: EMS
Test Reference: Part 3: 5.2 “Functional Testing”
DISCUSSION
This prevents the introduction of common known malware onto an electronic device from removable media. This requirement augments [VVSG2005] I.7.4.2 by specifying scanning of removable media for common known malware.
Source: [VVSG2005] I.7.4.2
EMSs SHALL be scanned for common known malware at least once every 24 hours during operation, including malware specifically targeted at voting systems.
Applies To: EMS
Test Reference: Part 3: 5.2 “Functional Testing”
DISCUSSION
This identifies any current infections on the electronic device caused by common known malware. This requirement augments [VVSG2005] I.7.4.2 by specifying scanning of removable media for common known malware.
Source: [VVSG2005] I.7.4.2
EMSs SHALL perform real-time scanning for common known malware.
Applies To: EMS
Test Reference: Part 3: 5.2 “Functional Testing”
DISCUSSION
This prevents files infected with common known malware from being executed or otherwise loaded within the electronic device. This requirement augments [VVSG2005] I.7.4.2 by specifying real-time scanning for common known malware.
Source: [VVSG2005] I.7.4.2
5.6 Communication Security
This chapter provides requirements for communications security. The requirements address both the integrity of transmitted information and protect the voting system from communications based threats.
This chapter is organized in three parts. The first set of requirements address physical communication components including the prohibition of radio frequency (RF) capable components. The second set of requirements address data transmission security requirements related to the encoding and decoding data packets, and creating logical paths for transferring data between systems. The third set of requirements address communication security related to the voting application including the authentication of communications between voting devices.
Although voting systems can have the capability to communicate with other voting devices, there are key security concerns that must be accounted for both during voting and when election administrators prepare the voting device. This chapter does not address networking issues based on hand carried electronic media, which are addressed in the Systems Integrity Management Chapter.
5.6.1 Physical communication security
This section describes security requirements for physical communication components of voting systems including the electrical and mechanical hardware that sends and receives data.
Electronic devices SHALL not be enabled or installed with any wireless technology (e.g., Wi-Fi, wireless broadband, Bluetooth) except for infrared technology when the signal path is shielded to prevent the escape of the signal and saturation jamming of the signal.
Applies To: Electronic device
Test Reference: Part 3: 4.3 “Verification of Design Requirements”
DISCUSSION
The transient and mobile properties of wireless networks are more threatening than enabling to the voting process. Wireless interfaces that are inadvertently or purposefully enabled at an electronic device are likely to leave those platforms exposed to attack and exploit, with exfiltration, manipulation, or destruction of data a possible outcome.
This requirement supersedes [VVSG2005] I.7.7 by prohibiting usage of wireless technology, except for infrared technology when the physical path is protected, in electronic voting system devices.
Source: [VVSG2005] I.7.7.1-a-h, I.7.7.2-5
Electronic devices SHALL not use public communication networks (including, but not limited to the Internet and modem usage through public telephone networks), except for electronic devices at polling places that transmit unofficial end of the day results and interface with voter registration databases on election day.
Applies To: Electronic device
Test Reference: Part 3: 4.3 “Verification of Design Requirements”
DISCUSSION
The use of public communications networks would greatly increase the exposure of electronic devices for voting to attack and exploitation. Functions such as software patch distribution may be performed either manually or through a dedicated, standalone network that is not connected to any public communications network. The excepts to this requirement allows for end of day results to be transmitted from a polling place to a central election facility and for activation devices to connect to voter registration databases housed outside of a polling place.
This requirement supersedes [VVSG2005] I.7.6 by prohibiting usage of public communication networks for electronic voting system devices.
Source: [VVSG2005] I.7.6.1, I.7.6.2.1, I.7.6.2.2
Electronic devices SHALL not be connected to other polling place electronic devices when transmitting end of the day results on election day.
Applies To: Electronic device
Test Reference: Part 3: 4.3 “Verification of Design Requirements”
DISCUSSION
This requirement is to provide an air gap between electronic devices networked at the polling place and electronic devices that connect externally from the polling place. This requirement allows for end of day results to be transmitted from a polling place to a central election facility.
Source: New requirement
Electronic devices that connect to voter registration databases outside a polling place on election day SHALL never be connected to other polling place electronic devices.
Applies To: Electronic device
Test Reference: Part 3: 4.3 “Verification of Design Requirements”
DISCUSSION
This requirement is to provide an air gap between electronic devices networked at the polling place and electronic devices that connect externally from the polling place. This requirement allows for activation devices to connect to voter registration databases housed externally from the polling place, but the activation devices cannot be connected to other polling place electronic devices.
Source: New requirement
Electronic devices SHALL have the ability to enable or disable physical network interfaces (including modems) based upon the voting system state.
Applies To: Electronic device
Test Reference: Part 3: 5.2 “Functional Testing”
DISCUSSION
Making an electronic device accessible on a network significantly increases the risk of that device to attack and exploitation. Election Officials need the ability to enable a physical network interface for use during a particular voting system state and to disable other network interfaces that are not required during that state. This reduces the exposure of the electronic devices to network-based attacks.
Source: [NIST05] Security Control AC-6
EMSs with multiple active network interfaces (including modems) SHALL not act as bridges or routers between networks that permit network traffic to pass through the electronic management systems.
Applies To: Electronic device
Test Reference: Part 3: 5.2 “Functional Testing”
DISCUSSION
Allowing network traffic to pass through a device that is not specifically designed to be part of the network/security infrastructure provides a possible method for malicious traffic to circumvent network security controls.
Source: [NIST05] Security Control AC-6
Each electronic device SHALL have a unique physical address/identifier for each network interface.
Applies To: Electronic device
Test Reference: Part 3: 4.3 “Verification of Design Requirements”
DISCUSSION
Most networking protocols require a unique physical address or other identifier for each network interface so that each network interface attached to a particular network can be uniquely identified. For example, Ethernet requires that each network interface have a unique media access code (MAC) address. Having such an identifier for each network interface is also beneficial for security because it permits each electronic device on a network to be uniquely identified.
Source: [NIST05] Security Control IA-3
5.6.2 Data transmission security
This section describes security requirements related to the encoding and decoding of data packets, and creating logical paths for transferring date between voting systems.
The manufacturer SHALL provide a listing of all network communication processes and applications required for the Electronic device to function properly.
Applies To: Electronic device
Test Reference: Part 3: 4.1 “Initial Review of Documentation”
DISCUSSION
Understanding required network processes and applications is necessary for understanding the attack exposure of any given electronic device.
This requirement generalizes [VVSG2005] I.7.5.2-b, which requires that manufacturers document all COTS hardware, and software communication devices used in the development and/or operation of the voting system if those devices are used on public communications networks. This requirement requires manufacturers to list network communication processes and applications required for the election system to function properly. There are no guidelines in the [VVSG2005] that require documentation of devices used for local networking.
This requirement augments [VVSG2005] I.7.5.1-b-ii by mandating documentation of valid processes and applications associated with network ports and protocols.
Source: [VVSG2005] I.7.5.1-b, I.7.5.2-b
Electronic devices SHALL prohibit intercommunications between electronic devices except where required for normal function.
Applies To: Electronic device
Test Reference: Part 3: 5.2 “Functional Testing”
DISCUSSION
In the interest of reducing the number of nodes accessing a given platform and potentially the voting data thereof, devices that have no need to interact over the network would be locally prohibited from those interactions. This reduces possible sources of network attack.
Source: [NIST05] Security Control AC-6
Electronic devices SHALL provide integrity protection for data in transit through generation of integrity data (digital signatures or message authentication codes) for outbound traffic and verification of the integrity data for inbound traffic.
Applies To: Electronic device
Test Reference: Part 3: 4.5 “Source Code Review”, 5.2 “Functional Testing”
DISCUSSION
Integrity protection ensures that any inadvertent or intentional alterations to data are detected by the recipient. Integrity protection for data in transit may be provided through the use of various protocols, such as IPsec VPNs and SSL/TLS.
This requirement modifies [VVSG2005] I.7.5.1, which requires use of error correcting or detecting codes, by mandating use digital signatures or message authentication codes for data integrity. These provide addition protection against threats than error detecting codes, but do not offer data correcting capabilities.
This requirement modifies [VVSG2005] I.7.5.1-a by specifying the use of cryptographic checksums (digital signatures and hashes) to be used to ensure information integrity in transit.
This requirement modifies [VVSG2005] I.7.6.1, which requires the use of digital signatures in communications over a public network between a voter server and another device. This requirement extends [VVSG2005] I.7.6.1 by requiring integrity data for all data in transit. It furthermore includes a requirement to verify the integrity data for inbound data.
This requirement extends [VVSG2005] 7.7.3-a, which requires protection against data manipulation on wireless communications, by requiring this protection on all data transmissions. Note that this document contains a prohibition against use of most wireless technology.
Source: [VVSG2005] I.7.5.1-a, I.7.6.1, I.7.7.3
5.6.3 Application communication security
This section describes security requirements related to the communications of the voting application.
Each Electronic device SHALL have a unique system identifier (ID).
Applies To: Electronic device
Test Reference: Part 3: 5.2 “Functional Testing”
DISCUSSION
System ID can be in the form of a unique system or device roles that can be used as a mechanism to filter the type of packets that are allowed or dropped by the device.
Source: [NIST05] Security Control IA-3
Electronic devices SHALL mutually authenticate using the devices’ unique system IDs before any additional network data packets are processed.
Applies To: Electronic device
Test Reference: Part 3: 4.5 “Source Code Review”, 5.2 “Functional Testing”
DISCUSSION
Mutual authentication provides assurance that each electronic device is legitimate. Mutual authentication can be performed using various protocols, such as IPsec and SSL/TLS.
Source: [NIST05] Security Control IA-3
Electronic devices SHALL have only the network ports and shares active and network services and protocols enabled as specified in Requirement 1.2.3-D.
Applies To: Electronic device
Test Reference: Part 3: 5.2 “Functional Testing”
DISCUSSION
Limiting network ports and shares and associated network services and protocols reduces the “attack surface” of the electronic devices. Attackers will have a diminishing chance of successful remote attack with each network port, share, service, and protocol that is disabled.
Source: [NIST05] Security Control AC-6
The manufacturer SHALL document all network ports, shares, services, and protocols required for the Electronic device to function properly.
Applies To: Electronic device
Test Reference: Part 1: 4.1 “Overview”
DISCUSSION
Understanding required network ports, shares (both visible and hidden/administrative), services, and protocols is necessary for understanding the attack exposure of any given electronic device. Based on local risk decisions, election officials will utilize the listing of required network ports, shares, services, and protocols to adjust configuration of an electronic device and the corresponding attack exposure.
Source: [NIST05] Security Control AC-6
The manufacturer SHALL define the minimum amount of information requested from unauthenticated devices via active network ports and shares.
Applies To: Electronic device
Test Reference: Part 1: 4.1 “Overview” as part of Requirement Part 1: 5.6.3-F
DISCUSSION
This requirement is meant to document the minimum amount and depth of information available to malicious network entities accessing the electronic device remotely. Information available through banners, help functions, and direct interaction with available ports and shares often gives remote attackers illuminating information about the electronic device. Armed with this expanded information, an attacker can evolve their attack to a more educated and specific effort, increasing probability of a successful attack.
Source: [SCAM01]
Electronic devices SHALL request no more information than required to unauthenticated devices via active network ports and shares.
Applies To: Electronic device
Test Reference: Part 3: 5.2 “Functional Testing”
DISCUSSION
This requirement is meant to minimize the amount and depth of information available to malicious network entities accessing the electronic device remotely. Information available through banners, help functions, and direct interaction with available ports and shares often gives remote attackers illuminating information about the electronic device. Armed with this expanded information, an attacker can evolve their attack to a more educated and specific effort, increasing probability of a successful attack.
Source: [SCAM01]
Electronic devices SHALL monitor inbound and outbound network communication for evidence of attack and security usage non-compliance.
Applies To: Electronic device
Test Reference: Part 3: 5.2 “Functional Testing”
DISCUSSION
Security usage non-compliance refers to instances where electronic device users are disobeying local policy.
See NIST Special Publication 800-94 – Guide to Intrusion Detection and Prevention Systems [NIST07] for more information on host and network communication monitoring and attack prevention.
This requirement extends [VVSG2005] I.7.5.1-b and I.7.5.2-a by requiring that intrusion detection systems monitor all inbound and outbound network connections, while [VVSG2005] 7.5.1-b and 7.5.2-a only require such systems monitor public communications network connections.
Source: [NIST05] Security Control S-I-4, S-I-10, I.7.5.1-b, I.7.5.2-a
Electronic devices SHALL provide the capability to stop inbound and outbound network attacks.
Applies To: Electronic device
Test Reference: Part 3: 5.2 “Functional Testing”
DISCUSSION
See NIST Special Publication 800-94 – Guide to Intrusion Detection and Prevention Systems [NIST07] for more information on host and network communication monitoring and attack prevention.
This requirement generalizes [VVSG2005] I.7.5.2-c, which describes the required capabilities of a voting device to stop an incoming attack over a network connection. This requirement further extends [VVSG2005] 7.5.2-c by requiring the ability to stop outgoing attacks as well.
Source: [NIST05] Security Control S-I-4, S-I-10, I.7.5.2-c
5.7 System Event Logging
An event is something that occurs within a voting device and a log is a record of these events that have occurred. Each log entry contains information related to a specific event. Logs are used for error reporting, auditing, troubleshooting problems, optimizing performance, recording the actions of users, and providing data useful for investigating malicious activity.
Event logs are typically divided into two categories: system events and audit records. System events are operational actions performed by voting device components, such as shutting down the voting device, starting a service, usage information, client requests, and other information. Audit records contain security event information such as successful and failed authentication attempts, file accesses, and security policy changes. Other applications and third party software, such as antivirus software and intrusion detection software also record audit logs. For the purpose of this chapter system event logging will be used to include both system and audit logs for voting devices. System event logs are of equal importance in the output of an election as the electronic CVRs and vote totals.
This chapter describes voting device capabilities that perform system event logging to assist in voting device troubleshooting, recording a history of voting device activity, and detecting unauthorized or malicious activity. It also describes the use of log management to protect the confidentiality and integrity of logs while also ensuring their availability. The voting device software, operating system, and/or applications may perform the actual system event logging. There may be multiple logs in use on a single device.
The requirements in this section protect against the following intermediate attack goals:
- The ability of an attacker to undetectably alter the logs;
- The ability of an attacker to remove an entry from the log; and
- The ability of an attacker to create an entry in the log.
This section defines the event logging requirements for voting devices. It outlines the various measures that the manufacturers and the voting device shall provide to ensure the functionality, performance, and security of the voting device event logging. These recommendations apply to the full scope of voting device functionality, including voting, pre- and post-voting activities, and maintenance of the voting device.
5.7.1 General system event logging
General requirements address the high-level functionality of a voting (programmed) device. These are the fundamental event logging requirements upon which other requirements in this section are based.
The voting device SHALL provide event logging mechanisms designed to record voting device activities.
Applies To: Programmed device
Test Reference: Part 3: 4.3 “Verification of Design Requirements”
DISCUSSION
This requirement generalizes [VVSG2005] I.2.1.5.1, which provides a basic description of required event logging functionality.
Source: [VVSG2005] I.2.1.5.1
The voting device SHALL enable file integrity protection for stored log files as part of the default configuration.
Applies To: Programmed device
Test Reference: Part 3: 4.4 “Manufacturer Practices for Quality Assurance and Configuration Management”, 4.5 “Source Code Review”
DISCUSSION
File integrity protection includes techniques such as a digital signature that would alert to data modification and tampering.
This requirement clarifies [VVSG2005] I.2.1.5.1-a-v, which requires that that the integrity of log files be maintained, by more specifically requiring that log files have integrity protection in their default configuration.
Source: [VVSG2005] I.2.1.5.1-a
The voting device logs SHALL NOT contain information that, if published, would violate ballot secrecy or voter privacy or that would compromise voting system security in any way.
Applies To: Programmed device
Test Reference: Part 3: 4.5 “Source Code Review”, 5.2 “Functional Testing”
DISCUSSION
The device must be constructed so that the security of the system does not rely upon the secrecy of the event logs. It should be considered routine for event logs to be made available to election officials and possibly even to the public, if election officials so desire. The system must be designed to permit the election officials to do so without fear of negative consequences to the security and integrity of the election. For example, cryptographic secret keys or passwords must not be logged in event log records.
Source: [VVSG2005] I.5.4
The voting device SHALL log at a minimum the following data characteristics for each type of event:
- System ID;
- Unique event ID and/or type;
- Timestamp;
- Success or failure of event, if applicable;
- User ID triggering the event, if applicable;
- Resources requested, if applicable.
Applies To: Programmed device
Test Reference: Part 3: 5.2 “Functional Testing”
DISCUSSION
This requirement clarifies and extends [VVSG2005] I.2.1.5.1-a and I.2.1.5.1-b by describing the required information that must be included with each event in the event log. [VVSG2005] 2.1.5.1-b is a requirement that discusses error messages and states that error messages must be logged. This document does not, in general, treat logging error messages differently than logging other events.
Source: [VVSG2005] I.2.1.5.1-a, I.2.1.5.1-b
Timekeeping mechanisms SHALL generate time and date values.
Applies To: Programmed device
Test Reference: Part 3: 5.2 “Functional Testing”
DISCUSSION
This requirement generalizes [VVSG2005] I.2.1.5.1-a-ii, which requires the inclusion of a real-time clock in the hardware of voting systems.
Source: [VVSG2005] I.2.1.5.1-a
The precision of the timekeeping mechanism SHALL be able to distinguish and properly order all audit records.
Applies To: Programmed device
Test Reference: Part 3: 5.2 “Functional Testing”
DISCUSSION
This requirement extends [VVSG2005] I.2.1.5.1-a by explicitly requiring that the timekeeping mechanism used to stamp audit records be precise enough to distinguish and properly order all events logged.
Source: [VVSG2005] I.2.1.5.1-a
Timestamps SHALL include date and time, including hours, minutes, and seconds.
Applies To: Programmed device
Test Reference: Part 3: 5.2 “Functional Testing”
DISCUSSION
Even if the accuracy of the clock leaves something to be desired, the seconds are useful to discern burst and gaps in the event stream.
This requirement clarifies [VVSG2005] I.2.1.5.1-a by explicitly requiring that the date, hour, minute and second be recorded for each audit record timestamp.
Source: [VVSG2005] I.2.1.5.1-a
Timestamps SHALL comply with ISO 8601 and provide all four digits of the year and include the time zone.
Applies To: Programmed device
Test Reference: Part 3: 5.2 “Functional Testing”
DISCUSSION
This requirement extends [VVSG2005] 2.1.5.1-a by requiring that timestamps comply with the ISO 8601 standard and include the time zone. The [VVSG2005] requires a timestamp, but does not specify a format.
Source: [VVSG2005] I.2.1.5.1-a
Voting devices SHALL only allow administrators to set the clock.
Applies To: Programmed device
Test Reference: Part 3: 5.2 “Functional Testing”
DISCUSSION
This requirement is needed to adjust clocks for each election. Since a voting system architecture may not support complete access control capabilities due to resource constraints, this requirement may or may apply. For example, a voting system architecture may only support a single identity, group, or role, so the ability to distinguish administrators from other users may not possible. However, when the voting system architecture has the capability to distinguish administrators from other users, the requirement must be satisfied.
Source: [VVSG2005] I.5.4
The voting device SHALL limit clock drift to a minimum of 1 minute within a 15 hour period after the clock is set.
Applies To: Programmed device
Test Reference: Part 3: 5.2 “Functional Testing”
DISCUSSION
The accuracy of the timekeeping mechanism relative to UTC (Coordinated Universal Time) may depend on application of a manufacturer-specified clock set procedure. NIST and USNO time references are far more accurate, and higher accuracy is desirable, but many clock mechanism exhibit significant drift due to temperature, etc. and simple correction methods for a fast local clock might violate the monotonic time requirement.
Source: [VVSG2005] I.5.4
The voting device SHALL log at a minimum the system events described in Part 1: Table 5-5 .
Applies To: Programmed device
Test Reference: Part 3: 5.2 “Functional Testing”
DISCUSSION
Part 1: Table 5-5 presents a minimum list of system events to be logged. The table also includes an “applies to” reference specifying the class of devices that are subject to each requirement.
This requirement clarifies and extends [VVSG2005] I.5.4.1, I.5.4.2, and I.5.4.3 by specifying a list of system events that must trigger an event log record. [VVSG2005] I.5.4.1 discusses required event log records for pre-election events. [VVSG2005] I.5.4.2 discusses required event log records for system readiness. [VVSG2005] I.5.4.3 discusses required event log records during the operation of diagnostic routines and the casting and tallying of ballots.
Source: [VVSG2005] I.5.4.1, I.5.4.2-a, I.5.4.3-a
The voting device SHALL ensure that the minimum event logging in Part 1: Table 5-5 cannot be disabled.
Applies To: Programmed device
Test Reference: Part 3: 5.2 “Functional Testing”
Source: [VVSG2005] I.5.4
Table 5-5 Minimum events to log
System Event |
Description |
Applies To |
General System Functions |
||
Device generated error and exception messages |
Includes but not limited to:
|
Programmed device |
Critical system status messages |
Critical system status messages other than information messages displayed by the device during the course of normal operations. Includes but not limited to:
|
Programmed device |
Non-critical status messages |
Non-critical status messages that are generated by the device’s data quality monitor or by software and hardware condition monitors. |
Programmed device |
Events that require election official intervention |
Events that require election official intervention, so that each election official access can be monitored and access sequence can be constructed. |
Programmed device |
Device shutdown and restarts |
Both normal and abnormal device shutdowns and restarts. |
Programmed device |
Changes to system configuration settings |
Configuration settings include but are not limited to registry keys, kernel settings, logging settings, and other voting device configuration settings. |
Programmed device |
Integrity checks for executables, configuration files, data, and logs. |
Integrity checks that may indicate possible tampering with files and data. |
Programmed device with file systems |
The addition and deletion of files. |
Files that are added or deleted from the voting device. |
Programmed device with file systems |
System readiness results |
Includes but not limited to:
|
Programmed device |
Removable media events |
Removable media that is inserted into or removed from the voting device. |
Programmed device |
Backup and restore |
Successful and failed attempts to perform backups and restores. |
Election Management Systems |
Authentication and Access Control |
||
Authentication related events |
Includes but not limited to:
|
Programmed device |
Access control related events |
Includes but not limited to:
|
Programmed device |
User account and role (or groups) management activity |
Includes but not limited to:
|
Programmed device |
Software |
||
Installation, upgrading, patching, or modification of software or firmware |
Logging for installation, upgrading, patching, or modification of software or firmware include logging what was installed, upgraded, or modified as well as a cryptographic hash or other secure identifier of the old and new versions of the data. |
Programmed device |
Changes to configuration settings |
Includes but not limited to:
|
Programmed device |
Abnormal process exits |
All abnormal process exits. |
Programmed device |
Successful and failed database connection attempts (if a database is utilized). |
All database connection attempts. |
Programmed device with database capabilities |
Cryptographic Functions |
||
Changes to cryptographic keys |
At a minimum critical cryptographic settings include key addition, key removal, and re-keying. |
Programmed device |
Voting Functions |
||
Ballot definition and modification |
During election definition and ballot preparation, the device may provide logging information for the preparation of the baseline ballot formats and modifications to them including a description of the modification and corresponding dates. Includes but not limited to:
|
Programmed device |
Voting events |
Includes:
|
Programmed device |
5.7.2 System event log management
Log management is the process for generating, transmitting, storing, analyzing, and disposing of log data. Log management primarily involves protecting the integrity of logs while also ensuring their availability. It also ensures that records are stored in sufficient detail for an appropriate period of time.
A log management infrastructure consists of the hardware, software, networks, and media used to generate, transmit, store, and analyze log data. The events outlined in this section may be logged as part of the underlying operating system, the voting device software, or other third party applications.
The voting device SHALL implement default settings for secure log management activities, including log generation, transmission, storage, analysis, and disposal.
Applies To: Voting device
Test Reference: Part 3: 4.1 “Initial Review of Documentation”
Source: [VVSG2005] I.5.4
The voting device SHALL log logging failures, log clearing, and log rotation.
Applies To: Programmed device
Test Reference: Part 3: 5.2 “Functional Testing”
DISCUSSION
A secondary logging mechanism may be used to log failures, clearing, and rotation.
Source: [VVSG2005] I.5.4
The voting device SHALL store logs in a publicly documented log format, such as XML, or include a utility to export the logs into a publicly documented format for offline viewing.
Applies To: Programmed device
Test Reference: Part 3: 4.3 “Verification of Design Requirements”
DISCUSSION
In some cases, election officials may be required to or may choose to disclose event logs in electronic form to investigators, candidates, observers, or to the public. The voting device must be designed to permit recipients of the event logs to understand and interpret the contents of the event logs and to write their own software tools to parse and analyze those event logs.
Source: [VVSG2005] I.5.4
The manufacturer SHALL ensure that the voting device is supplied with enough free storage to include several maximum size event logs.
Applies To: Programmed device
Test Reference: Part 3: 5.2 “Functional Testing”
DISCUSSION
The manufacturer should declare an upper limit on how much storage an event log might require during an election, referred to as the maximum size event log.
Source: [VVSG2005] I.5.4
The voting device SHALL be capable of retaining the event log data from previous elections.
Applies To: Programmed device
Test Reference: Part 3: 5.2 “Functional Testing”
DISCUSSION
In practice, previous event logs are typically cleared prior to the start of a new election. In some cases, jurisdictions may want to maintain previous event logs on the voting device. Event log data may be retained according to various methods including log file size, log entry counts, and time settings.
Source: [VVSG2005] I.5.4
The voting device SHALL only allow administrators to modify the log data retention settings including the actions to take when a log reaches its maximum retention such as overwriting logs, rotating logs, or halting logging.
Applies To: Programmed device
Test Reference: Part 3: 5.2 “Functional Testing”
DISCUSSION
Many event logs have a maximum size for storage, such as storing the 10,000 most recent events, or keeping 100MB of log data. When the log storage capacity is reached, the log may overwrite old data with new data or stop logging altogether. Since a voting system architecture may not support complete access control capabilities due to resource constraints, this requirement may or may apply. For example, a voting system architecture may only support a single identity, group, or role, so the ability to distinguish administrators from other users may not possible. However, when the voting system architecture has the capability to distinguish administrators from other users, the requirement must be satisfied.
Source: [VVSG2005] I.5.4
The voting device SHALL be capable of rotating the event log data to manage log file growth.
Applies To: Programmed device
Test Reference: Part 3: 5.2 “Functional Testing”
DISCUSSION
Log file rotation may involve regular (e.g., hourly, nightly, or weekly) moving of an existing log file to some other file name and/or location and starting fresh with an empty log file. Jurisdictions should ensure that the log rotation procedure includes a labeling method to identify the type of log, the system that created the logs, and the date of the logs.
Source: [VVSG2005] I.5.4
The voting device SHALL be capable of only allowing the administrator to delete previous event logs prior to starting a new election.
Applies To: Programmed device
Test Reference: Part 3: 5.2 “Functional Testing”
DISCUSSION
Since a voting system architecture may not support complete access control capabilities due to resource constraints, this requirement may or may not apply. For example, a voting system architecture may only support a single identity, group, or role, so the ability to distinguish administrators from other users may not possible. However, when the voting system architecture has the capability to distinguish administrators from other users, the requirement must be satisfied.
Source: [VVSG2005] I.5.4
The voting device SHALL restrict event log access to write or append-only for privileged logging processes and read-only for administrator accounts or roles.
Applies To: Programmed device
Test Reference: Part 3: 5.2 “Functional Testing”
DISCUSSION
Certain applications and processes need write and/or append access to system event logs in order to create entries. administrator accounts or roles need read access for log analysis and other log management activities. Since a voting system architecture may not support complete access control capabilities due to resource constraints, this requirement may or may apply. For example, a voting system architecture may only support a single identity, group, or role, so the ability to distinguish administrators from other users may not possible. However, when the voting system architecture has the capability to distinguish administrators from other users, the requirement must be satisfied.
Source: [VVSG2005] I.5.4
The voting device SHALL ensure that each election’s event logs and each device’s event logs are separable from each other.
Applies To: Programmed device
Test Reference: Part 3: 5.2 “Functional Testing”
Source: [VVSG2005] I.5.4
The voting device SHALL digitally sign and export event logs at the end of an election, along with all other election results from the device.
Applies To: Programmed device
Test Reference: Part 3: 5.2 “Functional Testing”
Source: [VVSG2005] I.5.4
The voting device SHALL include an application or program to view, analyze, and search event logs.
Applies To: Programmed device
Test Reference: Part 3: 5.2 “Functional Testing”
Source: [VVSG2005] I.5.4
The voting device SHALL halt voting activities and create an alert if the logging system malfunctions or is disabled.
Applies To: Programmed device
Test Reference: Part 3: 5.2 “Functional Testing”
Source: [VVSG2005] I.5.4
The voting device SHALL create an alert at user-defined intervals as the logs begin to fill.
Applies To: Programmed device
Test Reference: Part 3: 5.2 “Functional Testing”
DISCUSSION
User defined intervals for system event log capacity may include alerting when logs are 50%, 75%, and 95% full.
Source: [VVSG2005] I.5.4
The voting device SHALL suspend voting if the logs fill to a pre-defined capacity.
Applies To: Programmed device
Test Reference: Part 3: 5.2 “Functional Testing”
Source: [VVSG2005] I.5.4
5.7.3 System event log protection
Because logs contain voting device event records, they need to be protected from breaches of their integrity and availability. Logs that are secured improperly in storage or in transit might also be susceptible to intentional and unintentional alteration and destruction. This could cause a variety of impacts, including allowing malicious activities to go unnoticed and manipulating evidence to conceal the identity of a malicious party. For example, many rootkits are specifically designed to alter logs to remove any evidence of the rootkits’ installation or execution.
Data retention requirements might require log storage for a longer period of time than the original log sources can support, which necessitates establishing log archival processes. The integrity and availability of the archived logs also need to be protected.
The voting device SHALL protect event log information from unauthorized access, modification, and deletion.
Applies To: Programmed device
Test Reference: Part 3: 4.3 “Verification of Design Requirements”
Source: [VVSG2005] I.5.4
The voting device SHALL protect logs from unauthorized modification.
Applies To: Programmed device
Test Reference: Part 3: 5.2 “Functional Testing”
DISCUSSION
There are several ways to protect logs from modification including using operating system level security mechanisms to prevent deletion of the logs and enforce append-only access, use of append-only media, and use of cryptographic techniques.
Source: [VVSG2005] I.5.4
If the voting device provides log archival capabilities, it SHALL ensure the integrity and availability of the archived logs.
Applies To: Programmed device
Test Reference: Part 3: 4.3 “Verification of Design Requirements”
Source: [VVSG2005] I.5.4
5.8 Physical Security for Voting Devices
The objective of the voting device physical security measures is to prevent undetected, unauthorized physical access to voting devices. It is assumed that adversaries have financial resources, technical savvy, and possibly insider presence to exploit vulnerabilities within voting devices. When in use, the physical security required for voting devices is relatively low compared to other types of moderate or high impact systems. Though voting areas should be private enough to maintain a voter’s right to a secret ballot, the machines are generally not isolated. An attempt to physically open or disassemble a machine would likely not go unnoticed by poll worker. Similarly, a plot to tamper with the machines after the polls are closed would require a large conspiracy amongst poll workers, as an individual working alone would likely be noticed gaining access to machines outside of normal operating procedures. Voting devices also spend a considerable amount of time in storage or otherwise secured by means that could afford “open” though unauthorized access by well placed insiders. In that case, time and privacy are on the side of the adversary. One could not hope to stop an adversary from gaining access to the machine but one can hope to find evidence of their handiwork.
The effectiveness of all technical security safeguards is based, in part, on the assumption, either explicit or implicit, that all components have adequate physical security protection. Any unauthorized physical access must leave physical evidence that an unauthorized event has taken place.
This section outlines physical security requirements for voting devices both in use and in storage. It does not address the physical characteristics of polling places. It details countermeasures to be implemented by manufacturers in order to ensure the physical integrity of the voting devices.
5.8.1 Unauthorized physical access
Any unauthorized physical access SHALL leave physical evidence that an unauthorized event has taken place.
Applies To: Voting device
Test Reference: Part 3: 5.2 “Functional Testing”
DISCUSSION
Manufacturer may provide for and recommend a combination of procedures and physical measures that allow election officials to differentiate authorized from unauthorized access during all modes of operation such as a system that relies on tamper evidence tape or tags coded with consecutive serial numbers.
This requirement extends [VVSG2005] I.7.3.1 by requiring that any tampering with a device leave physical evidence. [VVSG2005] I.7.3.1 states that any tampering should be detectable using manufacturer-specified procedures and measures.
Source: I.7.3.1-2
Voting devices SHALL produce an audible and visual alarm if access to a restricted voting device component is gained during the Activated state.
Applies To: Voting device
Test Reference: Part 3: 5.2 “Functional Testing”
5.8.2 Physical port and access least functionality
The voting device SHALL only have physical ports and access points that are essential to voting operations and to voting device testing and auditing.
Applies To: Voting device
Test Reference: Part 3: 4.3 “Verification of Design Requirements”
DISCUSSION
Examples of essential voting operations include voting machine upgrades and maintenance. Examples of physical ports are USB ports, floppy drives and network connections. Examples of access points are doors, panels and vents.
Source: [NIST05]
5.8.3 Voting device boundary protection
If a physical connection between voting device components is broken during Activated or Suspended State, the affected voting machine port SHALL be automatically disabled.
The voting device SHALL produce an audible and visual alarm if a connected component is disconnected during the Activated state.
An event log entry that identifies the name of the affected device SHALL be generated if a voting device component is disconnected during the Activated state.
Ports disabled during Activated or Suspended State SHALL only be re-enabled by authorized administrators.
5.8.4 Information flow
Voting devices SHALL be designed with the capability to restrict physical access to voting machine ports that accommodate removable media, with the exception of ports used to activate a voting session.
Applies To: Voting device
Test Reference: Part 3: 4.3 “Verification of Design Requirements”
DISCUSSION
Floppy, CD or DVD drives and memory cards might be essential to voting operations during Pre-voting and Post-voting phases of the voting cycle such as machine upgrade, maintenance and testing. Therefore, they should be accessible only to authorized personnel. They should not be accessible to voters during Activated and Suspended phases of the voting cycle. It is paramount that the floppy, CD and DVD drives are not accessed without detection. The Manufacturer may provide for and recommend a combination of procedures and physical measures that allow election officials to differentiate authorized from unauthorized access during all modes of operation, such as a system that relies on tamper resistant tape or tags coded with consecutive serial numbers.
Source: [NIST05]
Voting devices SHALL be designed to give a physical indication of tampering or unauthorized access to ports and all other access points, if used as described in the manufacturer's documentation.
Applies To: Voting device
Test Reference: Part 3: 4.3 “Verification of Design Requirements”
DISCUSSION
Manufacturer may provide for and recommend a combination of procedures and physical measures that allow election officials to monitor and control access points such as a system that relies on tamper resistant tape of tags coded with consecutive serial numbers.
This requirement extends [VVSG2005] I.7.3.1 by requiring that tampering with device ports or access points leave physical evidence. [VVSG2005] I.7.3.1 states that any tampering should be detectable using manufacturer-specified procedures and measures.
Source: [NIST05], I.7.3.1-2
Voting machines SHALL be designed such that physical ports can be manually disabled by an authorized administrator.
5.8.5 Door cover and panel security
Access points such as covers and panels SHALL be secured by locks or tamper evidence or tamper resistance countermeasures SHALL be implemented so that system owners can monitor access to voting device components through these points.
Applies To: Voting device
Test Reference: Part 3: 4.3 “Verification of Design Requirements”
5.8.6 Secure ballot box
Ballot boxes SHALL be designed such that any unauthorized physical access results in physical evidence that an unauthorized event has taken place.
Applies To: Voting device
Test Reference: Part 3: 5.2 “Functional Testing”, 4.3 “Verification of Design Requirements”
DISCUSSION
The goal here is to ensure that poll workers or observers would easily notice if someone has tampered with the ballot box. This requirement can be achieved through locks or seals as a part of tamper evidence and tamper resistance countermeasures described by the use procedures and supplied by the manufacturer.
5.8.7 Secure physical lock and key
Voting devices SHALL only make use of locks installed for security purposes that have been evaluated to the listing requirements of UL 437 for door locks and locking cylinders or higher.
Applies To: Voting device
Test Reference: Part 3: 5.2 “Functional Testing”
DISCUSSION
See [UL03] for UL listing requirements.
Voting devices SHALL be designed with countermeasures that give a physical indication that unauthorized attempts have been made to access locks installed for security purposes.
Applies To: Voting device
Test Reference: Part 3: 5.2 “Functional Testing”
Manufacturers SHALL provide locking systems for securing voting devices that can make use of keys that are unique to each owner.
Applies To: Voting device
Test Reference: Part 3: Chapter 4: “Documentation and Design Reviews (Inspections)”
DISCUSSION
Voting device owners are the individuals accountable for purchasing, maintaining and/or operating the voting devices. They may work at the State level or at a local level. Election officials may want keying schemes that are more or less restrictive in accordance with their election management practices. The requirement does not mandate a unique key for each piece of voting equipment, but requires manufacturers to be able to provide unique keys for the voting equipment per the requests of election officials. System owners must establish procedures for issues such as key reproduction, use and storage.
5.8.8 Physical encasing lock
Locks installed for purposes other than security SHALL NOT, if bypassed, compromise the security of a voting device.
Applies To: Voting device
Test Reference: Part 3: 5.2 “Functional Testing”
DISCUSSION
Locks on voting devices may be used to secure access points such as doors and panels or they may be used simply to fasten a segment of the voting device’s encasement. In the former case, testing labs must verify that the lock does indeed provide a measure of security. In the latter case, the testing lab must verify that bypassing the lock does not put the security of the system in jeopardy.
5.8.9 Power supply
Any physical security countermeasures that require power supplies SHALL have a back up power supply
A physical security countermeasure that switches from its primary power supply to its back-up power supply SHALL give an audible and visual alarm.
Applies To: Voting device
Test Reference: Part 3: 5.2 “Functional Testing”