United States Election Assistance Comittee

Register to Vote!

Use the National Mail Voter Registration Form to register to vote, update your registration information with a new name or address, or register with a political party.

Note: If you wish to vote absentee and are a uniformed service member or family member or a citizen living outside the U.S., contact the Federal Voting Assistance Program to register to vote.

EAC Newsletters
and Updates

Sign up to receive information about EAC activities including public meetings, webcasts, reports and grants.

Give Us Your Feedback

Share your feedback on EAC policy proposalsElection Resource Library materials, and OpenEAC activities. Give feedback on general issues, including the Web site, through our Contact Us page.

Military and Overseas Voters

EAC has several projects under way to assist states in serving military and overseas citizens who register and vote absentee under the Uniformed and Overseas Citizens Absentee Voting Act. Learn more

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.

7 Comments

Comment by George Mietus (General Public)

I'd actually feel more confident in electronic voting if a closed system (local network) be used without any access to the general internet. No wifi at all and absolutely no Cat5 run to any system outside of the private loop. At the end of the day, a file dump could be collected from each machine and then sent via encrypted email back to home base from a seperate laptop. This would definitely reduce risk of potential vote tampering. A good hacker can disguise their tracks no matter how many logging programs are in place. This is why I feel a high profile system connected to an open network can NEVER be safe no matter how many firewalls and software are in place. I would also like to see an evolution in the user interaction. Potentially a direct ID or driver's license scan or a non-RFID chip be added to licenses to secure that authenticity of the vote. Even perhaps a direct finger print registration. Although, this might raise privacy concerns. To ensure the purity of the system, I think this would create the hardest obstacles for a potential tamperer to overcome. ...although there is NO electronic system that is 100% secure.

Comment by ted selker (Academic)

"Such as touch screens, batteries" should be changed to: "Such as input devices, power sources"

Comment by Mike Ahmadi (Voter)

This list of requirments should start with a high level threat model as the FIRST requirment. Diving into the technology without doing a threat model first is the equivalent of operating without a diagnosis.

Comment by Harry VanSickle (State Election Official)

Overall, we are satisfied with the security requirements outlined in Chapter 5. Specifically, the cryptography expanded logging requirements and augmented physical security requirements are a positive change from previous iterations of the standards.

Comment by David Reardon (Academic)

The most proper and secure means of preventing tampering with program code is to segregate program steps (which should be in non-reproammable memory) from lookup tables (in reprogrammable memory). In other words, regulations should be developed to REQUIRE of all electronic equipment that the units' functional response to all inputs (program steps) must be in true read-only-memory or unalterably embedded, preferably in "potting" (a rubberized sealing that inhibits tampering and clearly leaves evidence of any attmpted tampering) or some other material, so as to precludes physical access to the program memory. Obviously, reprogramming the lookup tables should be possible under secure conditions. A key advantage of this system is that any error in the lookup table would be easily spotted simply by instructing the unit to print out a complete copy of the lookup table and the fixed codes associated with each voting option. Moreover, any error in the lookup table would consistent across all machines in which the lookup table was used. In this recommended approach, all preparation for each election would be limited to inputting a linked set of lookup tables (including precinct, ballot type, voting options, instructions in multiple languages etc). The fixed programming would then display and record votes in EXACTLY the same fashion from election to election. Only the lookup table would be subject to alteration. Additionally, while the unit could dump it's progam for verification purposes, it simply could not be reprogrammed. The design of such a system is not overly complex and it is far more secure than the electronic voting equipment that is currently on the market which values the ability of "upgrading the software" which necessarily includes then the possibility of corrupting the software.

Comment by Cem Kaner (Academic)

VVSG does not explicitly consider equipment to be used with mail-in ballots. A system that works adequately for in-person voting might be subject to very different use patterns, and might in many ways be less secure, when used to record mail-in ballots. .......... The particular issue that I have been asked to raise on this (via a poll of the IEEE SCC38 Voting Standards committee) considers automated signature verification, and the particular recommendation I have been asked to make to you is the addition of this restriction: "The use of totally-automated signature verification is banned for validation of mail ballots." .......... (Affiliation Note: IEEE representative to TGDC)

Comment by E Smith/P Terwilliger (Manufacturer)

