Technical Guidelines Development Committee (TGDC) Agenda
Attendees: Alicia Scott Morrison, Allan Eustis, Andrew Regensheid, Angela Orbaugh, Barbara Guttman, Helen Purcell, John Wack, Mat Masterson, Neil Erikson, Nelson Hastings, Philip Pearce, Quynh Dang, Rene Peralta, Rene Peralta, Sharon Laskowski, Wendy Havens Administrative Updates (Allan Eustis):
VVSG Review (John Wack): John Wack gave a high level review of the VVSG (http://vote.nist.gov/VVSG-0807/). Some points of interest:
Plans are to have an html version of the report on line as well as a searchable database version. The current plan is to deliver the draft to the EAC around mid September. |
*************
Technical Guidelines Development Committee (TGDC) Agenda
Attendees: Alicia Clay, Allan Eustis, Angela Orbaugh, Helen Purcell, John Kelsey, John Wack, Mat Masterson (EAC), Patrick Gannon, Philip Pearce, Quynh Dang, Ron Rivest Administrative and Other Updates:
Teleconferences from 2004, 2005, 2006 and upcoming in 2006.
|
*************
Technical Guidelines Development Committee (TGDC) Agenda
Attendees: Alexia Scott-Morrison, Alicia Clay, Allan Eustis, Andrew Regensheid, Barbara Guttman, Commissioner Davidson (EAC), David Wagner, Helen Purcell, John Wack, Mat Masterson (EAC), Nelson Hastings, Quynh Dang, Ron Rivest, Sharon Laskowski, Wendy Havens, David Wagner Administrative Updates (Allan Eustis):
Independent Voter Verifiable Record (IVVR) Requirements (Barbara Guttman): Barbara discussed the changes that had been made to the IVVR section, which included upgrading the general VVPR requirements to the general IVVR requirements.
Suggested word changes were made to section 1.4.1 to clarify that if a vote is not accepted, it is not "recast". Changes were also suggested to section 1.4.4.D.1 to add that certain requirements are specified and governed by state law. Barbara and Nelson will reword these sections. Ron Rivest expressed concerns over section 1.4.J.1 (VVPR Accepted or Rejected for Multiple Physical Media). Ron felt that it was necessary to know if a voter only submitted page 1 or a vote, or page 2 of a vote, or both pages. He felt this was necessary for auditing to make sure that no one's pages were not submitted unintentionally. After discussion it was decided that this was handled in the voting procedures. Ron also expressed concern over 1.4.10.A.3 (Minimum Size of Batches). The batching size was added as a way to help when conducting an audit and making more manageable stacks. The consensus of STS was to remove the requirement 1.4.10.A (Scanner Optional Batching Support) and its sub requirements. Alexia expressed concerns over 1.4.5.D (Paper Roll CVRs on a Single Roll) that the discussion point may be redundant. Barbara to review and reword. Section 1.4.7 (Paper-Roll VVPAT Privacy and Audit-Support Requirements) will also be reworded to something such as "these requirements address threats…" Other:
[* Pursuant to the Help America Vote Act of 2002, the TGDC is charged with directing NIST in performing voting systems research so that the TGDC can fulfill its role of recommending technical standards for voting equipment to the EAC. This teleconference served the purposes of the STS subcommittee of the TGDC to direct NIST staff and coordinate voting-related research relevant to the VVSG 2007. Discussions on this telecon are preliminary and do not necessarily reflect the views of NIST or the TGDC.]
Teleconferences from 2004, 2005, 2006 and upcoming in 2006. |
*************
***********
****************
Technical Guidelines Development Committee (TGDC) Agenda
Attendees: Alexia Scott-Morrison, Alicia Clay, Allan Eustis, Andrew Regenscheid, Barbara Guttman, Bill Burr, David Wagner, Elle Colver (EAC), Helen Purcell, John Wack, Mat Masterson (EAC), Nelson Hastings, Quynh Dang, Sharon Laskowski Administrative Updates:
Open Ended Vulnerability Testing (OEVT) (Alicia Clay): Alicia went over requirements 1.1.2.F and 1.1.2.G regarding failure criteria, and noted that Santosh Chokani had comments that still needed to be taken into consideration. It was clarified and verified that the OEVT team does not have to exploit a threat; they just need to analyze and prove the vulnerability to fail the system. Two ways to fail a system were discussed. A system would fail if it does not meet all the requirements laid out in the VVSG. A system is also fail-able if there are vulnerabilities discovered (even if not covered directly in the standard) that could be exploited to change the outcome of an election. Requirements 1.1.2.F and 1.1.2.G will be reworded to clarify specifics. It was also decided to change the current draft requirements so that the OEVT team did not "define failure criteria" to "use failure criteria". There will be informative discussion text added to clarify what is meant by serious vulnerabilities. It was noted that the testing labs are the ones that make the final call on pass/fail of a system based on the OEVT team's report. Alicia discussed questions and feedback received on the OEVT requirements:
The question arose as to how the OEVT requirements would be presented and the group was informed that all requirements were presented to the EAC as draft recommendations. There was discussion regarding whether a system failed if during the testing process the OEVT team was able to break into the system but evidence was left that this had occurred. It was discussed that there is no uniform rule about evidence tracking on the system and that each requirement being tested must be looked at individually. It was decided that based on conversation there would not be a change to the requirements but that a "Rules of Engagement" paper should be written. Other:
[* Pursuant to the Help America Vote Act of 2002, the TGDC is charged with directing NIST in performing voting systems research so that the TGDC can fulfill its role of recommending technical standards for voting equipment to the EAC. This teleconference served the purposes of the STS subcommittee of the TGDC to direct NIST staff and coordinate voting-related research relevant to the VVSG 2007. Discussions on this telecon are preliminary and do not necessarily reflect the views of NIST or the TGDC.]
Teleconferences from 2004, 2005, 2006 and upcoming in 2006. |
*************
Technical Guidelines Development Committee (TGDC) Agenda
Attendees: Allan Eustis, Andrew Revensteid, Angela Orbaugh, Barbara Guttman, Bill Burr, Commissioner Davidson (EAC), Helen Purcell, John Kelsey, John Wack, Mat Masterson (EAC), Nelson Hastings, Patrick Gannon, Quynh Dang, Santosh Chokani, Sharon Laskowski, Wendy Havens , Rene Peralta Administrative Updates:
Update on Security Chapters (Nelson Hastings):
Audit Architecture (John Kelsey): This section discusses the auditing steps required to be supported by a voting system. (The other sections on electronic records and VVPR discuss the records used for auditing and the requirements on them. They also contain other security requirements besides auditing ones.) The high level purpose of the audit architecture is to discuss what auditing steps are needed to secure a voting system as software independent (SI). This is an equipment standard - the vendor must document the steps for an audit and they must be testable in the lab. [NOTE: Remove reference to VVSG 07, just title it VVSG. NOTE: Glossary will be renamed to something like "Words with Special VVSG Meaning.] Big changes to this section were to remove the primary focus of OEVT testing; make a high level explanation of steps; and to change from six auditing steps to four. The auditing steps to ensure persistent records from the voting system agrees are 1) pollbook audit, 2) hand audit of paper and electronic records, and 3) checking device records against final tally. The auditing steps to ensure vote capture device is interacting with the voter properly and recording votes fairly is observational testing. The big change was to get ride of parallel testing and spot parallel testing. [NOTE: There was discussion of whether a requirement should be added in this section to explicitly say that voting systems 'shall' be SI and it was decided that John Wack would add that to the Conformance Clause section.] Electronic Records (John Kelsey): The high level discussion on electronic records involves how particular components (voting devices) have to exchange electronic records (e.g., VVPAT system sending vote totals and ballot images to election management system), what information must be included in those records, and how they will be protected cryptographically. It also discusses the ability needed to print out reports with certain information on them that links back to the auditing chapter. Big change in this chapter was that John originally had a lot of discussion about certificates and a lot of overlap with the cryptography chapter. Much of that information has been cut and instead includes references to the cryptography chapter. The electronic records chapter also specifies two different final reports: an audit tally and a final tally. There are requirements here to protect voter privacy. John Kelsey requested comments from election officials about what information was needed in the final tally. Any comments are needed by cob Wednesday, June 20th. Voter Verifiable Paper Records (VVPR) (John Kelsey): There are two high level systems of VVPR: optical scan systems and VVPAT systems. The informational text in this chapter discusses the reasons behind VVPR - so that the voter can see their ballot to verify and so that it can be recounted. John Kelsey was not at the last TGDC plenary meeting and wanted to verify that he had captured the two major concerns from that meeting - machine readability requirements and cut sheet VVPAT requirements. [NOTE: It was pointed out that testing methods were needed to be written for the machine readable requirements. John Wack will discuss this with David Flater.] Two issues were raised. There was concern expressed about the non-human readable information contained on an op scan system not being in a public format. It was decided by members in attendance to exclude open format on op scan systems. The other issue was regarding the rejection of paper records by a voter. It was decided to include a 'may' requirement that the system allowed for election intervention but that if it did so that the number of tries necessary before election official intervention must be configurable, and that this must be done before an election begins. Another big issue in this section was in regards to cut sheets VVPATs. The original requirement did not allow for ballots to be split on multiple sheets - this would prevent using off the shelf printers and paper. It was changed to allow splitting cast vote records over multiple sheets. There is a new requirement that does not allow for questions to be split across sheets. Each sheet must be rejected or accepted individually. John Kelsey requested comments from the election officials. Requirements regarding that linking between electronic records and paper records was optional was clarified. The system must be capable of producing identifiers that link the two, but it must also be capable for election officials to turn this off. It was decided that the requirements in the VVPR section regarding batching would be deleted. ANY COMMENTS TO ANY OF THIS MATERIAL SHOULD BE SUBMITTED IMMEDIATELY. Next STS meeting is scheduled for Tuesday, June 26th. The discussion will be on OEVT. [* Pursuant to the Help America Vote Act of 2002, the TGDC is charged with directing NIST in performing voting systems research so that the TGDC can fulfill its role of recommending technical standards for voting equipment to the EAC. This teleconference served the purposes of the STS subcommittee of the TGDC to direct NIST staff and coordinate voting-related research relevant to the VVSG 2007. Discussions on this telecon are preliminary and do not necessarily reflect the views of NIST or the TGDC.]
Teleconferences from 2004, 2005, 2006 and upcoming in 2006. |
******************************
Technical Guidelines Development Committee (TGDC) Draft Agenda
Attendees: Alexia Scott-Morrison, Alicia Clay, Allan Eustis, Angela Orbaugh, Barbara Guttman, Bill Burr, Commissioner Davidson (EAC), David Wagner, Helen Purcell, John Kelsey, John Wack, Mat Masterson (EAC), Nelson Hastings, Patrick Gannon, Philip Pearce, Quynh Dang, Ron Rivest, Santosh Chokani, Wendy Havens Administrative Updates:
OEVT (Alicia Clay): Ron Rivest feels that OECT represents important progress over the VVSG 2005. The OEVT requirements draft (which goes in Volume 5, Sections 3.4 and 5.5) was discussed in detail with specific changes noted. (See Rivest e-mail notes at below).The introductory section was taken from Santosh Chokani's white paper. The goals of OEVT were outlined "The goal of OEVT is to discover architecture, design and implementation flaws that have crept into the system which may not be detected using systematic functional, reliability, and security testing and which can be exploited to change the outcome of an election, interfere with voters' ability to cast ballots or have their votes counted during an election or compromise the secrecy of vote. The goal of OEVT also includes attempts to discover logic bombs, time bombs or other Trojan Horses that may have been introduced in the system hardware, firmware or software for said purposes." The paper has a handful of requirements and discusses how the team should prioritize. John Kelsey inquired about intermediate attack goals, and was informed that they were still be taken into consideration. There is a requirement that states that you do not have to full exploit the vulnerability to point it out. Requirements have been added for reporting results and for what the testing labs are required to do. OEVT team is part of the testing lab function. Requirements:
It was decided that the paper was in pretty good shape and just needed some polishing. Alicia will work in changes and forward out to STS members shortly. The issue was discussed about what happens when a system fails OEVT. It was decided this was a matter for EAC and the testing labs. If a system fails, it will generally not be an easy fix before resubmission. Will it have to start at the beginning or should there be intermediate testing? Reevaluation is different and not the focus of the VVSG. It was questioned whether testing results would be made public. Mat Masterson to research and report back to group. There may be proprietary vendor issues.
Epoll Books (John Wack): Requirements for epoll books were revisited. John had sent out the latest draft and received a few responses back. A few questions remained that were discussed with the group. It was decided that patching/updates should be handled in the system integrity management section of the VVSG. John had put in two "should" requirements and asked the group for agreement/disagreement of keeping these in. 1) Activation devices should not be reusable and 2) Devices should only be big enough to contain necessary information. It was decided to leave the non-reusable requirement in as long as it was a should. The group would leave the size requirement in but change the scope to be include token and interface should be restricted in size. John was given the editing token to make changes to document and forward to the TGDC as a whole. Next meeting scheduled for Tuesday, June 19, 2007. The main topic will be the auditing sections. STS will also try to get some time to meet after the CRT meeting this week on the 14th. (Note this is the case and STS invited to join telcon on 7/14 at 11 am. [* Pursuant to the Help America Vote Act of 2002, the TGDC is charged with directing NIST in performing voting systems research so that the TGDC can fulfill its role of recommending technical standards for voting equipment to the EAC. This teleconference served the purposes of the STS subcommittee of the TGDC to direct NIST staff and coordinate voting-related research relevant to the VVSG 2007. Discussions on this telecon are preliminary and do not necessarily reflect the views of NIST or the TGDC.]
Teleconferences from 2004, 2005, 2006 and upcoming in 2006. |
********************
<
Technical Guidelines Development Committee (TGDC) Draft Agenda
Attendees: Angela Orbaugh, Barbara Guttman, Bill Burr, David Wagner, Helen Purcell, John Wack, Karen Scarfone, Mat Masterson (EAC), Nelson Hastings, Patrick Gannon, Quynh Dang, Ron Rivest, Sharon Laskowski, Wendy Havens Administrative Updates:
System Integrity Management and Set-up Validation (Barbara/Nelson): These chapters were discussed together because there seems to be a lot of overlap between integrity management and setup validation. David Wagner had originally questioned whether setup validation would be doable based on costs and engineering. It was agreed that it was doable. Possibilities for handling it and security risks were discussed. Nelson’s big question for the group was if, when doing system integrity management, you do integrity checks on the boot process, testing operating system before loading, and checking integrity of applications before they are loaded, do we still need setup validation? System integrity management is a preventive mechanism (don’t boot unless valid version appropriately signed), where setup validation is a discovery mechanism (to learn what’s on the system). Possible mechanisms for handling integrity management were discussed. Ron felt that the technology is available via several options and is doable. The question about who signs and when was discussed. Key management was discussed and it appears that it should be relatively simple and cost effective if done using integrity management checking. A requirement for having the vendor specify a trust model for the secure booting of software, what digital signatures are needed and how they are created, who would sign the software and where, and a users manual will be the first step. A consensus was reached to back off on setup validation requirements, making this section smaller and talking about forensics capabilities where it would be possible for labs to read the state of the systems after the fact; and instead to put emphasis on making sure that the machines do appropriate checking of signatures during boot up process, making sure only valid software is running. Nelson will get new requirements versions out, setup validation will be appropriately renamed and possibly moved to another section. Specific questions about backup were addressed – requirements should only pertain to EMS systems so the scope in the requirement needs to change. The malware requirement needs to be more specific to talk about spyware and antivirus software. Communications (Nelson): This section has been condensed and streamlined compared to the VVSG 05. It has been broken out in three different protection levels: physical communication, transmission of information, and communications related to the voting application itself. Feedback from the STS was requested:
Next Meeting:
Other:
Meeting adjourned at 11:50 a.m. [* Pursuant to the Help America Vote Act of 2002, the TGDC is charged with directing NIST in performing voting systems research so that the TGDC can fulfill its role of recommending technical standards for voting equipment to the EAC. This teleconference served the purposes of the STS subcommittee of the TGDC to direct NIST staff and coordinate voting-related research relevant to the VVSG 2007. Discussions on this telecon are preliminary and do not necessarily reflect the views of NIST or the TGDC.] Teleconferences from 2004, 2005, 2006 and upcoming in 2006. |
*************
Technical Guidelines Development Committee (TGDC) Draft Agenda
Attendees: Alexis Scott-Morrison, Alicia Clay, Allan Eustis, Barbara Guttman, Commissioner Davidson (EAC), David Wagner, Helen Purcell, John Wack, Mat Masterson (EAC), Nelson Hastings, Paul Miller, Quynh Dang, Rene Peralta, Ron Rivest, Santosh Chokani, Sharon Laskowski, Thelma Allen, Wendy Havens Administrative Updates:
Review of TGDC Plenary Meeting (Ron): Most everyone on today’s telecon were in attendance at the plenary meeting. We still have a lot to do before July. Most notable discussions from the meeting were:
John Wack will put together a list of the outcome items from the meeting and circulate it to TGDC members to verify everyone is in agreement on the resolution of the items. Voter Verification [conditional vs. unconditional] (Ron): Ron proposed the scenario that in some case (inkavote and populex systems) even though voter verifiable records are written in human readable form, it is not possible to verify the voter’s intent was correctly recorded without auxiliary information. The term human readable may need to be changed to “human readable without encoding” or “directly human readable”. John Kelsey and Sharon Laskowski will work on this requirement as it pertains to paper records and human factors. Their proposal will be sent to TGDC members for review. Software Distribution and Installation Requirements (Nelson): Nelson pointed out that a lot of the material in this section was procedural and questioned whether it should be moved into another section of the VVSG. Based on the conversation at this telcon meeting Nelson will rework this chapter to break it down; installation requirements will be part of the product standard and the software distribution (more procedural aspect) will go someplace else. Whether or not software needed to be certified by the VSTLs AND the states AND the counties was also discussed. This may be an item that should be discussed in EAC’s Best Practices or Election Management Guidelines, as the authorization structure needs to be flexible per state. VVSG’s requirements might include requiring digital signatures to check that installation is following a defined pattern or template in the installation process and several of those components may need digital signature. The determination of what components get signed and by whom should be flexible. Per STS discussion, Nelson will rewrite and re-circulate to the STS for comments. Epollbooks (John Wack): It was decided at the TGDC plenary meeting that e pollbooks could be used for both networking and ballot activation at the discretion of the election officials. STS now needs to write requirements for e pollbooks and ballot activators. Could the voting system’s software be configured to protect it against an attack that would involve the activation token? Should we have tokens that are only one-time use? Requirements that get written need to contain the following input: 1) tokens should only contain ballot style; 2) contain provisional ID if needed; 3) contain activation information; 4) system should contain macro for integrity checking; 5) source code review of activator looking for vulnerabilities; 6) extra OEVT; and 7) voting system can not write anything back to token except what it takes to deactivate it (No ballot choice information). What special requirements for e pollbooks should be included? The e pollbook should identify what mode it is in, whether networked and/or ballot activation mode. The configuration should also allow for the officials to decide which mode the system is in, there should be on/off switches for the network and ballot activator. There should also be specific requirements about backups when the network goes down so that the e pollbook continues to function. Setup validation for e pollbooks will be discussed at the June 5th STS meeting. Plans for Security Sections (Alicia): Alicia went over the 5 categories where she felt the security sections resided in terms of completion:
There are a couple of places throughout the other volumes that need STS input. John Wack will go through and determine what needs to be done. Ron Rivest and David Wagner have been providing (and will continue to provide) comments on other volumes of the VVSG. If there are any terms/definitions you want added, those need to be submitted. Next Meeting: Tuesday, June 5, 2007, at 10:30 a.m. We will cover communications, system integrity management, and setup validation. There is a possibility that we will be able to get some of the time slots originally given to CRT. [* Pursuant to the Help America Vote Act of 2002, the TGDC is charged with directing NIST in performing voting systems research so that the TGDC can fulfill its role of recommending technical standards for voting equipment to the EAC. This teleconference served the purposes of the STS subcommittee of the TGDC to direct NIST staff and coordinate voting-related research relevant to the VVSG 2007. Discussions on this telecon are preliminary and do not necessarily reflect the views of NIST or the TGDC.] Teleconferences from 2004, 2005, 2006 and upcoming in 2006. |
*************
*************
Technical Guidelines Development Committee (TGDC) Draft Agenda
Attendees: Alicia Clay, Angela Orbaugh, Commissioner Davidson (EAC), David Wagner, Helen Purcell, John Kelsey, John Wack, Mat Masterson (EAC), Nelson Hastings, Patrick Gannon, Paul Miller, Philip Pearce, Quynh Dang, Ron Rivest, Santosh Chokani, Sharon Laskowski, Wendy Havens TGDC Plenary Meeting:
Discussion on Auditing, Electronic Records, and Paper Record Requirements: John Kelsey felt that comments on the VVPR paper had been covered at the last meeting with the exception of the use of barcodes. Should they be allowed? And if so, what requirements should be written? Should the barcodes contain cast vote ballot records and should they be used for recounts or audits? Should this be a policy issue? Are they necessary considering the advancement in capabilities for OCR (OCR is voter verifiable)? It was suggested that whether or not barcodes were used should be left up to the states. It was decided that the standard would not disallow barcodes, but there would be discussion about problems when adding more complexity to the record, and discussion that if used it must be stressed that auditing to compare information is very important. They should not be used for recounts or auditing an election. Open Ended Vulnerability Testing (OEVT) - Santosh Chokani: The OEVT was updated based on David Wagner's concerns. David still had concerns over the process, but with the understanding that it was meant to be descriptive and not prescriptive caused fewer issues. Ron Rivest pointed out that the paper should be used as guidance for the team conducting the test. The team should have flexibility and a clear goal. The goal of OEVT is to find vulnerabilities that could be exploited without detection to change the result of an election. Due to limitations of resources, fully exercising a vulnerability will probably not be feasible. Today's discussion was focused on the level of effort, size of the team, and cost. The paper being discussed estimated 5 to 6 people, at 6 to 8 weeks, costing between $250K and $500K. The added "cost of this testing" causes issues for EAC as well as the state election officials. Ron stated that the costs and effort would depend on factors such as the complexity of the system, the quality of the documentation provided by vendor, number of iterations with vendor, whether it's a new system or older system, and how much expected use there will be of the system. David pointed out that extensive OEVT costs would cause barriers to entry for new innovative systems. Several options were discussed: 1) TGDC to recommend a default (mid-range) level of testing required and EAC would determine if more or less was needed based on mitigating factors of each system. 2) TGDC would recommend a default (mid-range) level of testing and the states would request more testing if they deemed necessary based on their needs. 3) Certify/test systems based on the number of systems put in use (the more systems that you deploy requires more vulnerability testing). 4) Another model would be to have a broad range of testing requirements and let the testing labs determine what is an appropriate level of testing, within that range, based on the complexity of the system. Santosh will take these points from discussion today, and using $100K as the bottom level testing amount, rework white paper. Ron then brought up the reporting based on OEVT testing. A report will be generated with the list of vulnerabilities, but then a determination has to be made as to whether they are fixable flaws or not. (If they are determined to be fixable flaws, they will have to be retested.) How does this become a standard? How do you determine whether vulnerabilities are serious enough to cause a system to fail certification? David Wagner stated that a serious vulnerability is one that if a single person, using whatever he has available, can do something that will affect the outcome of an election. When a system is tested, a list of vulnerabilities found will be forwarded to EAC for determination whether the system fails or is certified. TGDC will provide to the EAC what should be considered serious vulnerabilities. Future STS Meetings (Nelson Hastings): The STS subcommittee will continue to meet on Tuesdays after the plenary meeting. Our next meeting is scheduled for May 29 at 10:30 a.m. [* Pursuant to the Help America Vote Act of 2002, the TGDC is charged with directing NIST in performing voting systems research so that the TGDC can fulfill its role of recommending technical standards for voting equipment to the EAC. This teleconference served the purposes of the STS subcommittee of the TGDC to direct NIST staff and coordinate voting-related research relevant to the VVSG 2007. Discussions on this telecon are preliminary and do not necessarily reflect the views of NIST or the TGDC.]
Teleconferences from 2004, 2005, 2006 and upcoming in 2006. |
*************
Technical Guidelines Development Committee (TGDC) Draft Agenda
Attendees: Allan Eustis, Barbara Guttman, Bill Burr, David Wagner, John Kelsey, John Wack, Nelson Hastings, Paul Miller, Ron Rivest, Sharon Laskowski Administrative Updates (Allan Eustis):
Audit of Electronic Records and VVPR (John Kelsey): This draft chapter (prepared by John Kelsey) was distributed several days before the meeting for feedback. At the meeting, John went over major items where he would like comments: The first part of the document covers general security requirements that a paper record has to contain, what it has to do, and how it is to be processed. The first section applies to ALL voter verifiable paper records. (General requirements apply to machine marked and human marked ballots, specific requirements probably only impact machine marked.) General requirement is that paper records must contain enough information so that there is no ambiguity in how to interpret the record when performing an audit. The high level requirements may not be testable, and so a layer of sub-requirements may be necessary. John had a question regarding his requirement on the durability of paper. This should be removed (per John Wack) as it is covered by the core requirements chapter. Other general requirements are covered in specific requirements. For example, machine readable encoding - requirements cover must be included and optional inclusions. The requirement regarding public format was discussed - should all non-human readable text be in a public format. This requirement brought up the issue of the use of barcodes. John Wack suggested two options: either not allow barcodes or if allowed, add requirements to more publicly document protocol and publish warnings. Concern was shared over having the same information on a ballot in two different formats. Also, should there be anything on the ballot that in non-human readable? Some felt there was no security benefit from adding barcodes - barcodes add no benefit when conducting a recount unless there is something wrong with your voting system. Paul Miller discussed the Holt bill and felt that barcodes would accomplish the requirement in that bill about accessibility when verifying records. Barbara Guttman reminded the group that barcodes have been discussed in the past and that STS had agreed to allow them with certain requirements. This will be discussed again at the next STS telecom call. Next, VVPAT requirements: Some of these requirements will need to be moved or deleted, such as the supply requirements. There is a lot of stuff on error handling. John requested comments about anything that was missing. Are there common errors that leave a voter in a stage where the election official is not sure if they should vote again or not? Also, if you want to correct a vote, can a voter go back or does it need election official intervention? (Wasn't sure how to address these due to state requirements, comments welcome from state election officials.) The voter needs to see whether a vote was accepted or rejected right away - what happens to the paper record if a vote is rejected? Requirements also cover operation requirements, covering the ease of record comparison (easy to look at electronic record on screen and read paper record simultaneously). John requested that group look at what he has for requirements about what needs to be printed on the record and give comments. Ron Rivest brought up the problem with transporting ballots for individuals with dexterity problems and the privacy issue associated with that issue. John needs to think about that and get back. Read back requirements are going to be handled by the HFP subcommittee so that will be removed from John Kelsey's document. Privacy requirements: John would like comments. These are technical requirements, not procedural requirements. John Kelsey will look at how to handle provisional ballots. Precinct count optical scan systems: The requirement was written so that machines were able to batch records in groups of 50 or more if states requested it. This is for unit of auditability. Cut sheets for DREs. There is a requirement that says you cannot split ballots across sheets. Feedback requested. Meeting adjourned at 12:45 p.m. [* Pursuant to the Help America Vote Act of 2002, the TGDC is charged with directing NIST in performing voting systems research so that the TGDC can fulfill its role of recommending technical standards for voting equipment to the EAC. This teleconference served the purposes of the STS subcommittee of the TGDC to direct NIST staff and coordinate voting-related research relevant to the VVSG 2007. Discussions on this telecon are preliminary and do not necessarily reflect the views of NIST or the TGDC.]
Teleconferences from 2004, 2005, 2006 and upcoming in 2006. ************* |
Technical Guidelines Development Committee (TGDC) Draft Agenda
Attendees: Allan Eustis, Angela Orbaugh, Barbara Guttman, Bill Burr, David Flater, David Wagner, Helen Purcell, John Wack, Mat Masterson (EAC), Nelson Hastings, Patrick Gannon, Quynh Dang, Rene Peralta, Ron Rivest, Santosh Chokani, Sharon Laskowski, Thelma Allen, Wendy Havens Administrative Updates:
Discussion of Requirements from VVSG Volumes 3 and 4 (Patrick Gannon): Interoperability: Patrick Gannon wanted to discuss his concerns with requirements in Volume 3 regarding interoperability and Volume 4 regarding interface description. Current requirement in Volume 3: "All systems shall maximize interoperability and integratability with other systems and/or devices of other systems." And "Interoperability through open export -- The interoperability and integratability requirement may be met by providing the capability to export data in a royalty-free, published, open format." Patrick Gannon proposed adding the word "commonly agreed upon" to the requirement. This was discussed in detail. Mr. Gannon wanted to know what to goal of the requirement was, if it was to produce interoperability as it currently says, then we need to write requirements that would support getting a vendor to that by requiring a commonly agreed upon format. Several members agreed that interoperability is a goal for future systems - right now we are requiring integratability. This requirement will written in two parts. There will be a shall requirement on integratability. The existing high level requirement will reduce the use of interoperability but say that vendors "should strive for interoperability". There will be a discussion text added that says e.g., "to reduce barriers to interoperability, vendors should strive to use a commonly agreed upon industry standard format". The ballot image data requirement is only required for DREs, it is not mandated for opscan systems and STS cannot see any security requirements at this time for it to be required for opscan systems. It was discussed if these requirements would be for only new systems, or would other systems have to be retrofitted - we are talking about requirements for new procurements of systems. It is up to the state how they handle older equipment and what is grandfathered. Electronic Records Requirements: Patrick Gannon wanted to know where this was in the process, and what was the intended use. John Kelsey informed the group that he had sent around a paper for comments. This document is intended to be requirements that address known threats - a set of requirements that address security issues for electronic records. Mr. Gannon wanted to know if this covered requirements for common ballot formats as specified in resolution 2305. The core requirements section covers specifics about electronic record formats including what data needs to be in there. Election definition functionality that the EMS is required to support is in there as well. Additional requirements in regards to reporting abilities appear in the reporting section. Mr. Gannon requested something that would provide a list of all the requirements that responded to resolution 2305 since they appear in different sections of the VVSG. Allan Eustis suggested a link from the glossary under common data format referencing each section that responded to it. Mr. Gannon suggested something easy as a "see also" added to the requirements. Cost of Testing Summit (Mat Masterson, EAC): EAC hosted a summit on the cost of testing voting systems. Approximately 40-45 people in attendance from vendors, testing labs, advisory groups, NIST. There were presentations and responses to questions that had been posed by Brian Hancock before the meeting. No minutes were prepared for this meeting. Couple major points:
Access Control Requirements (Nelson Hastings): This item was deferred to the Thursday May 10 telcon meeting. OEVT (Santosh Chokani): Santosh's paper was distributed before the meeting. The purpose of this document is to define the scope of and approach to Open Ended Vulnerability Testing (OEVT) prescribed in VVSG "2007" in light of the software independent verification of cast ballots. The goal of OEVT is to discover architecture, design and implementation flaws that have crept into the system which may not be detected using systematic functional, reliability, and security testing and can be exploited to change the outcome of an election or can otherwise provide erroneous results for an election. This document assumes that the voting systems are not networked. Requirements are listed in sections 3.1, 3.2, and 3.3. Team expert composition is defined in 3.4. There are 16 OEVT steps that are to be carried out for each computer system component such as voting machine, central tabulator, etc. Input into this process include security documentation from the vendor, access to source code, type of tests conducted, how rigorous were the tests. Ron wanted to know if there was a level of effort in the document. Santosh reported that that had not been included yet. Requirements to the vendor: vendor must supply adequate documentation including threat models, team expertise, level of effort, document describing every security mechanism in the system and what security threat it addresses. In terms of getting this ready for the VVSG, what needs to be done? The subcommittee needs to review this document and get comments to the STS mailing list or Santosh. This is an important part of the committee's work and needs to be pushed forward. Next meeting is scheduled for Thursday, May 10, 2007, at 11:45 a.m. Meeting adjourned at 12:00 p.m. [* Pursuant to the Help America Vote Act of 2002, the TGDC is charged with directing NIST in performing voting systems research so that the TGDC can fulfill its role of recommending technical standards for voting equipment to the EAC. This teleconference discussion is for the purposes of the STS subcommittee of the TGDC to direct NIST and coordinate its voting-related research relevant to the VVSG 2007. Discussions on this telecon are preliminary and do not necessarily reflect the views of NIST or the TGDC.] Teleconferences from 2004, 2005, 2006 and upcoming in 2006. ************* |
Technical Guidelines Development Committee (TGDC) Draft Agenda
Attendees: Alexis Scott Morrison, Allan Eustis, Barbara Guttman, Brian Hancock (EAC), Commissioner Davidson (EAC), David Wagner, Helen Purcell, John Kelsey, John Wack, Jon Crickenberger (NVLAP), Mat Masterson (EAC), Nelson Hastings, Patrick Gannon, Quynh Dang, Rene Peralta, Ron Rivest, Santosh Chokani, Secretary John Gale, Sharon Laskowski, Steve Freeman (NVLAP), Wendy Havens Administrative Updates (Allan Eustis):
E-Poll Books: The discussion regarding e poll books was a continuation from previous STS meetings. The CRT and HFP subcommittees were invited to participate in this discussion. The hope for the meeting was that two major decisions would be made regarding e poll books. First decision was whether e poll books should be used to activate ballots and the second was whether externally networked e poll books should be allowed to activate ballots. The main use for e poll books is as a registration device to be used when a voter comes in, to look up their name, verify they are authorized to vote, and to assign them the proper ballot. John Kelsey expressed the issue regarding privacy. The concern was that if an e poll book knew the name of the voter and the ballot activation code, and the voting system knew the ballot activation code and the selections on the ballot, that those two could be combined to find out who voted for whom. There appears to be a risk that if the two pieces of equipment retain this information there is a risk factor involved. The trade-off in not using an e poll book to activate ballot is the possibility of human error, when poll workers have to manually activate the ballots. If we allow ballot activation, requirements need to be written that minimize the risk of the flow of information, or requirements that the system does not store authorization codes. David Wagner summarized his opinions by saying that it would be too disruptive not to allow ballot activation by e poll books, but that we have to write technical requirements barring identifiers. This would not cause extra work for poll workers or election officials. Ron Rivest stated that the recommendation on the table was to allow e poll books to do ballot activation (decision currently based on books not being externally networked). This was agreed to by members of TGDC on the call. The second topic for discussion regarding e poll books was that should they be allowed to be externally networked and also activate ballots. This was defined as whether systems should be networked outside the polling place on Election Day. This includes connection via a dedicated phone line, internet, data network, cell phone, etc. The need for allowing this would be that if you're using voting centers, voters would be allowed to vote anywhere but also to prevent the voter from casting votes at different locations. There are three risks involved, 1) reliability - if the network goes down and the voting system relies on the e poll book to activate ballots, this could stop an election for all machines at a precinct, 2) someone could deliberately try to induce this kind of overload condition of network unavailability, like a denial of service, and 3) security risk - a hacker may be able to compromise an e poll book and then compromise all e poll books in the county. David Wagner was concerned that we do not know how to write standards if we allow networked e poll books to activate ballots. [Alexis Scott Morrison questioned how this could be accomplished. Would there be a system designed so that if it was networked the ballot activation device would not work? Or would there be two types of e poll books, one for activation and one that was networked? David Wagner seemed to think the first system would be the case as this should be a software change/capability.] Helen Purcell recommended that e poll books that were externally networked not be allowed to activate ballots -contingent on further discussion at the TGDC plenary in May. Several members of the TGDC concurred. There could be additional ballot activator costs required and additional research here makes sense. Secretary Gale asked for clarification on the way the system and interface would work functionally. There are issues of reliability, availability and back up for the e-poll book. Ron Rivest noted that the error problem is solvable- with extra check digits. There would be extra works for the poll worker. The issue could be revisited in the future. Ron recommended we make Helen's recommendation to the full TGDC. Secretary Gale expressed his reservations with the limited basis of facts at hand. Ron Rivest suggested a requirement supporting the dual mode devices as a configurable option for the election administrators with the security caveats. The STS members decided to put forward two alternatives to the TGDC at the full May plenary with a recommendation of one alternative over the other- allowing for full discussion at that time. The meeting adjourned at 11:50 EDT. [* Pursuant to the Help America Vote Act of 2002, the TGDC is charged with directing NIST in performing voting systems research so that the TGDC can fulfill its role of recommending technical standards for voting equipment to the EAC. This teleconference discussion is for the purposes of the STS subcommittee of the TGDC to direct NIST and coordinate its voting-related research relevant to the VVSG 2007. Discussions on this telecon are preliminary and do not necessarily reflect the views of NIST or the TGDC.] Teleconferences from 2004, 2005, 2006 and upcoming in 2006. ************* |
Technical Guidelines Development Committee (TGDC) Draft Agenda
Attendees: Allan Eustis, Angela Orbaugh, Barbara Guttman, David Flater, David Wagner, Donetta Davidson (EAC), Helen Purcell, John Crickenberger (NVLAP), John Kelsey, John Wack, Mat Masterson (EAC), Nelson Hastings, Patrick Gannon, Quynh Dang, Rene Peralta, Ron Rivest, Santosh Chokani, Sharon Laskowski, Steve Freeman (NVLAP), Wendy Havens Administrative Updates (Allan Eustis):
Innovation Class (John Wack): The discussion paper prepared by Rene Peralta outlined a general approach that needs to be taken by an EAC review board reviewing submissions to the innovation class. There have been lots of discussion online and off, as well as conversations with the EAC, regarding the innovation discussion paper. We are trying to write requirements for the VVSG that are testable and allow innovation class submissions to start the process of submitting, with adequate documentation, to the review board. [NOTE: CRT has written a paper on the maintenance of the VVSG. The innovation class requirements may fall under maintenance - which would be looking at the VVSG periodically for errors and/or additions and making them. Innovation class could be handled by writing some initial requirements and making edits/changes periodically.] John had distributed 3 papers via e-mail with material related to the innovation class. The first one covered the conformance clause. At the end of this document, there are a couple requirements for the innovation class submissions. Some submissions may not conform to the VVSG. Either there are not requirements for the new type of design, the design satisfies the requirements in a different way, or the requirements are not broad enough. Someone submitting a new design should take a look at the hierarchy of the class and decide where the device would reside, letting the review board know where it fits and how, what requirements it does and does not meet, and why the design is innovative. Right now all we have are documentation requirements. It is too early to write functional requirements. The second item distributed was volume 4 of the VVSG containing documentation requirements. These include core requirements mostly, along with some security. More security and human factors to be added. David Flater has added a lot of requirements here to cover innovation class, including requirements for hardware and design construction. [NOTE: In the conformance clause David Flater added that innovations are not allowed to collide with existing requirements. There may be new requirements and the submitter should state what they are and make a case for them] The third item distributed was Rene's original discussion paper which was prepared as guidance to the EAC and how to set up for the review process. EAC felt that this was only one approach and would like to see alternative approaches or a broader general description. EAC wants to meet with NIST to discuss this further. If we approached this submission like any other, it would require a system to meet a lot of requirements. These submissions are likely to come from smaller companies and this may be difficult - should be a choice for them to submit design for approval before further development. TGDC's scope included development of initial innovation class requirements - the follow on is up to EAC: to implement the review board and associated procedures. TGDC needs to make sure documentation requirement is as comprehensive as possible. Next steps: NIST needs to revise white paper and start preparing advice white paper to send to EAC in regards to the discussion today. Rene requested guidance on what TGDC members are looking for. Ron suggested framing it in a series of questions about what needs to be addressed. Identifying what needs to be answered for the innovation class to work. E.g., does vendor need to submit hardware, will there be an external review board, at what stage in the design process should the vendor submit. All questions are policy questions and EAC needs to answer. All STS members should submit suggested questions to Rene. Other Topics: Barbara Guttman suggested that STS outline topics that need to have a consensus reached by the May plenary meeting. They include:
Nelson Hastings will send an email summarizing these topics and when they will be discussed. Barbara asked how the TGDC liked to receive background information on subjects and agreement was short synopsis. Epollbooks: John mentioned the topic of discussing what could be done to activate ballots separate from e poll books. His opinion was that the conclusion was not to restrict e poll books from voting centers and updating databases, but to not use them for ballot activation. If e poll books are not used for ballot activation they are not part of the voting system and are considered registration devices and outside the TGDC scope. If they do activate ballots, they are considered part of the voting system and are subject to the VVSG requirements that say no part of the voting system can be externally networked. Consensus appears that if they are used for ballot activation, they cannot be networked. This appears to be in conflict with what was decided at the March 2007 TGDC plenary. Final decision of STS's recommendation has to be reached so that it can be brought up at the May meeting and clarification made on decision by TGDC as a whole. John Kelsey has privacy concerns over using e poll books for ballot activation even if they are not networked. This topic will be discussed in detail at an upcoming STS meeting. May Plenary Meeting: Topics to be presented currently appear to be innovation class, e poll books, and open ended vulnerability testing. Meeting adjourned at 11:40 a.m.
[* Pursuant to the Help America Vote Act of 2002, the TGDC is charged with directing NIST in performing voting systems research so that the TGDC can fulfill its role of recommending technical standards for voting equipment to the EAC. This teleconference served the purposes of the STS subcommittee of the TGDC to direct NIST staff and coordinate voting-related research relevant to the VVSG 2007. Discussions on this telecon are preliminary and do not necessarily reflect the views of NIST or the TGDC.]
Teleconferences from 2004, 2005, 2006 and upcoming in 2006. ************* |
Technical Guidelines Development Committee (TGDC) Agenda:
Administrative Updates: There were no updates this week E-Poll Books: This weeks meeting continued to focus on e-poll books. As written, the VVSG does not permit networked e poll books to activate ballots. David Flater has added a device class bubble for ballot activation to the voting system diagram in the requirements. A device that activates the ballot is considered part of the voting system, so if an e poll book activates ballot, it is subject to the requirements of the VVSG. Currently, we have direction from the TGDC to allow externally networked devices to activate ballots. This direction either needs to be added to the VVSG or STS needs to go back to the TGDC formally with the recommendation that this direction be changed. STS needs to reach a consensus and decide how to implement. Key issues on the table for discussion:
E poll books are used to make sure voters are authorized to vote, in what jurisdiction, and to make sure they only vote once, and to give them the right ballot. These are registration activities and are different than activating the ballot. Concern was expressed over allowing ballot activators to be externally networked. There are security issues, privacy issues, and reliability issues. What happens if the network goes down, is voting stopped at that precinct for the day? Ron Rivest as well as other members of the subcommittee felt it not be best to externally network these activation devices. What are the next steps? We need to receive more input from election officials. At the STS subcommittee meeting in two weeks we will invite HFP and CRT members to join in discussion to make sure that all concerns and benefits are discussed. E-poll Books (whether networked or not) should activate ballots (because of privacy issues)? John Kelsey expressed concern over allowing devices that contained identifiable information on voters to talk to machines that contained the vote records. With this communication it would be possible to reconstruct how an entire state voted. Ron inquired about possible guidelines. John Kelsey suggested separately the e poll book (registration device) completely with an air gap from the mechanism that records the votes. Ron felt this would cause procedural mechanisms to get very complex and would allow for human error rate and usability concerns. When talking about privacy, there is not external audit. We have to rely on the integrity of source code, certification, and software distribution management. We can write standards to these issues. This issue was tabled for the meeting. It will be revisited at the meeting in two weeks. Innovation class: John Wack gave a short overview of the innovation class issues. STS Subcommittee was looking at coming up with general procedures about how these submissions should be reviewed and how to make testable requirements. We are now looking at 1) specific requirements for the VVSG that can be used to evaluate system and 2) guidance to the EAC of how to handle the other aspects in the evaluation process. This will be covered at next weeks STS meeting. Meeting adjourned at 12:00 p.m. [* Pursuant to the Help America Vote Act of 2002, the TGDC is charged with directing NIST in performing voting systems research so that the TGDC can fulfill its role of recommending technical standards for voting equipment to the EAC. This teleconference served the purposes of the STS subcommittee of the TGDC to direct NIST staff and coordinate voting-related research relevant to the VVSG 2007. Discussions on this telecon are preliminary and do not necessarily reflect the views of NIST or the TGDC.] Teleconferences from 2004, 2005, 2006 and upcoming in 2006. |
*************
Technical Guidelines Development Committee (TGDC) Draft Agenda
Attendees: Allan Eustis, Angela Orbaugh, David Wagner, Helen Purcell, John Kelsey, John Wack, Mat Masterson (EAC), Neslon Hastings, Quynh Dang, Ron Rivest, Santosh Chokani, Sharon Laskowski, Wendy Havens, Alicia Clay, Rene Peralta Administrative Updates:
The remainder of the meeting was focused on requirements for e-poll books and ballot activation. John Wack said that the EAC has asked that we address e-poll books in terms of privacy, ballot activation, possibility that they are leaking information, and what we can do about it. One option was to add e-poll books as a new class of device to the VVSG and develop requirements for them. We opted out of this option due to time constraints. We decided to beef up privacy requirements and to take a closer look at ballot activation. One solution was to write a requirement that said ballot activation (in essence) cannot create possibility of a covert channel between e-poll book and voting station, and vice versa - the ballot activation technique would be used for activation and nothing else. Ron Rivest suggested that the ballot activation device not be reusable. It should not allow writing back to the device that would then be placed back in the e-poll book - this would allow for the possibility of information leaking from the voting station back to the e-poll book. A big question that arose was whether or not e-poll books should be simultaneously externally networked and also used for ballot activation. Discussion centered around the risks involved with this. One purpose of e-poll books is to have them networked with voting central to keep track of who has voted, so as not to have double voting by individuals at different locations. [NOTE: The distinction was made between external networking versus networking amongst the voting systems at a particular voting location.] The proposal at the March plenary meeting that we keep e-poll books doing what they are currently doing, and using a separate mechanism for ballot activation. It was felt that the TGDC did not want this solution. Three concerns to keep in mind when writing requirements: without networked information, it might be possible for voter to vote more than once at a different location; if e-poll book is networked, an external attack from a hacker could cause the voting systems to crash at poll site and leave in non- functional; concern over voter privacy - there could be a channel of some sort between the e-poll book and the voting system which could leak information back to e-poll book from voting system. Other concerns were expressed regarding reliability. If e-poll books are used for ballot activation, and they are compromised or go down, there needs to be some sort of back-up, otherwise the voting station would not be able to continue. Several suggestions were brought up.
It was suggested that the STS subcommittee concentrate on writing requirements for ballot activation devices (not e-poll books) to be discussed at next meeting. There was concern about the need to receive input from local election officials about how much of a poll worker usability problem having separate devices would cause. John Wack will draft up a set of questions for Mat Masterson (EAC) to use to canvass for feedback. Helen Purcell will also distribute to the Election Center for feedback. Meeting adjourned at 12:00. [* Pursuant to the Help America Vote Act of 2002, the TGDC is charged with directing NIST in performing voting systems research so that the TGDC can fulfill its role of recommending technical standards for voting equipment to the EAC. This teleconference served the purposes of the STS subcommittee of the TGDC to direct NIST staff and coordinate voting-related research relevant to the VVSG 2007. Discussions on this telecon are preliminary and do not necessarily reflect the views of NIST or the TGDC.] Teleconferences from 2004, 2005, 2006 and upcoming in 2006. |
*************
**************
Security and Transparency Subcommittee (STS) Teleconference* Agenda:
Participants: Allan Eustis, Angela Orbaugh, Barbara Guttman, Bill Burr, David Flater, Helen Purcell, John Wack, Mat Masterson (EAC), Nelson Hastings, Patrick Gannon, Rene Peralta, Ron Rivest, Santosh Chokani, Sharon Laskowski, Steve Berger, Wendy Havens Administrative Updates (Allan Eustis):
Review of Joint STS-HFP Teleconference At the joint HFP/STS meeting, two topics were on the agenda: First, software independence and accessibility for the voter and second, software independence and its implications on the usability of audits. As an action item from discussion of the first topic, John Cugini is working on a paper outlining some methods to be discussed on 2/23. One key issue to keep in mind is the notion of SI and accessibility in understanding all the ramifications and complexities when reviewing voter verification. John Wack expressed concerns that the machines used for voter verification would not be the same for both sighted and unsighted voters. Discussion ensued on "separate but equal" access or more appropriately "sufficient" access. Discussion has not occurred regarding implementation details regarding usability. The significance of auditability to security needs to be stressed - a proposal to toss auditability was a non-starter. The next joint STS/HFP meeting is 2/23/07 at 11:00 a.m. Update on Comments Received on Access Control and System Event Logging Sections All comments that were received last week have been reviewed. Some changes have been made, such as the comments regarding improving requirements with the wording "shall be capable of" have been corrected. Subcommittee is currently reviewing comments about items that should be in other sections. Three specific questions were discussed:
Update on Modifications to Setup Validation Section All changes discussed at the last STS conference call were made for the section on software identification and software verification. One of the changes was limiting the scope of software requirements to election management systems. Discussion ensued about the scope of set up requirements on networked devices. This had been brought up originally by David Wagner because of a concern with viruses. Nelson has extended the scope in the paper to include not only the verification but the identification part as well. Consensus was reached that identification needs to be universal. Discussion continued about which pieces needed strong verification. Election management systems. The requirement regarding Network Vote Capture Devices will be changed to Vote Capture Devices and written with a "should", with the recommendation that this will become a "shall". A note will be added in the Discussion section annotating this. Nelson then clarified what had been deleted. Correct behavior of the verification software requirement, external port requirement, chain of custody requirement, robustness of the verification technique, and sourcing of the verification hardware and software from parties other than the vendor were removed. The digital signature-centric language was modified. Barbara asked for a clarification about the impacts of the changes. These changes are all related to the requirements on the verification technique that was used. It was generalized to say that a technique had to be used, but it did not get specific. A clarification was then asked regarding what requirements were written to make sure a technique was good. Nelson will send out an email clarifying - the requirement needs to be strong but flexible. Exchange Standards for Election Data (David Flater) This subject is being brought up because STS was interested in looking at possibility of representing cast vote records and possibly other things in a standard export format. CRT's testing requirements are more broad than what's needed by STS. EDX cannot be used because it is the intellectual property of Hart. The current version of EML has a lot of issues - too many for testing as required by CRT. They are currently working on a new version but not sure if that will be ready in time for VVSG 07. One issue that will not be resolved in the next iteration is the conceptual distinction between a vote tally and a ballot count. John Wack feels that we will not be able to point to a specific standard by draft time. EML V5 may not be out in time to be referenced. Ron Rivest suggested that we put a placeholder in that states "cast vote records will be in a plausible open format, meeting the following requirements, etc." with the understanding that it could be replaced when EML V5 or V6 come out. STS needs to specify a list of requirements to determine if the next iteration will meet its needs. A comment could be added about it being STS's hope that EML will be the language we use as a standard. Meeting adjourned at 12:00.
Teleconferences from 2004, 2005, 2006 and upcoming in 2006. ************* |
Participants: Alicia Clay, Allan Eustis, Angela Orebaugh, Barbara Guttman, Bill Burr, David Flater, David Wagner, Helen Purcell, John Cugini, John Wack, Nelson Hastings, Patrick Gannon, Philip Pearce, Quynh Dang, Rene Peralta, Santosh Chokhani, Wendy Havens Agenda:
Administrative Updates:
Cross Subcommittee Topics: COTS: A discussion took place of the proposal by CRT. The discussion paper suggested having a list of approved COTS software that can be used in voting systems. This suggestion would require EAC support and buy-in in order for it to be implemented. Discussion papers clarifies relevant concepts - everything submitted is NOT either COTS or non-COTS. Paper contains more precise definitions. It deals with the applicability of requirements to COTS. David Flater inquired if there was any feedback/comments to the paper. David Wagner (with no objections) stated that STS agrees with CRT's approach to COTS. David W will send an email to Ron Rivest regarding trusted COTS to see if there are any issues he would like to raise. HFP: John was asked to expound on Whitney's end-to-end paper and on his SI/Accessibility paper. John outlined the thesis of the end-to-end paper: main problem is how/whether to achieve comparable verifiability for blind voters as for sighted. Main technical suggestions so far seem to be: a. non-vendor-dep't OCR and b. audio tape. Are these feasible? Are they SI? Not knowing where Whitney stands on some topics, John preferred not to comment any further. Discussion on SI/Accessibility paper: STS subcommittee felt we need to distinguish two goals: first, protect election versus second, enable individual voter verification - do the two specific approaches suggested for blind voter verification meet the need, i.e. would they count as SI-type voter verifiability? David Wagner suggested that maybe Goal #1 must be strictly SI, but Goal #2 need not be - the implication is that plain old audio verification (clearly non-SI) for blind voters is good enough as long as the mechanism is checked thoroughly enough not to endanger the election. That is, maybe the Acc-VS itself need not be SI? The issue is whether the VVSG mandates an expensive/high-tech approach that is (arguably) SI, or whether the cheaper/low-tech, but non-SI, approach is good enough. Rene Peralta noted that the TGDC adopted Goal #2 in the SI resolution passed in December. David Wagner suggested that SI does not rule out software to read the record of the vote. Discussion followed on two potential methods for verification. Are these good security approaches? U.S. Access Board concept of "complimentary accessibility" mentioned. What is the merger of adequate accessibility with adequate security? Philip Pearce emphasized that accessibility requirement extends beyond blind to low vision, and cognitive disabilities. Barbara Guttman recommended that accessible voting station (both audio and print output) should be able to be verified by all voters. Discussion of direct/indirect verification by both blind and sighted voters followed. Conclusion that the best we can do is to maximize the number voters that can verify their vote. (Philip Pearce will get input from U.S.Access Board on these issues).
Concern at this time with interoperability standards; they will be a focus of next STS meeting. Dave Flater recommended considering using "mays" in some of these requirements to not preclude solutions.. SI and Set Up Validation Nelson Hastings summarized the papers. Discussion of software related requirements in set up followed including digital signatures and (trusted) external port issues. David Wagner suggested you need to be more precise as to applicability. Make digital signature requirement a "shall". With external port, architectural changes in the hardware of voting systems are required. This is expensive. Should we eliminate software integrity requirements because of SI? Option two would be to modify software integrity requirements- make them "shoulds". There are cost issues; Plausible to make trusted external port as a "should" requirement. David Wagner noted that SI does not solve some threats such as denial of service attacks. Nelson brought up issues of performance metrics/techniques. David suggested stating goal and listing accessible modes and performance based techniques. Need testable requirements. Concern expressed with use of the word "Trusted" with external port. Suggestion to look at gaming industry set up requirements. John Wack will send out e-mail. 5) Next call Tuesday, February 20, 2007 @ 10:30 AM EST [* Pursuant to the Help America Vote Act of 2002, the TGDC is charged with directing NIST in performing voting systems research so that the TGDC can fulfill its role of recommending technical standards for voting equipment to the EAC. This teleconference discussion served the purposes of the STS subcommittee of the TGDC to direct NIST and coordinate its voting-related research relevant to the VVSG 2007. Discussions on this telecon are preliminary and do not necessarily reflect the views of NIST or the TGDC.]
Teleconferences from 2004, 2005, 2006 and upcoming in 2006. ************* |
Agenda:
Participants: Alan Goldfine, Alicia Clay, Allan Eustis, Angela Orbaugh, Anoop Singhal, Barbara Guttman, Bill Burr, David Wagner, Donetta Davidson, John Kelsey, Nelson Hastings, Patrick Gannon, Ron Rivest, Santosh Chokhani, Sharon Laskowski, Wendy Havens Administrative Updates (Allan Eustis):
Software Independence (SI) Impact on Access Control and System Event Logging Requirements: The chapters on Access Control and System Event Logging were forwarded around to STS members. The access control document was presented (in substantially the current version) at the March 2006 TGDC meeting, edited, and put in final VVSG 07 format. The event logging document has received NIST review, it needs to be reviewed by STS and TGDC. Due to software independence, do the chapters need to have more or less requirements? Are there general guidance/broad principles that we should be using to decide whether to add/remove requirements due to the new software independence material? Answer by David Wagner and Ron Rivest is that we should still be using the cost/benefit trade-off review. When you remove or add a requirement based on impact from SI, make a note of it. Much of the discussion relating to this agenda item centered on requirements that would require software versus hardware changes. Access control requirements recommend multi factor access control that may need something soldered to the mother board requiring a hardware upgrade. Logging event requirements may require hardware upgrades that allow for writing to “write-once” media. David Wagner and others expressed desire for compliance be possible with only software upgrades. Donetta Davidson stated that it should be made clear whether the new requirements would make it necessary for hardware to be retrofitted or upgraded. This would help TGDC and EAC when considering these recommendations. John Kelsey is concerned that it will be hard to determine what kind of effects the requirements are going to have on systems. Without a survey, we are not going to know how many machines are affected. ACTION: Allan Eustis and Nelson Hastings will discuss bringing this up at the next vendor meeting. The event logging discussion centered on the importance of keeping these logs. Are they being used? It was suggested that a requirement should be written that logs are forwarded to a central location, transmitted with the voting records. A system must have the capability so that everything can be pulled off the system at once – ballots, event logging, etc. An inquiry was made whether there was a standard format for the logs. It was agreed that the requirement should be that the logs are in standard format or a utility provided to convert them to a standard format. There must also be a requirement saying that confidentiality must be protected when event logs are generated. The logs will be useful for finding problems with the system, e.g., shutdown or logout during use, software upgrades, administrator account access, etc. Further comments are requested by next week.
Discussion of Security Related Topics for Other Subcommittees:
Discussion of Innovation Class: Two parts to the requirements we need to write. First, generic requirements that specify what the voting system has to do. (Do we write new requirements or identify requirements we already have? These are requirements that transcend the architecture no matter what the architecture is.) Second, we need to write setup procedures that identify the evaluation process. This innovation class evaluation procedure needs to be ready when the vendor has a new system. We have to allow for conceptual systems to be reviewed before huge investments are made. The review process might be in two stages. Stage 1, the vendor would provide a detailed description of the system they would like to build with justifications. Stage 2 would be a regular full review with the panel of experts and VSTL review. The question was asked if this panel would be EAC-run and if so we need to provide a white paper outlining TGDC recommendations and allow for public comment.
Next STS teleconference is Tuesday, February 6, 2007, at 10:30 a.m.
Teleconferences from 2004, 2005, 2006 and upcoming in 2006.
************* |
Agenda:
Administrative Updates: Allan Eustis:
John Wack:
Summary and Status of STS Activities: Changes reflect the new table of contents that will appear in the VVSG2007. Currently appears as: Security and audit architecture overview: Several draft white papers have been written. John Kelsey is working to consolidate his papers and edit; he is working with B. Guttman to get into right format. This is where the threat analysis is housed, as well as assumptions, verifying integrity of vote, and audit requirements. Ron mentioned we haven't discussed specifics on auditing techniques. How do we handle the things that can not be handled by the testing labs but need to be supported in this document? Are procedures being handled in VVSG 2007? Usability of auditing procedures and auditing techniques need to be included. OFF AGENDA DISCUSSION: Audit requirements (in chapter 2) - issues regarding usability and accessibility regarding paper based systems will be handed over to HFP subcommittee. At the election center discussion (last week), manual counting was brought up and issues about what could be done to make it easier. John Wack talked about bar codes as a possibility. How do you write a usability standard for this?
Discussion of security related resolution and impact on security requirements: David Wagner questioned whether we should go easier on some of the requirements now that SI is being included. If so, what should be done? Now that we have an emphasis on auditability, it is appropriate to consider making some "shoulds" to "shalls". Looking at the 3 resolutions that passed, we've already looked at innovation class. Next is wireless security resolution: straight forward how requirements are written and the implications on wireless technology. Third is software independence: specific questions and examples regarding setup validation. Two categories of setup validation: the physical condition of the system and the validation of the software on the system. How does SI impact this? How much do we care about the accuracy of system setup information before the election - these are still important. Cost versus necessary functionality. With SI, you can audit after you vote. Existing systems that don't offer SI need to continue to be certified under 2007 standards, but new standards must have SI. "Grandfathering" strategies will be developed by the EAC and are outside TGDC's scope. Setup validation strategies will also be brought up to the EAC - requirements are not useful if they're not used. Consensus on the phone call to reduce setup validation requirements if there's a strong cost benefit to do so, since we have independent verification. Nelson Hastings should come up with possible changes/reductions. NVLAP will have accredited labs announced soon that will be able to test VVSG 2005 requirements. Other Items:
Next teleconference - Tuesday, January 23rd at 10:30 a.m. EST Teleconferences from 2004, 2005, 2006 and upcoming in 2006. ************* |