5.1.1-B. "NIST approved" is not defined; it appears to conflict with 5.1.1-A's requirement of FIPS 140-2 validation. 5.1.1-B. The last paragraph of the discussion is hard to interpret. First, all programmed devices must meet a certain standard, but then an undefined "incidental" use is OK? 5.1.2. "Permanently" is undefined. A soldered-in module is hardly permanent to one with a soldering iron. 5.1.2. "Signature module" is not in Appendix A. 5.1.2-A. The last sentence refers to "Part 1:7.7.1 "integrity" above". Wile the referenced section is indeed entitled "integrity", it (a) is not "above" and (b) does not appear relevant. 5.1.2-B.1. "Permanently" is undefined. A soldered-in module is hardly permanent to one with a soldering iron. 5.1.2-B.2. This requirement may conflict with 5.1.1-A, as different FIPS levels are specified. 5.1.3. Election Signature Key is not in Appendix A. 5.1.3.1. Device Signature Key is not in Appendix A. 5.1.3.1. Device Public Key Certificate is not in Appendix A. 5.1.3.1-B. X.509 is not defined. 5.1.3-B. Device Certificate is not defined. 5.1.3-C. "Permanently" is undefined. 5.1.3-D. "Permanently" is undefined. "Placard" is undefined - how does it differ from "label" or "data plate"? "external frame" is undefined. 5.1.3-F. These requirements on the SM force it to understand the context of the data being processed, as otherwise it cannot block uses other than the 3 permitted ones. Note also that in 5.1.4, this requirement is negated by the sentence "The SM is not aware of the contest of its use...." 5.1.4-C. "maintain" is not defined. 5.2.1.1-A. Requirement states "SHALL be able to". How does this differ from 5.2.1.1-B's "SHALL be capable of"? 5.2.1.1-B.1. It is impossible to record "identifying information" of an individual. All that can be recorded are the login/authentication information. There is no way to determine if these are shared between individuals. 5.2.1.2-A. To match other requirements, suggest this be changed to "SHALL be capable of". 5.2.1.2-B.1. It is impossible to record "identifying information" of an individual. All that can be recorded are the login/authentication information. There is no way to determine if these are shared between individuals. 5.2.2-A. This makes no sense. To violate this would mean that the voting device software could not use its own data. The section numbers on Page 124 are incorrect. 5.2.1.2-B should be 5.2.2-B. 5.2.1.2-B.1 should be 5.2.2-B.1. 5.2.3. By applying the requirements in this section to "voting device", the EMS is included. The requirement to not allow software to perform the various indications likely rules out any use of COTS hardware (workstations, servers, UPS, etc.). 5.2.3-A. What is the purpose of not allowing software for this function? 5.2.3-B. What is the purpose of not allowing software for this function? 5.2.3-C. Should this also be "without the use of software"? 5.2.3-C. "communications capability" is undefined. 5.2.3-E. Should this also be "without the use of software"? If not, please explain and contrast especially with 5.2.3-A. 5.2.3-F. There is no actual requirement here. 5.2.3-G. Typo: "SHALL be able adjust". Suggest this requirement is better written as "The voting device SHALL provide a calibration function for each component that requires calibration. This function SHALL be accessible only to Election Judges and Administrators. Page 126 has 2 misnumbered sections. 5.2.3-H. "Device properties inspection" is not defined or explained. 5.2.3-H.1. It is impossible to record "identifying information" of an individual. All that can be recorded are the login/authentication information. There is no way to determine if these are shared between individuals. 5.3. Thise entire section appears based on an assupmtion of a PC-like architecture, with software installation packages & tools. It does not appear that any leeway is provided for a simpler embedded system architecture, where there may not be an operating system, and the "software" resides on EPROM chips that must be physically removed and replaced to "install" software. 5.3-A. Why is this requirement limited to vote capture devices? 5.3-B. "Authenticated administrator" is undefined and untestable. 5.3-B.1. 1) Since the EMS is considered voting equipment, this is a circular requirement. 2) This requirement assumes a connection between the EMS and the voting equipment, otherwise there is no way for the EMS to "allow" software to be installed on physically separate equipment. 5.3-C. Untestable. There is no way for the various programmed devices in a voting system to know whether the installation is being done by someone authenticated by the EMS. The section title needs to be revisited. 5.3-C.1. There is no way for the EMS to "allow" operations on physically separate devices. 5.3-C.1. The section title indicates it is about installing software on the EMS, yet the body talks about voting equipment. 5.3-C.1. "uniquely authenticate" is untestable; it is a jurisdiction issue. 5.3-E. How is "placing the software on programmed devices" different from installing it? 5.3-E.1. Is it acceptable to not have an installation program? 5.3-H. "voting device configuration files" is not defined. How is this different from "election specific software & data files" (5.3-I)? 5.3-H.1. "uniquely authenticate" is untestable; it is a jurisdiction issue. 5.3-I. Typo. "allow authenticated only". 5.3-I.1. "uniquely authenticate" is untestable; it is a jurisdiction issue. 5.2.1.2-J. This requirement places a significant lower bound on the capability of peripheral devices that may have a small amount of software (such as a VVPAT microcontroller). Suggest changing it to vote capture devices. 5.4.1. The introductory text uses "voting system", yet the requirements change to "voting device". Why the difference? 5.4.1-A. "prevent" is untestable. 5.4.1-A.1. The requirement, discussion and accompanying table indicate that voters will be required to log in. 5.4.1-A.2. Again mixing the identification of individuals with authenticating log in accounts/details. Only untestbale procedural safeguards prevent sharing of login credentials. 5.4.1 subsections. Requirements switch between "vote capture device" and "voting device". 5.4.1-H. "prevent" is untestable. 5.4.2-B. Earlier sections, in particular 5.4.1-A.1, require role-based access, so there is no "if" available for this requirement. 5.4.2-D. It is impractical to have the EMS identify all pollworkers and election judges. 5.4.3. Applying the requirements in the subsections to "voting device" causes concern; it will make polling place devices substantially more costly and complex. 5.4.3-B. "multi-factor authentication" is not defined. 5.4.3-B and 5.4.3-C say "multi-factor authentication", while table 5-4 says two-factor authentication". Which is it? 5.4.3-D. "protected" is untestable. 5.4.3-I. The discussion is incorrect; the requirement as stated does NOT require strong passwords, it only provides the capability of such. 5.4.3-I.1's discussion concurs. 5.4.4-A. "ensure" is untestable. 5.4.4-B. "enforce" is untestable. 5.4.4-C. "provide" is untestable. There is no way for the voting device to verify that there are actually two people. How is "dual person control" different from "two-factor authentication"? 5.4.4-D. "explicitly" is untestable. 5.5.1-A. "Electronic device" is defined as a device that uses electricity. Therefore a booth for marking a paper ballot that includes a light is an "electronic device" and hence subject to the requirements here. As a minimum, this must be changed to "programmed device" to make sense. 5.5.1-A. By applying this to the EMS, COTS servers & workstations will not be permitted. 5.5.1-A. "tamper resistant" is untestable. 5.5.1-B. Discussion states that the requirement mandates cryptographic software reference information. It does not, it only requires a hardware module, not how that module shall function. 5.5.2. "precinct" seems out of place here. 5.5.2-A. "Electronic devices" should be "programmed devices" or "voting devices". 5.5.2-A. The discussion directs the reader to Chapter 14, which does not exist. 5.5.3-A. It is inadvisable to not provide a method for retrieving vote data from a voting device in the event of a removable memory device failure. Such a method is indistinguishabe from a "backup" in the context of this prohibition. Also, the discussion appears to modify the prohibition into "shall be minimized". 5.5.3-B. What does it mean for an EMS to be "activated"? What is the purpose of making backup functionality option for the EMS? This appears to go against standard computing practice. 5.5.4 subsections use "common known" which is undefined and untestable. 5.6.1. All subsections use "electronic devices" instead of "programmed device" or "voting equipment". 5.6.1-A. Is visible light considered a "wireless technology". Is sound considered a "wireless technology"? Neither uses wires... 5.6.1-B. How does this prohibition interact with recent "broadband over power line" technology? 5.6.1-B.1. Is connected to a common power strip considered "connected to"? How about the common practice of polling place equipment using daisy-chained power connections? 5.6.2. All subsections use "electronic devices" instead of "programmed device" or "voting equipment". 5.6.3-C. The referenced "requirement 1.2.3-D" does not exist. 5.6.3. All subsections use "electronic devices" instead of "programmed device" or "voting equipment". 5.7.1-D.4. Why is the time zone required? For any jurisdiction, local time would be assumed. 5.7.1-D.5. The discussion violates the requirements listed in section 5.4. 5.7.1-E.1. "ensure that" is not testable. 5.7.1-E.1. To apply this logging to "programmed device" places a significant burden on peripheral devices that use embedded microcontrollers. Suggest that the "applies to" field in the chart be revisited and restricted to "vote capture device" and higher levels (EMS). Also, much of the text of 5.7.2 refers to "voting device", not "programmed device". 5.7.2-A. "secure" in untestable. 5.7.2-D. "several" is undefined and untestable. 5.7.2-F. The discussion violates the requirements listed in section 5.4. 5.7.2-H. The discussion violates the requirements listed in section 5.4. 5.7.2-I. The discussion violates the requirements listed in section 5.4. 5.7.2-I. The read-only access requirement conflicts with 5.7.2-H, where the administrator is allowed to delete logs. 5.7.2-J. No idea what this is asking for. 5.7.2-K. "export" is not defined in this context. To where? 5.7.2-K. It is inappropriate to bury a requirement to export/sign all election results as a dependent clause in a requirement buried deep inside a section devoted entirely to event logs. 5.7.2-L. Conflicts with 5.7.2-C. "analyze" and "search" are untestable. 5.7.2-O. How does this pre-defined capacity get defined? How does it differ from the "maximum size" of 5.7.2-D? 5.7.3-A. "protect" is untestable. 5.7.3-B. "protect" is untestable. 5.8.1-A. "event" should be "access". 5.8.1-A. The requirement does not indicate what is being accessed. The voting device? 5.8.1-B. What is a "restricted voting device"? "Audible" is untestable. What SPL? 5.8.2-A. This is redundant. OTher sections already restrict port access. 5.8.3-A. This would be better if aligned with 5.8.1-B, where auddible and visual alarms are generated. 5.8.3-B. This would be better if aligned with 5.8.1-B, where auddible and visual alarms are generated. 5.8.3-D. This is impractical; it would require an adminstrator at each polling place. 5.8.4-A. This is redundant. Other sections already restrict port access. 5.8.4-B. Why the caveat of "if used as described..."? No other section anywhere includes this. 5.8.4-C. For what purpose? The VVSG already restricts ports to only those that are required. To allow disabling any such required port would render the system inoperable. 5.8.5-A. The requirement does not parse. 5.8.6-A. "Ballot box" is not defined. 5.8.7-B. Since an unauthorized access to a lock can be insertion of the wrong key, what physical indication would be possible? 5.8.7-C. This is the only requirement that refers to the "owner" of the voting device. In the case of a state or county government office purchasing the equipment, how is the owner determined?

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.

2 Comments

Comment by ted selker (Academic)

"This section establishes general cryptography requirements" Unless we define cryptography in plain English, should be changed to: "This section establishes general security requirements"

Comment by Richard Carback (Academic)

The IVVR prevents protecting the confidentiality of voting records with cryptography. It might be useful for a separate record, but not the voting records. This statement could be removed.

5.1.1 General cryptographic implementation

5.1.1-A Cryptographic module validation

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

3 Comments

Comment by ted selker (Academic)

"Ensures that the cryptographic algorithms" should be changed to: "Ensures that the coding and transmission methods designed to enhance security." "Unofficial results or communicating with electronic an poll book" should be changed to: "with electronic an poll book and after official records have been recovered from the equipment."

Comment by Kevin Wilson (Voting System Test Laboratory)

"Cryptographic module validation" As described in 1:5.6.3-B, a number of COTS and electronic devices might implement cryptographic means to perform mutual authentication. Are all such devices that are not FIPS 140-2 Level 1 certified excluded from use in such circumstances?

Comment by T Caddy (Voting System Test Laboratory)

It should not be allowed to have a non FIPS mode. Non-FIPS modes allow for vulnerabilities in the modules that will degrade trust of integrity, crypto keys and processes. The statement about having a FIPS mode of operation is meaningless because if it did not have a FIPS mode it could not be validated. Add sentence: The cryptographic module used in voting systems shall not have a non-FIPS mode of operation.
5.1.1-B Cryptographic strength

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

3 Comments

Comment by ted selker (Academic)

112 bits is a specific solution. The level of security should be described and the source of the solution should be referenced in the requirement. The expectation of "several decades" should be qualified because we have had to change our prediction of the value of security codes many times.

Comment by T Caddy (Voting System Test Laboratory)

Statement: The specified strength should be sufficient for several decades Comment: Table 4 of 800-57 Part 1 says 112 bits of strength should be ok through 2030 then 128 bits will be required. This is a guide that is not fixed if some new threat appears. This is actually a maximum of two decades. Suggestion: Option 1) Delete sentence. Option 2) Modify sentence to indicate until 2030.

Comment by T Caddy (General Public)

Requirement: This requirement is not intended to forbid all incidental use of non-approved algorithms by OS softwrae or standardixed network security protocols. Comment: This is a built in waiver that is not consistent with FIPS 140-2 compliant cryptography. This will allow vendors to build in insecure ptrotocols and processes that are not necessary at this time. There are currently enough approved methods to implement any objective designers neede in the elections arena. Suggestion: Delete paragraph; the statmens allowing a tolerable amout of flexibility are built into the FIPS 140-2 standard.

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.

3 Comments

Comment by T Caddy (General Public)

Stetement: 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. Comment: Awkward sentence. It seems that in two places it sayes NOT detect when it should just be detect. Suggestion: Modify sentence: This makes it difficlut to falsify election records withou creating evidence of the alteration that has a high assurnace of detecting the change.

Comment by T Caddy (General Public)

Statement: The module is "embedded in" (permanently attached to) the voting device to make it difficult to substitute another module Comment: Specific words in this sentence are likely to be miss interpreted by some labs and vendors. EMBEDDED; it may be possible for a module to be embedded into the voting system without being a FIPS 140-2 "embedded" module as it is classifed by the CMVP. PERMENENT: If the key management and signature verification processes are architected correctly, a substitued signature would be detected and flagged. To make the SM permanent would make the device un maintainable which is a big impact. Suggestion:

Comment by T Caddy (General Public)

Statement: A separate hardware Signature Module (SM) protects the private signature keys and the signature process should the election system software be compromised. Comment: Specific Words likely to be mis interpreted: SEPERATE To what degree is it seperated? Is seperate in conflict with Permenant in the next sentence. HARDWARE What is the definition of hardware. Would a chip with firmware be Hardware. In CMVP ROM is considered Hardware, but flash is not will that be the case also here?
5.1.2-A Digital signature generation requirements

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

2 Comments

Comment by T Caddy (General Public)

Statement: This makes it more difficult to create spurious election records. Comment: "Create spurious" term is ambiguous in this context. Suggestion: This makes it more difficult to modify or substitue CVR's.

Comment by T Caddy (General Public)

Statement: The purpose of signing election records is to authenctiate them and prevent their subsequent alteration. Comment: Digital Signatures will not PREVENT subsequent alteration, but they do enable a very high confidence in being able to detect the record was altered. Suggestion: Modify sentence to say Enable the detection of a modified or altered record.
5.1.2-B Signature Module (SM)

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

1 Comment

Comment by Kevin Wilson (Voting System Test Laboratory)

Suppose that a SM module provides its unique id to its enclosing electronic device as the unique id of the device and the enclosing electronic device never caches this information (except perhaps as a security check). Is that circumstance sufficiently "permanent" because even though the SM module itself might be replacable, to do so would create a new electronic id for the enclosing electronic device? (i.e this is akin to SIM chip in a cell phone, which if replaced renders the cell phone a new identity on the network). Of course, the described replacement would necessarily require replacement of the placard in section 5.1.3-D, effectivly creating a new enclosing electronic device. Soldered or not, the ultimate security of the system depends on how tamper-resistant and counterfeit-resistant the placard is. If the SM module is replaced at any time in the lifetime of the enclosing device with a compromised but functionally equivalent device, then the compromised device and its conspirator(s) can use it to tamper with vote records at any point in the voting cycle where they have access to them.
5.1.2-B.1 Non-replaceable embedded Signature Module (SM)

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

1 Comment

Comment by ted selker (Academic)

Finger nail polish or equivalent should be placed on each physical area such as the mechanical affixment of the security chip to the circuit to demonstrate that the device has not been moved since the circuit board first was assembled.
5.1.2-B.2 Signature module validation level

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.

1 Comment

Comment by Scott Shorter (Manufacturer)

There should be section on key management for symmetric keys as well, requiring generation by a FIPS approved module or establishment by CMVP approved establishment schemes. Password derived keys should not be accepted for encryption.

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.

5.1.3.1-A DSK Generation

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

5.1.3.1-B Device Certificate generation

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

5.1.3.1-C Device Certificate storage

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

5.1.3.1-D Device identification placard

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

5.1.3.1-E Device Signature Key protection

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

5.1.3.1-F Use of Device Signature Key

Signature Modules SHALL implement and permit only three uses of the DSK:

  1. to sign Election Public Key Certificates;
  2. to sign Election Closeout Records; and
  3. 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).

1 Comment

Comment by ted selker (Academic)

"may be held on a single day" should be changed to: may be held in a single voting period.
5.1.4-A Election Signature Key (ESK) generation

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

1 Comment

Comment by Kevin Wilson (Voting System Test Laboratory)

"Signature Modules SHALL internally generate election signature key-pairs (ESK) using an integral nondeterministic random bit generator." Is this a testable requirement or is vendor affirmation sufficient to meet the requirement?
5.1.4-B Election Public Key Certificate

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

5.1.4-C Election counter

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

5.1.4-D Election Signature Key use counter

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

1 Comment

Comment by Carl Hage (Academic)

The ESK use count (number of signatures created) should be included within each signature where order-dependence is not required, e.g. on summary record signatures. (The application could pass a parameter to indicate a signature with/without a serial/sequence number.) If no requirement for hiding the order exists, e.g. paper audit is collected on rolls, then the use-count/serial number should be included in all signatures. The signature module should also include a cumulative hash/checksum of the signed data, either order independent (e.g. XOR) or order dependent (SHA), depending on the privacy requirements. Audits of electronic and paper records must be able to detect insertion or deletion of records, and identify where this occurs. Note that equipment failures could be an inintentional accidential source of insertion and deletion, so preservation of cumulative digital signature authentication on the independent paper trail is highly desirable.
5.1.4-E Election Key Closeout

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

5.1.4-F Election Key Closeout record

The Election Key Closeout record SHALL be signed by the DSK and contain at least:

  1. The election signature public key (or a message digest of that key);
  2. The ESK number; and
  3. 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].

1 Comment

Comment by ted selker (Academic)

"Such as touch screens, batteries" should be changed to: "Such as input devices, power sources …"

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.

2 Comments

Comment by ted selker (Academic)

can use directory paths and filenames… Should be changed to: can use identifiers such as directory paths and filenames…

Comment by Carl Hage (General Public)

The software verification system must be configurable to setup a specific list of signatures required to authenticate the software. For example, voting device operating system and application software should require a summary signature from the local election offical, the secretary of state, the election system vendor, plus an independent software validation lab. This insures that state laws insuring only certified software is used, and all changes are publically logged. The software verification process should be easily visible with public access to the verification and change logs. Authentication logs and software version signatures should be electronically posted for public access with an independent digital notary timestamp. To facilitate independent verification, industry standard signature formats must be used, and the data formats must be published and freely usable without license restrictions.

5.2.1.1 Software identification verification

5.2.1.1-A Voting device software identification

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)

5.2.1.1-B Voting device, software identification verification log

Voting devices SHALL be capable of a software identification verification inspection that records, minimally, the following information to the device’s event log:

  1. Time and date of the inspection;
  2. Information that uniquely identifies the software (such as software name, version, build number, etc.);
  3. Information that identifies the location (such as full path name or memory address); and
  4. 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

5.2.1.1-B.1 EMS, software identification verification log

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

5.2.1.2-A 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)

1 Comment

Comment by Craig Burton, CTO, EveryoneCounts.com (Manufacturer)

This seems to allow the voting device to host a trojaned MD5SUM application which will mask changes. A third party device with a known good MD5SUM checker is needed to interrogate the voting machine. Also, the voting machine needs some sort of provably full storage mechanism so there is no room any other software to boot or run in addition to the National Software Reference Library (NSRL) MD5. Ideally, the third party device can query the voting machine entire mass storage device or memory at random and receive entirely deterministic values it can compare to a reference. Any empty space on the device is filled with a file of random numbers which also accompanies the NSRL repository. This way we can be sure that while the repository MD5s are correct there is no _additional_ software on the mass storage device, hidden or not. Presumably the TPM has to be reset for new software installs and this would be the time to set it with MD5s for trojan software.
5.2.1.2-B Voting device, software integrity verification log

Voting devices SHALL be capable of performing a software integrity verification inspection that records, minimally, the following information to the device’s event log:

  1. Time and date of the inspection;
  2. Information that uniquely identifies the software (such as software name, version, build number, etc.);
  3. Information that identifies the software integrity verification technique used;
    Results of the software verification,
  4. Including the cryptographic software reference information used for the verification; and
  5. 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

1 Comment

Comment by ted selker (Academic)

"These other properties that can be inspected" should be changed to "These other properties that SHALL be inspected."
5.2.1.2-B.1 EMS, software integrity verification log

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.

5.2.2-A Election information value determination

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)

5.2.2-B Voting device, election information value inspection log

Voting devices SHALL be capable of performing an election information inspection that records, minimally, the following information to the device’s event log:

  1. Time and date of the inspection;
  2. Information that uniquely identifies the storage location of the information inspected;
  3. The value of each piece of election information; and
  4. 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

5.2.2-B.1 EMS, election information value inspection log

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.

2 Comments

Comment by Kevin Wilson (Voting System Test Laboratory)

What does "without the use of software mean" Is an analog circuit expected? Or does this refer to software operating outside of the device? Isn't it implicit that all voting devices contain software to drive their functionality? If this requirement does refer to an analog circuit, then what is the test for an analog circuit? Or does this mean that the functionality must be observable at all times during normal operation, as implied by 5.2.3-B which, in all likelihood, is driven in most systems by a digital ("software") circuit?

Comment by Premier Election Solutions (Manufacturer)

More accurate estimations of battery charge are performed using software that analyzes previous battery charge and discharge curves. To limit the system to only using hardware established thresholds would diminish the accuracy of the reported charge over the operating life of the battery. Proposed Change: Change the requirement to read as follows: 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).
5.2.3-A Backup power source charge indicator

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

1 Comment

Comment by Premier Election Solutions (Manufacturer)

It seems that this requirement is mandating the use of a light/LED or other visual indicator to indicate a cable is connected and operational. However, it is unclear as to whether this requirement extends to items like headphones and other ATI devices. Please clarify whether the connection of items like headphones and other ATI devices are included under this requirement.
5.2.3-B Cabling connectivity indicator

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

1 Comment

Comment by ted selker (Academic)

"SHALL indicate the remaining amount of voting device consumables (i.e. ink, paper, etc.) in quarterly" Should be changed to: "SHALL indicate the remaining amount of voting device consumables (i.e. ink, paper, etc.) in number of voters."
5.2.3-C Communications operational status indicator

The voting device SHALL indicate the operational status of the communications capability of the voting device.

Applies To: Voting device

Test Reference: Part 3: 5.2 "Functional Testing"

Source: New requirement

5.2.3-D Communications on/off indicator

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

5.2.3-E Consumables remaining indicator

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.

Applies To: Voting device

Test Reference: Part 3: 5.2 "Functional Testing"

Source: New requirement

5.2.3-F Calibration determination of voting device components

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

5.2.3-G Calibration of voting device components adjustment

The voting device SHALL be able adjust the calibration of voting device components that require calibration.

Applies To: Voting device

Test Reference: Part 3: 5.2 "Functional Testing"

Source: New requirement

1 Comment

Comment by Gail Audette (Voting System Test Laboratory)

How can a device calibrate itself?
5.2.3-H Voting device, property inspection log

Voting devices SHALL be capable of performing a device properties inspection that records, minimally, the following information to the device’s event log:

  1. Time and date of the inspection;
  2. A description of the inspections performed;
  3. Results of each inspection; and
  4. 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

5.2.3-H.1 EMS, property inspection log

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.

5.3-A Software installation state restriction

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

1 Comment

Comment by Carl hage (General Public)

The description and limitations on software installation in the VVSG is inadequate. Any installation must not violate the principle that _all_ software be authenticated, and only authenticated software and data can be installed. Software and critical data files should be stored on media with hardware write protect, where a physical key is required, and media is contained within a physically secured enclosure. A physical key and hardware write protect could be used in conjunction with a digital security device, e.g. a USB digital signature token (or set of tokens) used by installation software to enable alteration. Hardware write protect should also be used to facilitate inspection. An "inspection" mode should be designed into the hardware, where all media is placed in a hardware protect mode, and digital signatures are disabled up to the next hardware reset. Once in the read-only inspection mode, the bios could boot off a CD-ROM or portable media device to allow independent software to run on the machine to validate the contents of the storage media. Physical security of the software must include firmware and protection against tampering at the chip level. Many chips contain programmable memory changable via electrical pins on the chip, e.g. a JTAG port. These ports must be disabled or otherwise protected including tamper evidence.
5.3-B Authentication to install software

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

1 Comment

Comment by ted selker (Academic)

Administrators should only be able to install software in the presence of a second party (a double lock on access), and a record of their access should be created.
5.3-B.1 Authentication to install software on EMS

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

5.3-C Authentication to install software election-specific software

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

2 Comments

Comment by ted selker (Academic)

"The program devices shall only allow authenticated central election officials to install electronic software and data files on voting equipment", should continue " using administrative double lock to insure that no single agent makes the change by themselves without record."

Comment by Premier Election Solutions (Manufacturer)

It seems that this requirement is meant to allow only authenticated application software to be loaded onto the voting equipment by authorized central election officials, but it is not clearly written. Please clarify the intent of this requirement or change this requirement to read as follows: Programmed devices SHALL only allow authorized central election officials to install authenticated application software on voting equipment.
5.3-C.1 Authentication to install software election-specific software on EMS

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

1 Comment

Comment by Premier Election Solutions (Manufacturer)

This requirement is a duplicate of the parent requirement 5.3-C. Proposed Change: Remove this requirement.
5.3-D Software installation procedures usage documentation

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

5.3-E Software digital signature verification

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

5.3-E.1 Software installation programs digital signature verification

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

5.3-E.2 Software digital signature verification record

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

1 Comment

Comment by Gail Audette (Voting System Test Laboratory)

"Who" - is this the lab, the individual, or what? Please define.
5.3-F Software installation error alert media

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

1 Comment

Comment by ted selker (Academic)

"Software installation programs shall provide an externally visible error..." should be changed to "Software installation programs shall provide an externally auditable error message."
5.3-G Programmed device, software installation logging

Programmed devices SHALL be able to log, minimally, the following information associated with each piece of software installed to the device’s event log:

  1. The date and time of the installation;
  2. The software’s filename and version;
  3. The location where the software is installed (such as directory path or memory addresses);
  4. If the software was installed successfully or not; and
  5. 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

5.3-G.1 EMS, vote equipment property inspection log

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

5.3-H Authentication to access configuration file

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

1 Comment

Comment by ted selker (Academic)

"Using administrative...", should read "Using administrative double lock to insurance agent independence."
5.3-H.1 Authentication to access configuration file on EMS

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

5.3-I Authentication to access election–specific configuration file

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

1 Comment

Comment by ted selker (Academic)

"including administrative double lock to insure single agent independence and auditability." should be added. All access to the device should require passing a double llock and be auditable after the fact.
5.3-I.1 Authentication to access election–specific configuration file on EMS

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

2 Comments

Comment by ted selker (Academic)

5.3-i.1 should add, including administrative double lock to insure single agent independence and auditability.

Comment by Gail Audette (Voting System Test Laboratory)

2 sections immediately following this one are labeled 5.2.1.2-J and 5.2.1.2--J.1 which should probably be 5.3-J and 5.3-J.1
5.3-J Programmed device, configuration file access logging

Programmed devices SHALL be able to log, minimally, the following information associated with configuration file accesses:

  1. The date and time of the access;
  2. The configuration file’s filename;
  3. An indication of the configuration file was modified; and
  4. 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

5.3-J.1 EMS, configuration file access logging

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.

5.4.1-A Access control mechanisms

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:

  1. Accountability of actions by identifying and authenticating users;
  2. Confidentiality of casting and storing of votes;
  3. Integrity of event logs, electronic records, and vote reporting; and
  4. 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

5.4.1-A.1 Voting device access control

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.

5.4.1-A.2 EMS access control

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

5.4.1-B Access control for software and files

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

5.4.1-C Access control voting states

The vote-capture device’s access control mechanisms SHALL distinguish at least the following voting states from Part 1: Table 5-2:

  1. Pre-voting;
  2. Activated;
  3. Suspended; and
  4. 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.

5.4.1-D Access control state policies

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

1 Comment

Comment by ted selker (Academic)

Add to this, "using administrative double lock to insure single agent independence and make all access auditable."
5.4.1-E Minimum permissions default

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

5.4.1-F Privilege escalation prevention

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.

Source: [VVSG2005] I.7.2.1 and [VVSG2005] II.6.4.1

5.4.1-G Privileged operations authorization

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.

Source: [VVSG2005] I.7.2.1 and [VVSG2005] II.6.4.1

1 Comment

Comment by ted selker (Academic)

"The voting device shall insure that an administrator authorized each privileged operation..." should be changed to "The voting device shall insure that administrators using administrative double lock to insure single agent independence and auditability authorize each privileged operation."
5.4.1-H Software and firmware modification prevention

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.

Source: [VVSG2005] I.7.2.1 and [VVSG2005] II.6.4.1

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.

5.4.2-A Access control identification

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

5.4.2-B Role-based access control standard

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

5.4.2-C Access control roles identification

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

5.4.2-D Group member identification

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

5.4.2-E Access control configuration

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.

5.4.3-A Minimum authentication mechanism

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

5.4.3-B Multiple authentication mechanism

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

1 Comment

Comment by Scott Shorter (Manufacturer)

Table 5-4 lists 'minimum authentication method' but doesn't indicate the relative ranking of the methods offered. Also, is there a minimum authentication method for voting tokens?
5.4.3-C Administrator group or role multi-factor authentication

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

1 Comment

Comment by ted selker (Academic)

This rule should also ensure that secret or private data shall be protected from being viewed by one person without supervision to ensure confidentiality.
5.4.3-D Secure storage of authentication data

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

1 Comment

Comment by ted selker (Academic)

5.4.3, "the voting device shall allow privileged groups or roles to be disabled and allow new individual privileged groups and roles to be created." Add to that, "with administrative double lock, ensuring that no one person makes these changes without eliminating single agent independence."
5.4.3-E Setting and changing of passwords, pass phases, and keys

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

5.4.3-F Creation and disabling of privileged groups or roles

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

1 Comment

Comment by ted selker (Academic)

This should add, " with administrative double lock requiring more than one person to be present to avoid single agent independence."
5.4.3-G Account lock out

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

1 Comment

Comment by Kevin Wilson (Voting System Test Laboratory)

No minimum password strength? In light of all the extra security being required for Fops 140-2 level 3 etc. and then its thrown away by the administrator who chooses a password strength of 0?
5.4.3-H Account lock out configuration

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

5.4.3-I User name and password management

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

1 Comment

Comment by ted selker (Academic)

This section should be changed to require that the voting device shall also create an auditable record of all changes.
5.4.3-I.1 Password strength configuration

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

5.4.3-I.2 Password history configuration

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

5.4.3-I.3 Account information for password restriction

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

5.4.3-I.4 Automated password expiration

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

1 Comment

Comment by Kevin Wilson (Voting System Test Laboratory)

At what point in the product life-cycle is this requirement expected to take hold? After all during initialization of a system an identity and authentication must be created and clearly a second identity does not exist yet to allow such an activity.

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.

5.4.4-A Account access to election data authorization

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

5.4.4-B Separation of duties

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

5.4.4-C Dual person control

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

5.4.4-D Explicit authorization

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

5.4.4-E Explicit deny

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

5.4.4-F Authorization limits

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.

5.5.1-A Protecting the integrity of the boot process

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

5.5.1-B Integrity verification of binaries before execution or memory load

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

2 Comments

Comment by Carl Hage (General Public)

It is important to verify critical configuration and data files as well as software modules. Verifying integrity should apply to these files as well. All software and non-modified data files should be stored in read-only storage with hardware write protect, and a physical key required to enable writing. Any operating system or COTS software that cannot run within read-only media must be disqualified. Any operating system or COTS software that mixes configuration and data that must be protected (read-only) with data that can be altered must be disqualified. For example, storing all system configuration and log data in a "registry database" disqualifies an operating system because run time writable data is mixed with configuration data that requires hardware write protection.

Comment by Craig Burton, CTO, EveryoneCounts.com (Manufacturer)

It is not clear how the TPM can prevent the administrator from setting it to record MD5s for installed software unless the TPM is independently networked to the NSRL.
5.5.1-C Sandboxing applications

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.

5.5.2-A Restricting the use of removable media

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

3 Comments

Comment by Carl Hage (General Public)

Any operating system that has the ability (even if disabled in a configuration file) to execute programs automatically when inserting media, e.g. "Autorun", must be disqualified. (Execution of validated software by the voting application when inserting media does not apply.) "Autorun" is such a severe security violation, that the mere presence of such software warrants disqualification of a machine. It is useful to enable booting from removable media if the hardware can be placed in a read-only "inspection" state, where read-only includes disabling of signature creation. Otherwise there is no means to use independent software to inspect and validate the contents of the machine. An inspection mode puts the hardware in a state where software cannot alter the machine in any way, or access private information such as private signature key. This includes operations such as generating signatures. A hardware reset must be used to escape the inspection mode.

Comment by ted selker (Academic)

"Electronic devices shall disable all removable media" should be changed to, "electronic devices shall physically disable all removable media."

Comment by Kevin Wilson (Voting System Test Laboratory)

A "Electronic devices SHALL disable all removable media interfaces that are not needed for each voting system state." This section refers to Chapter 14: Physical Security. No such chapter exists.

5.5.3 Backup and recovery

Backup and recovery requirements describe minimum authorization, auditing, and protective measures, without regard to specific media.

5.5.3-A Restricting backup and restore capabilities

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

2 Comments

Comment by Carl Hage (General Public)

The description should be enhanced to qualify this as "general purpose backup". A non-ems SHOULD have the ability to backup (make a copy) of certain information such as the stored voter records or totals, but as part of the application logic. If fact, it would be desirable to have a requirement that a poll-site device create backups onto removable media that can be held and collected independent of the machine.

Comment by Premier Election Solutions (Manufacturer)

In the requirements for 7.7.5, redundant records are required to be maintained for the purposes of "recoverability. This requirement (5.5.3-A) states that the electronic device shall not be allowed to restore that data. This is an apparent contradiction to require devices to have redundant records yet not allow those devices to recover by restoring those records, unless the recoverability purpose of the redundant records is not meant to be performed through the use of a restore function. Proposed Change: Please do one of the following: 1. Remove this requirement; or 2. Allow electronic devices with redundant records to have the ability to restore from those records; or 3. Clarify the requirements to remove the apparent contradiction.
5.5.3-B Restricting the performance of backups and restores

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

1 Comment

Comment by ted selker (Academic)

"Electronic management systems that provide backup or restore capabilities shall only permit backup and restore operations while not in activated state" should be changed to, "EMS shall produce more than one set of records to demonstrate that they are auditable during use."
5.5.3-C Authenticity and integrity of backup information

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

1 Comment

Comment by Scott Shorter (Manufacturer)

Hashes do not provide authenticity, and should be omitted from the list.
5.5.3-D Verifying backup authenticity and integrity

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.

1 Comment

Comment by Ariel J. Feldman, Harlan Yu, Joseph A. Calandrino (Princeton University) (Academic)

This requires the use of commercial off-the-shelf (COTS) malware detection software, such as a virus scanner, on EMSs. This requirement may do more harm than good. Widely used COTS malware detection software would be unlikely to detect custom malware written specifically to attack one particular voting system-- it is typically designed to detect general-purpose attacks against personal computers. In addition, the COTS software itself might introduce its own vulnerabilities into the system, whether inadvertent or not. The best strategy for thwarting these custom attacks would be to conduct comprehensive open-ended vulnerability testing and adopt a "segregated dual-EMS architecture" (see: J.A. Calandrino, A.J. Feldman, J.A. Halderman, D. Wagner, H. Yu, B. Zeller. Source Code Review of the Diebold Voting System. July 2007. Section 6.10).
5.5.4-A Installing malware detection software

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

2 Comments

Comment by Carl Hage (General Public)

Please read this comment-- this is most important. Section 5.5.4-A creates a huge security problem and it's existence must disqualify a system. Here is why... This requirement is mutually exclusive with the requirement that all software (and certain data) be validated. An EMS must PROHIBIT anti-virus, etc. software, as this software iteself is an inherent security risk. The requirement here is backwards-- off-the-shelf malware detection must only be allowed while the equipment is in a read-only inspection state, where hardware disables any alteration of media, signature creation, etc. Such an inspection state must be entered as a separate (unsafe) boot, and exited only with a hardware reset of the whole machine. Anti-malware software must be made moot by utilizing digitally signed and authenticated data as part of the boot process, and software must be protected against alteration by hardware write protection. Only software certified by all of local and state election officials, the equipment vendor, and independent software certification lab. Anti-malware software inherintly cannot be certified. Anti-malware software can (and SHOULD) be run within a firewall router external to a network connected EMS. Various products are available that scan email messages, web accesses, etc. for malware as well as restrict access over a net connection. However, it may be desirable to limit network access to only a controlled application-level interface (no COTS or uninspected code used), or limit communication to removable media. It would be reasonable to modify section 5.5.4-A to require malware detection in a separately connected hardware device on any net-connected EMS.

Comment by Scott Shorter (Manufacturer)

Is an EMS required to be built on a platform for which off-the-shelf malware detection software is available?
5.5.4-B Malware detection software signature updates

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

5.5.4-C Scanning removable media for malware

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

1 Comment

Comment by Carl Hage (General Public)

Any operating system that is susceptible to malware on removable media (autorun) must be disqualified. An EMS should limit applications to only those necessary to limit the possibility of attacks in data files. An EMS should limit access to removable media data, except via application software to explicitly transfer known data files with content that can be validated. General (online updated) malware scans of removable media should be performed on a system external to the EMS, since malware scanning software cannot generally be authenticated and certified.
5.5.4-D Periodic malware scanning

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

1 Comment

Comment by ted selker (Academic)

" EMSes shall be scanned for common known malware at least every 24 hours during operation." This should be changed to, "EMSes shall be scanned with best-of-breed malware checking each time it is associated with a network or other computer. And if it is continuously on a network, this scan must be continuously run."
5.5.4-E Real-time malware scanning

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

1 Comment

Comment by Carl Hage (General Public)

Real-time malware scanning means the integrity of the whole system cannot be trusted, as the malware scanning software itself alters the operating system and is itself a "root-kit".

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.

5.6.1-A Prohibiting wireless technology

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

5 Comments

Comment by Peter Pearson (General Public)

Please clarify this notion of an infrared channel "shielded to prevent the escape of the signal". Is this an obscure reference to optical fibers? If you're contemplating free-space IR transmissions, would closing the windows of the room constitute sufficient "shielding" to prevent "escape"? Escape from what boundary? I think you have in mind some specific technology, but I can't tell what it is, so opening a hole in the "no wireless" rule for it seems like a vulnerability with no corresponding benefit.

Comment by ted selker (Academic)

The use of wireless technology has been used to insure that electronic devices are not stolen, are seized or otherwise compromised on the way to being counted. The value of having multiple checks on the transportation of the votes is as important and relevant as any other aspect of security. In this way, the wireless could be a useful tool to insuring the security only if the records are retrieved from the electronic device before the wireless technologies are physically installed and used to transmit records.

Comment by Brit Williams (Academic)

Every so ofter a technology emerges that completely alters the way we live. Examples are electricity, the automobile, the telephone; to name a few. Wireless technology is on of these life altering technologies. Every person reading this comment has on their person a wireless device that has completely altered the way they communicate with their business, their family, and their friends. To categorically prohibit the use of this technology in voting systems seems, at least to me, unnecessarily to deny the tremendous advantages of wireless technologh to the advancement of voting systems. A more reasonable approach would be to specify the conditions under which wireless technology can be employed in a voting system.

Comment by David B. Aragon (Voter)

I am a wireless engineer for a major provider of enterprise-class 802.11 (WiFi) equipment, speaking not on behalf of my employer but as an individual professional and IEEE member. I strongly concur with the prohibition of RF wireless in voting equipment for the reasons given by TGDC, and particularly because of the ease of disruption of wireless operation by intentional or unintentional interference which poll workers would be unequipped to diagnose or rectify. ISSUES: T-Coil coupling for assistive hearing devices is a wireless technology, so this requirement apparently conflicts with 3.3.3-C.2. It can also be parsed (however absurdly) to permit RF wireless as long as the signal path is not shielded. The language below would resolve both problems. SOLUTION: Replace I:5.6.1-A as follows: "Electronic devices SHALL NOT be enabled or installed with any wireless technology (e.g., Wi-Fi, wireless broadband, Bluetooth), with the following exceptions: (1) infrared technology where the signal path is shielded to prevent the escape of the signal and saturation jamming of the signal, and (2) T-Coil coupling technology complying with Requirement 3.3.3-C.2."

Comment by Craig Burton, CTO, EveryoneCounts.com (Manufacturer)

This comment applies to 5.6.1-B as well These two assert there can be no form of remote observation or checking of DREs and no strong transport of votes via the Internet. This reduces the opportunities for new technologies, for live access to CRLs, strong NNTP, and so on. Does this also preclude the use of a LAN or VPN and so require DREs to retain the ability to handle removable media. Otherwise the machines could be completely physically enclosed. There would be no way to remotely confirm a voting machine has the right software on it or similar. This means the POs have to have skills to locally check the DREs. It would seem to make approaches such as http://www.gcn.com/print/27_5/45892-1.html impossible
5.6.1-B Restricting dependency on public communication networks

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

4 Comments

Comment by ted selker (Academic)

5.6.1-b should include " until a a secure record is extracted."

Comment by Kevin Wilson (Voting System Test Laboratory)

"Restricting dependency on public communication networks" The Internet and modem usage through public telephone networks are given as two examples of public communications networks. Please supply a specific definition of a "public communication network". For example, is a statewide or district-wide WAN not specifically devoted to voting a public network? In particular we are looking for what the EAC considers to be the "public."

Comment by Scott Shorter (Manufacturer)

A literal reading would indicate that the exception permits unofficial end of day results to be transmitted over the internet, is that the intention? If so, some additional communications security requirements seem necessary.

Comment by Ariel J. Feldman, Harlan Yu, Joseph A. Calandrino (Princeton University) (Academic)

This allows devices at polling places to connect to public communication networks to transmit unofficial results and interface with voter registration databases. Connecting these devices to the public networks provides adversaries with yet another interface to attack, and one that can be exploited remotely on many devices simultaneously. In addition, networks, even private networks, provide a means for viruses to propagate quickly. Thus, although networks can be useful to elections (e.g. quickly reporting unofficial results and checking voter registration in real-time), we believe that their security risks outweigh their benefits. Voting machines should never be networked to each other or to any other device, and, if possible, neither should election management systems (EMSs), polling place accumulators, or pollbook devices. We also suggest that voting systems adopt a "segregated dual-EMS architecture," where devices used to initialize an election are distinct from devices used to tabulate election results (see: J.A. Calandrino, A.J. Feldman, J.A. Halderman, D. Wagner, H. Yu, B. Zeller. Source Code Review of the Diebold Voting System. July 2007. Section 6.10.) This architecture hinders the spread of viruses and reduces the possibility that viruses could persist from one election to the next. Although we believe that the use of communication networks should be prohibited entirely, if it is allowed, we wish to note that the requirement's current language does not specify the systems to which polling place devices are allowed to connect.
5.6.1-B.1 Air gap for transmitting end of day results on election day

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

5.6.1-B.2 Air gap for connecting to voter registration databases

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

5.6.1-C Limiting network interfaces based on voting state

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

5.6.1-D Preventing traffic from passing through EMSs

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

5.6.1-E Implementing unique network identification

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.

5.6.2-A Documenting network processes and applications

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

5.6.2-B Prohibiting unnecessary communication between electronic devices

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

5.6.2-C Implementing integrity of data in transit

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

5.6.3-B Prohibiting unauthenticated communications

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

2 Comments

Comment by Kevin Wilson (Voting System Test Laboratory)

Is a PSK (pre-shared key) sufficient to meet this requirement?

Comment by Kevin Wilson (Voting System Test Laboratory)

"Prohibiting unauthenticated communications" As described in Chapter 2, just as devices fall into various categories that may be regarded in a subclass and superclass lattice, so networks can be described in the same way. Does this requirement apply to a physically controlled and wired LAN as much as it does to a WAN? In particular, the discussion in section 1:5.6.3-E suggests that there is the possibility of a "remote" connection. That in turn suggests that these requirements are targeting a specific type of network that is not physically secure. It is also not clear what networks this requirement covers from the point of view of the voting place, the vote collection center and the vote reporting system. Each of these network communication systems may or may not be physically securable.
5.6.3-C Limiting network ports and shares and associated network services and protocols

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

5.6.3-D Documenting network ports and shares and associated network services and protocols

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

5.6.3-E Documenting information available to devices

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]

5.6.3-F Minimizing information available to devices

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]

5.6.3-G Monitoring of host and network communication for attack and policy compliance

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

5.6.3-H Prevention of host and network communication based attacks

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.

5.7.1-A Event logging mechanisms requirement

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

5.7.1-B Integrity protection requirement

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

5.7.1-C Voter privacy and ballot secrecy requirement

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

5.7.1-D Event characteristics logging requirement

The voting device SHALL log at a minimum the following data characteristics for each type of event:

  1. System ID;
  2. Unique event ID and/or type;
  3. Timestamp;
  4. Success or failure of event, if applicable;
  5. User ID triggering the event, if applicable;
  6. 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

5.7.1-D.1 Timekeeping requirement

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

5.7.1-D.2 Time precision requirement

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

5.7.1-D.3 Timestamp data requirement

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

1 Comment

Comment by Diane Gray (Voting System Test Laboratory)

The Discussion states "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." It goes on to state that it is a clarification of VVSG 2005 vol. I Sec. 2.1.5.1-a by explicitly requiring the date, hour, minute, and second be recorded for each audit record timestamp. However, stating "...if the accuracy of the clock leaves something to be desired..." indicates to the reader that clock accuracy is not required. Does this mean if the clock indicates an incorrect date and time than the date of the event that this is acceptable?
5.7.1-D.4 Timestamp compliance requirement

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

5.7.1-D.5 Clock set requirement

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

1 Comment

Comment by ted selker (Academic)

This requirement should be changed to also require double lock approaches that would eliminate any single agent access to clock settings.
5.7.1-D.6 Clock drift minimum requirement

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

1 Comment

Comment by ted selker (Academic)

The voting device shall limit clock drift to be a minimum of 15 seconds within a 15 hour period after the clock is set.
5.7.1-E Minimum event logging requirement

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

5.7.1-E.1 Minimum logging disabling requirement

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:

  1. The source and disposition of system interrupts resulting in entry into exception handling routines.
  2. Messages generated by exception handlers.
  3. The identification code and number of occurrences for each hardware and software error or failure.
  4. Notification of physical violations of security.
  5. Other exception events such as power failures, failure of critical hardware components, data transmission errors or other types of operating anomalies.
  6. All faults and the recovery actions taken.
  7. Device generated error and exception messages such as ordinary timer system interrupts and normal I/O system interrupts do not need to be logged.

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:

  1. Diagnostic and status messages upon startup
  2. The "zero totals" check conducted before opening the polling place or counting a precinct centrally
  3. For paper-based systems, the initiation or termination of card reader and communications equipment operation
  4. Printer errors

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:

  1. System pass or fail of hardware and software test for system readiness
  2. Identification of the software release, identification of the election to be processed, polling place identification, and the results of the software and hardware diagnostic tests
  3. Pass or fail of ballot style compatibility and integrity test
  4. Pass or fail of system test data removal
  5. Zero totals of data paths and memory locations for vote recording

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:

  1. Login/logoff events (both successful and failed attempts)
  2. Account lockout events
  3. Password changes

Programmed device

Access control related events

Includes but not limited to:

  1. Use of privileges (such as a user running a process as an administrator)
  2. Attempts to exceed privileges
  3. All access attempts to application and underlying system resources
  4. Changes to the access control configuration of the voting device

Programmed device

User account and role (or groups) management activity

Includes but not limited to:

  1. Addition and deletion of user accounts and roles
  2. User account and role suspension and reactivation
  3. Changes to account or role security attributes such as password length, access levels, login restrictions, permissions, etc.
  4. Administrator account and role password resets

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:

  1. Changes to critical function settings. At a minimum critical function settings include location of ballot definition file, contents of the ballot definition file, vote reporting, location of logs, and voting device configuration settings.
  2. Changes to device settings including but not limited to enabling and disabling services.
  3. Starting and stopping processes.

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:

  1. The account name that made the modifications.
  2. A description of what was modified including the file name, location, and the content changed.
  3. The date and time of the modification.

Programmed device

Voting events

Includes:

  1. Opening and closing polls
  2. Casting a vote
  3. Canceling a vote during verification
  4. Fled voters
  5. Success or failure of log and election results exportation
  6. Note: for paper-based devices, these requirements may need to be met procedurally

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.

5.7.2-A Default logging policy requirement

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

1 Comment

Comment by ted selker (Academic)

"Sstorage, analysis and disposal" should be changed to, "storage, and analysis." The next sentence should read, "No log shall be deleted."
5.7.2-B Reporting log failures, clearing, and rotation requirement

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

5.7.2-C Log format requirement

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

1 Comment

Comment by Brian V. Jarvis (Local Election Official)

Recommend replacing the word "several" with a specific threshold (at least 3, at least 4, etc.) so that the requirement is verifiable.
5.7.2-D Event log free space requirement

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

1 Comment

Comment by ted selker (Academic)

"The voting device shall be capable of retaining event log data from previous elections." This must be changed. The voting device shall retain event logs from elections. These must be specifically and particularly separated and segmented in a way that they can never be confused. They must be used as records that require the election to be completed before another one is started.
5.7.2-E Event log retention capability requirement

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

5.7.2-F Log retention settings capability requirement

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

2 Comments

Comment by ted selker (Academic)

5.7.2-f, the voting device shall only allow administrators, should be changed to, the voting device shall only allow administrators with administrative double lock using more than one person to assure single agent independence.

Comment by Kevin Wilson (Voting System Test Laboratory)

The phrase "halting logging" is difficult to understand from a security point of view. An obvious attack is to cause the system to generate spurious event logs until the log is filled and then do whatever it is they want to do once the state is in "halting logging" Furthermore 5.7.1-A seems to require a logging mechanism but this requirement seems to allow such logging to be turned off under certain circumstances. Please also clarify in terms of 5.7.2-O
5.7.2-G Log rotation capability requirement

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

5.7.2-H Event log deletion capability requirement

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

5.7.2-I Event log access requirement

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

5.7.2-J Event log separation requirement

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

5.7.2-K Event log export requirement

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

5.7.2-L Log viewing and analysis requirement

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

5.7.2-M Event logging malfunction requirement

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

5.7.2-N Log file capacity requirement

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

5.7.2-O Event logging suspension requirement

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.

5.7.3-A General event log protection requirement

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

5.7.3-B Modification protection requirement

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

5.7.3-C Event log archival protection requirement

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

5.8.1-A Unauthorized physical access requirement

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

1 Comment

Comment by Carl Hage (General Public)

The requirement description should be extended to explicitly note a requirement for tamper detection that extends to the storage media and circuit boards. It should be possible to inspect and verify that a circuit board has not been tampered with, e.g. a bios chip or trusted computing security module has not been replaced. Tampering means any alteration or physical access since the original manufacturing.
5.8.1-B Unauthorized physical access capability requirement

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"

Comment

Comment by Gail Audette (Voting System Test Laboratory)

If software is available to produce an audible and visual alarm if access is gained to a restricted voting device component during the activated state, shouldn't that same software then restrict access and also log that attempt? How is this to be implemented and tested (in Functional testing)?

5.8.2 Physical port and access least functionality

5.8.2-A Physical port and access point requirement

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

5.8.3-A Physical port shutdown requirement

If a physical connection between voting device components is broken during Activated or Suspended State, the affected voting machine port SHALL be automatically disabled.

Applies To: Voting device

Test Reference: Part 3: 5.2 "Functional Testing"

Source: [NIST05]

2 Comments

Comment by ted selker (Academic)

5.8.3-a, if a physical connection between voting device components is broken during activated or suspended state, the effected machine port shall be automatically disabled. This is a very problematic requirement. In fact, accidental disconnection of cables has disabled voting machines. The question of how to reduce the impact of any connection problems during voting is certainly an issue. However, allowing a pulled cable to disable voting seems irresponsible.

Comment by E Smith/M LaTour (Manufacturer)

This section needs additional detail. A port in a suspended state may be difficult to electonically disabled. If the port is programmed such that it can only be taken out of suspension by an authenticated device (see 5.8.3.d), is that adequate? What about physical disablement of the port?
5.8.3-B Physical component alarm requirement

The voting device SHALL produce an audible and visual alarm if a connected component is disconnected during the Activated state.

Applies To: Voting device

Test Reference: Part 3: 5.2 "Functional Testing"

Source: [NIST05]

5.8.3-C Physical component event log requirement

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.

Applies To: Voting device

Test Reference: Part 3: 5.2 "Functional Testing"

Source: [NIST05]

5.8.3-D Physical port enablement requirement

Ports disabled during Activated or Suspended State SHALL only be re-enabled by authorized administrators.

Applies To: Voting device

Test Reference: Part 3: 5.2 "Functional Testing"

Source: [NIST05]

1 Comment

Comment by ted selker (Academic)

5.8.3-d, add, "with administrative double lock requiring more than one person to supervise each other to eliminate single agent, to give single agent independence." Such security measures will be required as a condition of equipment working, thereby assuring that the tamper proof locks were in place during the use of the equipment. It has been a common practice in some places to avoid, disable or ignore seals and allow human access to ballot boxes during elections without record that they were accessed. All accesses should be part of a record of use.

5.8.4 Information flow

5.8.4-A Physical port restriction requirement

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]

5.8.4-B Physical port tamper evidence requirement

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

5.8.4-C Physical port disabling capability requirement

Voting machines SHALL be designed such that physical ports can be manually disabled by an authorized administrator.

Applies To: Voting device

Test Reference: Part 3: 5.2 "Functional Testing"

Source: [NIST05]

5.8.5 Door cover and panel security

5.8.5-A Door cover and panel security requirement

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

5.8.6-A Secure ballot box requirement

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

5.8.7-A Secure physical lock strength requirement

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.

5.8.7-B Secure physical lock access requirement

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"

5.8.7-C Secure locking system key requirement

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

5.8.8-A Physical encasing lock access requirement

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.

1 Comment

Comment by E Smith - Sequoia Voting Systems (Manufacturer)

"a measure of security" is an untestable requirement.

5.8.9 Power supply

5.8.9-A Back-up power requirement

Any physical security countermeasures that require power supplies SHALL have a back up power supply

Applies To: Voting device

Test Reference: Part 3: 5.2 "Functional Testing"

Source: [NIST05]

5.8.9-B Power outage alarm

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"