Skip to main content
U.S. flag

An official website of the United States government

Official websites use .gov
A .gov website belongs to an official government organization in the United States.

Secure .gov websites use HTTPS
A lock ( ) or https:// means you’ve safely connected to the .gov website. Share sensitive information only on official, secure websites.

TGDC Subcommittee Work - Historical Meetings - STS Meetings - 2007

Technical Guidelines Development Committee (TGDC)
Security and Transparency Subcommittee (STS) Teleconference *
August 14, 2007, 10:30 a.m.
Draft Minutes

Agenda

1) Administrative/Logistical Updates for upcoming 8/17 plenary (Allan)
2) Overview of the draft VVSG document and Companion Executive Summary (Wack)
3) Other Items

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):

  • This STS teleconference was opened up to the TGDC as a whole to do a high level review of the VVSG.
  • Friday's TGDC plenary meeting will begin at 11:25 a.m. ET. Dr. Jeffrey, Tricia Mason, Commissioner Davison and NIST staff will be participating from NIST, the rest of the TGDC will join by teleconference.
  • NIST will be doing a dry run on Thursday (8/16//07) at 3:00 p.m. Members are invited to call in at 4:00 p.m. to test the TRACE hand raising tool.
  • There have been 5 resolutions proposed for the meeting. Three to approve each subcommittee section of the report, one to approve the report as a whole for final editing, and one to recognize the importance of the innovation class and to emphasis that to the EAC. At this meeting, Helen Purcell proposed a sixth resolution to thank Dr. Jeffrey for his participation and leadership of the TGDC.

VVSG Review (John Wack):

John Wack gave a high level review of the VVSG (http://vote.nist.gov/VVSG-0807/).

Some points of interest:

  • The report used to be divided into 6 volumes - it has been changed and divided into parts.
  • There has been continued confusion over the glossary - the name has been changed to reflect that these are words with special meaning in the VVSG specifically.
  • The VVSG now contains a complete table of all the requirements at the beginning of the document.
  • The "Introduction" is a work in progress. It is an introduction to the document about what it contains, about what's changed since last iteration, about what the foundation is we're building on. We're hoping the report can accommodate change.
  • Figure 2-2 in the intro shows the importance of the requirement on IVVR for SI.
  • Part 1 of the document is devoted to requirements for devices. John explained the class structure in detail. This is also the section that covers SI and IVVR.
  • John suggested that reading Chapter 3 regarding the benchmarks would be helpful to committee members since Whitney Quesenbery will be discussing at plenary. Sharon L. pointed out that most requirements have already been discussed at previous meetings.
  • The remainder of the chapters in Part 1 were discussed in high level detail
  • Part 2 of the document is devoted to requirements for documentation, how the devices need to be documented.
  • Chapter 2 of part 2 are vendor requirements.
  • Part 3 is for testing requirements. It contains only testing related requirements - it doesn't contain requirements on how to test a system.
  • Chapter 5 contains the information on Open Ended Vulnerability Testing (OEVT).

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.
EAC plans to have the document publicly reviewed in two phases. It will be posted after TGDC delivers to EAC for 120 day comment period. These comments will be reviewed and the document revised. EAC will then release their version of the report for another 120 day review period. EAC plans to take their time with the review process in order to deliver a valuable report.

 

Teleconferences from 200420052006 and upcoming in 2006.
 

*************

Technical Guidelines Development Committee (TGDC)
Security and Transparency Subcommittee (STS) Teleconference *
August 7, 2007, 10:30 a.m.
Draft Minutes

Agenda

1) Administrative Updates
2) Preparations for the TGDC meeting on August 17th
3) Other items
4) Next call August 14, 2007 at 10:30AM

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:

  • IEEE has nominates Sem Kaner as their representative to the TGDC.
  • Preparations for the August 17th plenary are moving along.
  • Dr. William Jeffrey has announced his departure of NIST for September 3, 2007 - he will chair the plenary meeting.
  • The meeting web page is up <http://vote.nist.gov/TGDC/TGDCmeeting081707.htm>. A CD with meeting material and the current VVSG will be mailed 8/9 Fed Ex. The plenary meeting will start at 11:30 a.m. ET on 8/17. Same procedures will be followed as planned for July 3rd meeting.
  • John W: There are lots of updates to the VVSG. We have received comments from NAS and NASED - they are unhappy with how the VVSG is written; they feel it is difficult to understand. [Although it is intended for manufacturers and test labs it is important that everyone can follow it.] We are working to clarify by writing better introductions and making requirements clearer.
  • John W: Will be calling Paul Miller s - would like election officials input in what they expect to get out of the document.
  • John W: We are re-wording the Access Control section of the VVSG - changing the requirements that begin "If possible by the voting system architecture.."
  • John W: We are working to clarify the IVVR section, there is still lots of confusion about the requirements for VVPR.
  • John W: All security sections have been revised in the VVSG to combine into fewer chapters.
  • John W: A change document will be put out for the VVSG- changes noted from previous versions. Most changes still coming will be technical edits.
  • Allan and John have been working on an Executive Summary/Supplementary Document with a spreadsheet that maps each requirement to applicable resolutions and a reference source (whether it's a new requirement or carried over from previous VVSG/VSS or federal standard). They will have this out as soon as possible.
  • Mat Masterson inquired about the approval process of the VVSG at the meeting - Allan stated that it would be approved by subcommittee sections. (The document will be approved by subcommittee sections as in the past.)
  • Mat also inquired about the approval process for the innovation class white paper - Ron Rivest suggested preparing a resolution to accept the white paper and forward to EAC for consideration (emphasizing the importance of innovation).
  • Allan: NIST will be meeting with the Board of Advisors in October to discuss VVSG.
  • Patrick Gannon brought up questions regarding the changes to the Electronic Records section. John Kelsey noted the important changes to this section:, primarily it was revised to remove duplication of requirements covered in the cryptography and reporting requirements sections and to clean up terminology.
  • The next STS teleconference scheduled for August 14 will be to go over the VVSG in brief. All TGDC members will be invited to participate.
     
Teleconferences from 200420052006 and upcoming in 2006.

*************

Technical Guidelines Development Committee (TGDC)
Security and Transparency Subcommittee (STS) Teleconference *
July 24, 2007, 10:30 a.m.
Draft Minutes

Agenda

1) Administrative Updates
2) Discussion of Independent Voter Verifiable Record (IVVR) Requirements
3) Other items

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):

  • Allan forwarded to STS subcommittee a website containing the results from the NJ Institute of Technology's series of extensive tests on printers for Sequoia and Avante http://www.state.nj.us/lps/elections/reports-njit.html . (The website also contains response from Sequoia.) The tests shows issues with VVPAT and other security problems - interesting read for STS members.

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.

  • The PCOS and VVPAT sections were reviewed and updated to contain necessary changes for the IVVR.
  • A requirement was added that "No Codebook Required to Interpret IVVR" -- The human-readable information on the IVVR SHALL NOT require additional information, such as a codebook, lookup table, or other information, to unambiguously determine the cast vote.
  • The requirement on tamper evidence was reworded for clarification.
  • The public format shall not have any kind of intellectual property restrictions.
  • Independent voter records verification - records that voters can verify without software or other technology with the exception of assistive technology.

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:

  • Alexia brought up the confusion between the terms "ballot configuration" versus "ballot style". Style was defined as physical layout and presentation and configuration was defined as the content information. Since there were still concerns over the definition, it will be discussed among Commissioner Davidson, John Wack, and David Flater. [NOTE: Standards Board and others need to understand the definitions so that they understand the material they are reviewing.]
  • Next STS subcommittee is scheduled for August 7, 2007. Presentation materials will be discussed.
 
[* 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 200420052006 and upcoming in 2006.

*************

Technical Guidelines Development Committee (TGDC)
Security and Transparency Subcommittee* Teleconference
July 17, 2007, 10:30 a.m.

Draft Minutes

Agenda

1) Administrative Updates

2) Discussion of open ended vulnerability testing (OEVT) (Background material: see below)

3) Other items

4) Next call July 24, 2007 at 10:30AM
 

Attendees:  Allan Eustis, Wendy Havens, Ron Rivest, Alicia Clay, Matt Masterson (EAC), Barbara Guttman, Angela Orbaugh, Nelson Hastings, John Kelsey, Quinh Dang, John Wack, Alexia Scott Morrison, Santosh Chokani, Andrew Regenshied,   

Administrative Updates:

·Next TGDC plenary telcon on track for August 17, 2007 beginning at 11:30 EDT.

·Final draft of the VVSG document should available later this week for review.

 

Discussion of open ended vulnerability testing (OEVT) (Ron Rivest):

·RR notes that OEVT document looks good.

·AC summarized David Flater’s issues. OEVT has been used as a test reference along with source code review. 

·The issue was raised of whether OEVT team had to examine various requirements as opposed to setting their own agenda. Test was proposed/suggested to clarify this at the end of the introductory material: “OEVT will generally be conducted in conjunction with or following inspection, functional performance or vulnerability testing driven by test suites.  All aspects of the voting system, devices or use procedures may come under the purview of OEVT. However, in some instances, when the primary method of assessing conformance to a requirement is source code review, OEVT is specifically listed as a test reference because it may provide a faster, more efficient, and less expensive alternative.”

·RR : test references left in. AC yes. NH noted that this occurred about five times in the requirements.

·RR puzzled by operational impact of wording. SC noted they are complimentary techniques. AC noted possibility of deleting the word “alternative” and substituting “technique” or “methodology”.

·OEVT team and source code review team can be different groups or, more often, the same evaluation team.

·RR suggested demoting them from test references where appropriate to a discussion field item.

·NH: Original motivation for OEVT method was incongruity of having a requirement with no test reference. JW noted the special case of OEVT that could be explained in discussion field. (This was agreed to by STS teleconference   participants)

· LR made recommendation to avoid language that specified the order of testing.

·RR: OEVT is most often done near the end of the process.

·Discussion ensued on configuration of voting system for testing versus elections. MM had question on “re-configuration” and whether this changed the voting system submitted for certification? RR noted that it meant setting up for different elections. That would probably be in scope whereas disabling controls would require clearance.

·AC noted that rules of engagement for OEVT team are included in the requirements.

·Discussion of mock elections as part of testing ensued.  JW noted that volume testing is in effect a mock election. All agreed this needs to be spelled out more clearly- including size of volume test. RR  brought up possibility of a small realistic mock election. BG noted that inspection and set up requirements may accomplish this.

·MM brought up need for clear definition of “plausible description” and “plausible analysis” in 1.1.2.g. RR noted that bright defining line is not possible here. AC noted that someone will have to sit in judgment. Discussion ensued on defense in depth as an example. MM noted that EAC will need guidance here. RR noted that a definition for plausible threat could include number of individuals required to exploit vulnerability.

·AC will come up with draft text for “plausible definition and will circulate to STS via e-mail for review. RR noted criteria for failure  is at the VSTL level. MM pointed out that VSTL’s do not like to make judgment calls.

·RR indicated that perhaps NISt could produce guidance documents for VSTLs in this and associated requirements.

Topics for upcoming STS calls (Alicia Clay):

·Will review IVVR  next Tuesday at STS Teleconference.

Next STS meeting is scheduled for Tuesday, July 17th.  The discussion will be on OEVT.

Meeting adjourned at 11:22.

[* 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.]

***********

Technical Guidelines Development Committee (TGDC)
Security and Transparency Subcommittee* Teleconference
July 10, 2007, 10:30 a.m.

Draft Minutes

Agenda

1) Administrative Updates
2) Discussion of SI and VVPR requirements (background material below)
3) Topics for upcoming STS calls
4) Other items

5) Next STS call Tuesday, June 26th at 10:30AM.

Attendees:  Allan Eustis, Wendy Havens, Whitney Quesenbery. Ron Rivest, Alicia Clay, Sharon Laskowski, Matt Masterson (EAC), Commissioner Donetta Davidson (EAC), Barbara Guttman, Angela Orbaugh, Nelson Hastings, Bill Burr, Nelson Hastings, John Kelsey, Quinh Dang, David Wagner, Helen Purcell, John Wack.

Administrative Updates:

·July 3, 2007 TGDC plenary teleconference has been rescheduled for August 17, 2007 beginning at 11:30 EDT. The extra time will allow NIST to review the HF benchmark data for accuracy and completeness. Planed edits to the HF Report and reviews by additional researchers should make the data understandable and relevant to the election community.

·The final VVSG draft document should be out to TGDC members in early August. We are making final changes by July 20, 2007.

Discussion of SI and VVPR requirements (Ron Rivest):

·Use of paper records or IVVR records. Recommendation to elevate requirements to be more general than just applying to paper. WQ explained: paper is just a specific implementation. Everything else about SI requirements is results or goals (must be useful for auditing etc.) Making it VVPR is a serious implementation limitation and causes many accessibility problems.

·BG commended for synthesizing issues (See below). Looking for performance standards versus design standards.

·Not many examples evident of SI that would not be paper and not in the innovation class.

·BG reviewed her approach: to look at the essence of SI without limiting the choices to paper. What is it we are trying to accomplish with SI in a technology-independent manner? (She reviewed SI and IVVR requirements. See 1.2A and B below). Election officials must be able to review without technology.

·Discussion of durability, privacy and tamper evident requirements.

·HP question- How does this support innovation unless it is in the innovation section?

·BG: Systems using innovation an be classified into two bins: (1) Using a security architecture  envisioned here with count and method for auditing count, and (2) voting systems such as cryptographic based systems. (These go through innovation class review). 

·If someone comes up with a better way of “doing paper” that is more accessible or usable, then we allow for it in (1) assuming the capability of an independent audit.

·HP- this is hard to understand because there is still no defined system as an example.

·RR: is there a clear process for vendors to decider how his/her system should be evaluated (IVVR or innovation class)? BG: Yes can they meet IVVR is the threshold.

·RR posed questions on chapters 2.2 and 2.3. Proposed that all of the requirements in 2.3 get added to 2.2 with slight rewordings to make them refer to IVVR instead of paper. Most of them have to do with information content instead of paper. BG will go through and extrapolate the requirements up. DW agrees. Same issues apply to all systems.

·JK: auditing requirements specific to paper in 2.2. and 2.3 are specific to cut sheet or paper roll systems. One concern is experience of community with paper based voting systems. We may miss some important requirements when we try to map the paper requirements onto all systems.

·BG: Some risk but paper has drawbacks. DW: The drawback is using a physical medium. BG: Accessibility problems will cross into any print media.

·JK: We know limitations of paper and can write requirements to address these.

·WQ: Some of the attempts (requirements’) to address the paper limitations have violated other requirements. Solution creates more problems.

·Discussion of OEVT, durability and security assumptions. Review of tamper evident requirement.

·BG: Will also go through chapters 2.4 and 2.5 to elevate all requirements not tied to a specific technology. RR: Would like to hear from HF on the suggested changes once they are made- probably the end of next week.

·DW pointed out risk of leaving in an inadvertent loop hole. We need to read carefully, for example to pertain to the same record for each requirement.  BG: Everyone should circulate these examples on the STS list.

·AC: OEVT will not catch all loop holes but with new innovative systems, can we require additional OEVT? DW: OEVT is not right tool because it only catches demonstrable vulnerabilities.

·WQ: In last three elections, the major problems have been the result of design flaws.

·Further discussion of OEVT. DW noted example of not finding voting system vulnerability in time allotted to OEVT testers. The vulnerability may still exist even though it was not demonstrated. We need to scrutinize requirements carefully.

·RR: Some burden on vendors for OEVT with new technology assuring they have done due diligence in security areas.

·RR: Good direction to elevate requirements to IVVR but it needs to be done carefully and well.

·MM: What are other pending topics for resolution by STS. RR: This is the main one and OEVT

·Will have an FAQ for OEVT white paper by August 17h meeting.

Topics for upcoming STS calls (Alicia Clay):

·Will review OEVT next Tuesday at STS Teleconference.

Next STS meeting is scheduled for Tuesday, July 17th.  The discussion will be on OEVT.

Meeting adjourned at 11:22.

[* 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.]

****************

Technical Guidelines Development Committee (TGDC)
Security and Transparency Subcommittee (STS) Teleconference *
June 26, 2007, 10:30 a.m.
Draft Minutes

Agenda

1) Administrative Updates
2) Review for TGDC meeting
3) Discussion of open ended vulnerability testing
4) Other items

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:

  • Allan: The meeting material for the July 3rd plenary has been posted on the web, sent via email, and fedexed on CDs.
  • Allan: The draft VVSG has been posted on the web in final format, and CDs containing the VVSG have been sent to TGDC members.
  • Allan: We will be using a "hand raising" internet software tool (see: http://teitac.org/tohru/ ) for questions and comments during the plenary meeting. Instructions have been provided to TGDC members. If internet access is unavailable to any member during the meeting, please speak up.
  • Allan: Sections of the VVSG will be presented by subcommittee at the July 3rd meeting.
  • Nelson: The plan for the STS subcommittee presentation at the plenary meeting is to go through each section and point out major changes. There will also be a discussion on OEVT and Software Independence.
  • Nelson will be presenting STS material at the June 29th HFP teleconference - HFP is interested specifically the sections on VVPR, electronic records, and auditing. Nelson will forward HFP's agenda to STS when it is available.

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:

  • Why three experts? Requirements were written based on review of other teams set up to do similar work. One to two people are not enough, large numbers cause communication problems.
  • Can we provide more guidance on the expertise of team members requirement? The requirements, as written, call for a minimal level of experience. It was decided to reference requirements done for other "penetration teams". Team members will be chosen based on experience, professional reputation, and previous "red team" experience if any.
  • Cost - how do we justify? The cost was derived by the level of effort needed to do credible OEVT testing - level of effort, number of weeks needed. David Wagner described the level of effort in a high level overview - there are three steps: 1) documentation review and understanding system architecture, 2) architectural level analysis to understand where critical security risks are, and 3) narrowly targeted investigations of specific parts of the architecture as guided by analysis and documentation review.
  • Has this been done in any states already?

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:

  • There is a pre-draft document circulating around on Independent Voter Verifiable Records. This will be discussed in more detail after the June 29th HFP meeting.
  • VVPR and SI requirements were added to the Conformance Clause for those wishing to review.
  • REMINDER: Anyone wishing to attend the June 29th HFP meeting on Friday to go over STS material is welcome.
 
[* 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 200420052006 and upcoming in 2006.

*************

Technical Guidelines Development Committee (TGDC)
Security and Transparency Subcommittee (STS) Teleconference *
June 19, 2007, 10:30 a.m.
Draft Minutes

Agenda

1) Administrative Updates
2) Discussion of Security and Audit Architecture Requirements (including electronic and paper record requirements)
3) Other items
4) Next STS call Tuesday, June 26th at 10:30AM.

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:

  • A web page containing information for the upcoming plenary teleconference has been started. A draft agenda for the 7/3 telcon will be posted later today. There is a current version of the VVSG posted, it will be updated with more current versions when they are available. The plenary telcon meeting is scheduled to begin at 11:30 EDT on July 3rd.

Update on Security Chapters (Nelson Hastings):

  • Physical Security, Cryptography, and Communications Requirements: have been sent to John Wack for incorporation into the VVSG.
  • Access Control: Nelson is reading to check the scope, will send to STS within the next day
  • System Event Logging: Nelson forwarding to STS with the next day
  • Software Distribution and Software Installation: this section has gone through a major rework. Some requirements have been moved to volume 5. The chapter has been refocused on just software installation.
  • Setup Validation: section rescoped. Nelson in the process of editing.
  • OEVT: in the process of creating new requirements, it will be send out on Wednesday this week and will be discussed at next Tuesday's STS meeting.
  • Documentation requirements in each of these sections have been moved to the Security Documentation section.
  • Please get comments in soon, after Friday's build of the document it will not be logistically possible to do much major editing.

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 200420052006 and upcoming in 2006.

******************************

Technical Guidelines Development Committee (TGDC)
Security and Transparency Subcommittee (STS) Teleconference *
June 12, 2007, 10:30 a.m.
Minutes

Draft Agenda

1) Administrative Updates
2) Discussion of e-poll book requirements.
3) Discussion of open ended vulnerability testing (OEVT) and the VVSG.
4) Discussion of STS members comments on VVSG chapters. (Background material: see http://vote.nist.gov/TGDC/member-comments.htm
5) Other items
6) Next STS call Tuesday, June 19th at 10:30AM.

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:

  • Comments on the VVSG from OASIS were circulated and posted on the public web site.
  • We have received comments on the VVSG draft from a few TGDC members to date. if you would like to submit comments, please do so asap (by COB 15). Cut off for implementing major comments will be June 22.

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:

OEVT Failure Criteria: It was decided that Ron's criteria for failure "A voting system SHALL fail the OEVT if the OEVT examination team determines that during an election (1) any single person can cause a violation of a voting system security goal (e.g. integrity of election results, privacy of the voter, availability of the voting system), assuming that all other parties follow procedures appropriate for their roles as specified in the vendor documentation, OR (2) the vendor's documentation fails to adequately describe: (a) the potential vulnerabilities of the voting system (e.g. as given for example in the Brennan Center report [cite]), and (b) the security mechanisms or procedures that serve as countermeasures to these vulnerabilities in the submitted voting system." be included as well as a list of examples.

OEVT Network Priorities: It was decided that this should be moved up as an example under Focus of OEVT.

OEVT Team Resource: Add requirement that team will be provided with tools and instructions to perform a build from the source code - everything necessary to conduct a thorough investigation, and be specific.

OEVT Team Establishment: The team expertise requirement should be moved up into the actual requirement and become a "shall". The team shall consist of 3 security experts and 1 election management expert. Remove the mention of a cryptography expert.

OEVT Level of Effort - Test Plan: Delete the requirement about "flaw hyposthesis", this language is too premature.

Commitment of Resources: Change level of commitment. It was decided on 12 staff weeks. Amount of time will be defined by budget constraints and issues.

[NOTE: OEVT should not be used for quality assurance (QA) by the vendor. This is not the intended use by the testing labs. OEVT is not comprehensive; it will not find all vulnerabilities. If three major flaws are discovered, there are probably more that weren't discovered. If a system fails OEVT testing and is re-submitted, it will have to go back through the other testing, e.g., usability testing, as well. It will be very expensive on a vendor to fail - systems should not be failed on trivial matters.]

OEVT Reporting Requirement: No changes.

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.

[Rivest Proposed OEVT Requirement
 
Here is a proposed draft requirement for OEVT:

A voting system SHALL fail the OEVT if the OEVT examination team determines that during an election

(1) any single person can cause a violation of a voting system security goal (e.g. integrity of election results, privacy of the voter, availability of the voting system), + assuming that all other parties follow procedures appropriate for their roles as specified + in the vendor documentation,

OR

(2) the vendor's documentation fails to adequately describe: (a) the potential vulnerabilities of the voting system (e.g. as given for example in the Brennan Center report [cite]), and + (b) the security mechanisms or procedures that serve as countermeasures to these vulnerabilities in the submitted voting system]

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 200420052006 and upcoming in 2006.

********************

<

Technical Guidelines Development Committee (TGDC)
Security and Transparency Subcommittee (STS) Teleconference *
June 5, 2007, 10:30 a.m.
Minutes

Draft Agenda

1) Administrative Updates
2) Review of the TGDC meeting
3) Discussion of Communication requirements
4) Discussion of System Integrity Management requirements
5) Discussion of Setup Validation using an external device
6) Other items
7) Next STS call Tuesday, June 12th at 10:30AM.

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:

  • John Wack:  We are consolidating TGDC member comments to the VVSG chapters.   The subcommittees are tracking appropriate comments and processing.  At the end we should have a good explanation about how each comment was handled.
  • Allan:  Public comments are posted on the web http://vote.nist.gov/.  Please review.
  • Allan:  We are proceeding ahead for the July 3 plenary teleconference (Tentative start 11:30 am EDT.)

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:

  • Ron had minor comments: using the term “as necessary” might be too vague.  Cryptography checks are not defined – what are you talking about with integrity protection – setup requirements are needed.
  • David W: When talking about physical security requirements (1.2.1), it should be clearly stated that there are only two allowed scenarios for externally networking on Election Day and spell them out here.
  • Patrick Gannon: Concerned that the section that limits to one active interface is too restrictive.  Nelson to review/rework.
  • Ron: The phrase about preventing inbound and outbound attacks needs to be reworded because we can’t prevent these attacks.

Next Meeting:

  • Tuesday, June 12, 2007
  • Topics to include:  epollbooks, OEVT, and uncertain/difficult requirements

Other:

  • Ron agreed with comments sent in by David Wagner regarding Volume 5 and making sure the tests match the requirements being written.  Barbara pointed out that volume 5 is meant to be the testing infrastructure, there is still a lot of work to be done for creating the tests after the standards are written.
  • John Wack sent out a paper on ballot activation requirements, please provide feedback before the next STS meeting.

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 200420052006 and upcoming in 2006.

 

*************

Technical Guidelines Development Committee (TGDC)
Security and Transparency Subcommittee (STS) Teleconference *
May 29, 2007, 10:30 a.m.
Minutes

Draft Agenda

1) Administrative Updates
2) Review of TGDC Plenary Meeting
3) Discussion of Voter Verification - Ron Rivest
4) Discussion of Software Distribution and Installation Requirements
5) Other items
6) Next STS Teleconference - Tuesday, June 5, 2007

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:

  • Plans for the upcoming TGDC plenary teleconference are underway.  We’re looking at the week of July 2 – most likely the meeting will be on July 3rd.  Allow about 3 hours for the call.  Allan will send out date and time soon.
  • The unofficial closed caption transcripts of the May plenary have been posted.  We have put a rush order in for the official transcripts.

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:

  • E poll books (switching the consensus to allow them to be both networked and ballot activators)
  • Multi-sheet paper ballots (appears these are necessary to allow)
  • Barcodes (OK to use)
  • VVPAT (requiring human readable to also be machine readable)

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 current VVSG requirements should apply to e pollbooks?  It appears that most requirements (except the ones specific to voters) should apply to e pollbooks as well as the voting system.  John Wack will go through the requirements to double check this.

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:

Done:  cryptography; access control; system event logging

Received Direction from STS/Not Completed:  paper records (John K/Sharon L – human readable w/out auxiliary information); physical security; software distribution and installation; security documentation; innovation class; text on OEVT; electronic records

Done but No Feedback from STS: audit strategy

Items Still Need to be Circulated: system integrity management; communications

Need Direction:  setup validation

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 200420052006 and upcoming in 2006.

 

*************

*************

Technical Guidelines Development Committee (TGDC)
Security and Transparency Subcommittee (STS) Teleconference *
May 15, 2007, 10:30 a.m.
Minutes

Draft Agenda

1) Administrative Updates
2) Review of presentations for the TGDC meeting
3) Continuation of discussion on auditing, electronic records, and paper records requirements
4) Continuation of path forward discussion for open ended vulnerability testing (OEVT)
5) Other items
6) Future STS call schedule

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:

  • The new (near final) agenda for the plenary meeting will be sent out today. Presentations are due Wednesday afternoon and will be sent to subcommittee when we have them in. John reviewed the agenda for the meeting which will start with a high level overview of the structure of the VVSG. Subcommittee presentation will go CRT, HFP, then STS. The meeting may need to be extended and the schedule flexible.
  • Nelson went over STS's plan for presentation. Bill Burr will give a high level overview of security efforts, John Wack will talk about epollbooks, and Nelson will cover specifics on cryptography, setup validation, and highlight the new chapters as well as changes to the other chapters. Bill's overview will cover requirements for auditing electronic and paper records.

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 200420052006 and upcoming in 2006.

 

*************

Technical Guidelines Development Committee (TGDC)
Security and Transparency Subcommittee (STS) Teleconference *
May 10, 2007, 11:45 a.m.
Minutes

Draft Agenda

1) Administrative Updates
2) Discussion of audit strategy requirements including electronic and paper record requirements
3) Finalize outstanding issues related to Access Control requirements
4) Other items
5) Next call Thursday, May 15, 2007 at 10:30AM

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):

  • We are in the process of setting up a meeting with the subcommittee chairs and co-chairs and the EAC for next Thursday.
  • At the STS meeting next week, we need to discuss future teleconference schedule.

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.
Cast vote record correspondence. Some states require a link between electronic records and paper records and some states completely forbid this link. Requirements were written to make sure machines supported this but were able to turn it off.

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.
Any comments should be sent to John Kelsey via email.

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 200420052006 and upcoming in 2006.

*************

 

Technical Guidelines Development Committee (TGDC)
Teleconference for
Security and Transparency Subcommittee*
May 8, 2007, 10:30 a.m.
Draft Minutes

Draft Agenda

1) Administrative Updates
2) Report on EAC Cost of Testing Summit
3) Finalize outstanding issues related to Access Control requirements
4) Discussion of path forward for open ended vulnerability testing (OEVT)
5) Discussion of requirements from Volume 3, 11.6 "Interoperability" and Volume 4, 2.4.9.2 "Interface description" including EML
6) Other items
7) Next call Thursday, May 10, 2007 at 11:45AM

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:

  • David Wagner and Mark Skall testified at a House Oversight Committee hearing yesterday (5/7/07). David's testimony available at: http://www.cs.berkeley.edu/~daw/papers/testimony-oversight07.pdf. Mark's is posted at: http://vote.nist.gov/speeches/Skalltestimony.pdf. (David W: The main topic of discussion was the certification process; standards were also discussed as well as the state of New York's problems.)
  • We have a draft agenda for the plenary meeting that will go out today. The agenda is fluid, but schedules have been set for subcommittee presentations. It will be posted on line <http://vote.nist.gov/TGDC/TGDCmeeting052107.htm> with other meeting material. This is an important plenary meeting - probably last one before report becomes final.
  • John Wack is trying to arrange a subcommittee chair meeting. Will send out information soon.
  • Patrick Gannon requested that item 5 on the STS agenda be moved up on the agenda today.

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:

1. Group felt that there needed to be a gap analysis done between what the states are required to test and what the Federal government tests - there appears to be duplication. Group felt more testing done by Federal, as to reduce costs on states.
 
2. Group had concerns over current state of source code review and source code testing. Will requirements change in next iteration of VVSG. Mat believed the VVSG would get a lot of feedback on the sections regarding source codes.
[NOTE: David Flater pointed out that these issues were addressed in new VVSG. It was suggested that there be a cross reference of version 05 to new version. There will be a guide pointed out new items and major changes.]
 

3. It was suggested that there be cooperative agreements between states for testing to help reduce costs - smaller states working together to conduct their tests. This was discussed at a general level - there may be an upcoming conference to discuss this in better detail.

 

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 200420052006 and upcoming in 2006.

*************

 

Technical Guidelines Development Committee (TGDC)
Joint Teleconference with
Security and Transparency Subcommittee*
Core Requirements and Testing
Human Factors and Privacy
April 24, 2007, 10:30 a.m.
Draft Minutes

Draft Agenda

1) Administrative Updates
2) Discussion of e-poll books and the VVSG (Background material: To Be Distributed)
3) Other items
4) Next STS call Tuesday, May 1, 2007 at 10:30AM

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):

  • We have received and posted the official transcripts from the March plenary meeting. There was a gap in between tapes that left out a discussion by Alan Goldfine and David Flater regarding the ISO 9000/9001 Quality Assurance/Configuration Management. This section was important because a decision was reached for alternative wording on a requirement. This gap has been filled with an addendum that has also been posted.

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 200420052006 and upcoming in 2006.

*************

 

Technical Guidelines Development Committee (TGDC)
Security and Transparency Subcommittee (STS) Teleconference *
April 17, 2007, 10:30 a.m.
Minutes

Draft Agenda

1) Administrative Updates
2) Discussion of path forward for innovation class requirements (Background material: conformance clause (Conformance clause.pdf) and volume containing standards on data to be provided (Volume 4.pdf) of the VVSG)
3) Other items
4) Next call Tuesday, April 24, 2007 at 10:30AM - Joint call with HFP and CRT to discuss e-poll books

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):

  • Next week at the Swiss Embassy there is a symposium on e-voting cosponsored by MIT-CalTech. Number of NIST trying to go. Allan will send out the agenda to anyone interested. The main subject appears to be on remote access voting.
  • EAC is sponsoring a "Cost of Testing" workshop in Denver April 30-May 1, to discuss the cost of testing machines now and in the future.
  • There will be a continued joint discussion on epoll books at the April 24th STS teleconference.

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:

1) barcodes,
2) setup validation and access control,
3) integrity management chapter,
4) EML,
5) OEVT,
6) How to implement TGDC resolution on accessibility read back for other devices other than DREs, such as opscans and EBMs,
7) decide which topics need to be discussed with other subcommittees.

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 200420052006 and upcoming in 2006.

*************

 

Technical Guidelines Development Committee (TGDC)
Security and Transparency Subcommittee (STS) Teleconference *
April 10, 2007, 10:30 a.m.
Minutes

Agenda:

1) Administrative Updates
2) Continue discussion of path forward for e-poll book requirements
3) Discussion of path forward for innovation class requirements
4) Other items
5) Next call Tuesday, April 17, 2007 at 10:30AM


Attendees: Allan Eustis, Angela Orbaugh, Barbara Guttman, Bill Burr, David Wagner, Helen Purcell, John Crickenberger (NVLAP), John Kelsey, John Wack, Mat Masterson (EAC), Nelson Hastings, Patrick Gannon, Quynh Dang, Rene Peralta, Ron Rivest, Santosh Chokani, Wendy Havens

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:

  • Should ballot activators be networked outside polling place?
  • Should ballot activation by e poll books be permitted?
  • What safeguards are needed?

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 200420052006 and upcoming in 2006.

 

*************

Technical Guidelines Development Committee (TGDC)
Security and Transparency Subcommittee (STS) Teleconference *
April 3, 2007, 10:30 a.m.
Minutes

Draft Agenda

1) Administrative Updates
2) Review of TGDC meeting
3) Discussion of path forward for e-poll book requirements
4) Other items

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:

  • Allan: We are moving forward with preparations for the next plenary meeting, scheduled for May 21-22, 2007. The March meeting web cast has been archived on the web for viewing (http://origin.eastbaymedia.com/~nist/html/tgdc-0307/) . Unofficial transcripts are also posted; official ones will be up soon. The two resolutions that were approved have also been posted (http://vote.nist.gov/meeting20070322.htm) .
  • John Wack: Next plenary meeting will focus on a review of draft sections of the VVSG currently being worked on.
  • Ron Rivest commented that plenary meeting went well.


E-Poll Book Requirements:

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.

  • Not allowing external networking from e-poll book if used for ballot activation.
  • If external networking is allowed, then we need to write requirement, specifically saying this. Currently the voting system definition does not allow for voting system to be externally networked, but if e-poll book is used for ballot activation it becomes part of the voting system, so requirement would need to be changed to allow this.
  • Use smart card for ballot activation with limited memory so there would not be room on it to transfer any data from voting system back to e-poll book.
  • Use of mag-stripes to activate ballots.

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 200420052006 and upcoming in 2006.

 

*************

 

Security and Transparency Subcommittee (STS) Teleconference*
Tuesday, March 6, 2007, 10:30 a.m.
Minutes

Agenda:

1) Administrative Updates

2) Update on joint HFP-STS conference calls

3) Discussion of auditing strategy
~ Translating software independence into the VVSG
~ One-to-one correspondence between electronic and paper records

4) Discussion of setup validation approaches
~ Non-cryptographic software verification technique requirements for VVSG
~ Acceptable setup validation approaches

5) Preparation for the March 2007 TGDC meeting

6) Other items

7) Next call Tuesday, March 20, 2007 at 10:30 AM EST


Participants: Allan Eustis, Nelson Hastings, John Wack, John Kelsey, David Flater, Sharon Laskowski, Quynh Dang, Bill Burr, Rene Peralta, Angela Orebaugh, Ron Rivest, Donetta Davidson, David Wagner, Matt Masterson, Philip Pearce, Santosh Cahokani, Anoop Singha, Whitney Quesenbery, Patrick Gannon, Wendy Havens

 

1.) Administrative Updates (Allan Eustis/John Wack):

  • AE- Announces the extension of the second day (March 23rd) of the TGDC meeting to 4:30pm; 3/23 will now be a full 8 hr. day; 1st day will consist of each sub-committee's draft section reports and 2nd day will be discussion of "cross-cutting" issues.
  • JW- re March Plenary: Review of Draft Agenda; on Day 2: extended discussion of cross cutting subcommittee issues; usability paper for audits; innovation class; e-poll books.

2) Update on joint HFP-STS conference calls

RR-noted further dialog needed. SL-Revision of SI/Accessibility Approaches continues. Need to agree on firm definitions, alternative approaches and analysis. Then frame which categories allowed.

WQ/RR asked to provide introductory slides before cross cutting discussion here.

JW- "passionate about further focus on usability on paper records; not sure if there has been enough discussion about this issue; need to spend more time on usability aspects; can do more talk over email after meeting if needed; "very important" issue


3) Discussion of auditing strategy

DD- White paper on auditability of paper: need more input from election officials with experience in paper ballots. (Secretary Gale/Nebraska uses paper ballots ).

RR- we need collective recommendations and best practices as first step

JK: has been writing on what you need to do to achieve SI; will want (TGDC) election officials to comment/review; Will reach out to election officials.

WQ/DD/JW/RR: Discussion of wider paper formats for auditing. No best solution; Mistakes by poll workers. VVSG 2005 has requirements for machine readability of paper. There are continuing bar code issues. There are significant advances in OCR technologies. No current elections known to use OCR scanners. With respect to spooled paper, machine counting will likely have to be performed at some stage. There are challenges.

NH/RR/JW/WQ: Should VVSG support machine readability? Yes, already required.

Discussion of One-to-one correspondence between electronic and paper records: RR introduced notion of "audit group of unbounded size (one ballot or 100); to be determined/defined by election officials. Propose requirement to count every ballot in an audit group.

DD- Concerned about ballot type and changes within a precinct; ballots may not be consecutive; most auditing at precinct level. JW noted that unique identifier already required in VVSG 2005. Why do we want to limit further. Can privacy be maintained? RR noted that some states have no requirement for ballot ID. You have flexibility with audit groups of variable size. DD: Cost concerns with varying ballot types. One more step adds to cost.

JW-Some states require unique identifiers; can't replace hand audits; getting paper records that are readable is more important; global requirements for privacy; vendors have some capacity for paper vs. electronic; this does not violate voter privacy

Discussion continued: Smaller audit groups are more usable. Audit groups need to match back to electronic vote. DD questioned whether this was procedural and standards issue. DW questioned what problem are you solving with audit groups?

RR noted trade off points of voter privacy vs. security; motivation here is having audit procedures. JK noted that voting systems must provide capability of one to one audit.

JW noted that there is a global privacy requirement currently in VVSG.

DW concerned that requirement here be objectively testablep; Major concern with privacy here.

DD: Concern with provisional ballots; have to be able to pull ballot ( if not qualifying);sometimes part of ballot's votes qualified; some provisional's are not counted that night (of election). STS should examine how manufacturers currently mark provisional ballots.

Discussion of provisional voting procedures with DREs: Some jurisdictions allow DRE provisional voting. (Number on smart card assigned to voter associated on DRE. Suggest input from Helen Purcell on hand count procedures in Arizona vs. machine count. JW noted example of e-poll books and provisional vote. Concern over what info is transferred to smart card here.

Discussion of voter challenge laws and counting recently-deceased voters; This varies by state.

JW Summary: a) all agree on machine readability requirement. b) biggest security issue- making paper ballot usable.

DW: Focus on precinct based audits. Focus effort on usability; one to one correspondence secondly; prioritize efforts on kind of audits for election officials; summarize hand count This will have carry over.

4) Discussion of setup validation approaches

a) Non cryptographic software verification:

Incorporating SI into VVSG (Approach): With testing, require mock election to be run to test audit capability. (Will discuss this at plenary on Day 2.)

RR noted parallel testing difficult to do. JK-Testing is easier with ballot marking device.

b) Set up validation

Use of digital signature: do we lose this with SI? Prevention before detection

Tricky area: what goes in innovative class? DD- This is an unknown area. RR: yes set up validation new to voting arena; Use more common in gaming/gambling industry.

DW: Referenced discussion in the past on set up validation requirements JW- need to separate set up validation issues more clearly. (a) Narrow classes b) central back office systems, c) election management systems

Discussion of "snapshot " of the voting system capability.

DW leans toward not requiring set up validation with SI except for election management systems.

NH: Forensic analysis required. RR agreed, but also dump of machine state at end of each election.

DD- STS has to explain fully these complex issues with some retrospective so all of election community can understand.

Discussion of networked devices: Access control is area where we need to put effort. RR: need to add public keys as well with code signing.

DD noted that we want to take manufacturers out of set up arena. Will these requirements make this more difficult?

DW: This should be transparent for poll workers.

Other Business: NH- crypto VVSG section updated; will be circulated to STS

7) Next call Tuesday, March 20, 2007 at 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 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 200420052006 and upcoming in 2006.

 

**************

 

Security and Transparency Subcommittee (STS) Teleconference*
Tuesday, February 20, 2007, 10:30 a.m.
Minutes

Agenda:

1. Administrative Update
2. Review of the joint STS-HFP call (minutes of call can be found at http://vote.nist.gov/HFP/HFPteleconnotes020907.htm
3. Update on comments received on access control and system event logging sections
4. Update on modifications to setup validation section
5. Other Items
6. Next joint HFP/STS call Friday February 23, 2007, 11 am.


Next STS call Tuesday, March 6, 2007, 10:30 a.m.

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):

  • John Wack and Allan will be putting together a formal agenda this week for the March 22-23 meeting. Each subcommittee should have approximately 3 hours on the agenda.
  • There will be two workbooks distributed for this plenary meeting, one of which will contain the latest draft of the next iteration of the VVSG. It will also be posted on the website before the meeting.
  • Welcome to Mat Masterson from EAC. Mat will be the liaison between EAC and the TGDC subcommittees, keeping the lines of communication open.

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:

  • Should voting systems have administrator login and different accounts on the system? The system must have some kind of root capability, which must be tightly controlled. Access control policy would be role and identity based.
  • Should the access control policy be fixed or can you customize it to allow more privileges and change roles? Ron Rivest felt it should be fixed, but noted that there was a possibility that state law may require flexibility. Nelson had suggested writing minimum requirements regarding roles and not mentioning customization. There was discussion about whether or not this would work. Nelson will redo this section.
  • Should voting machines store logs from previous elections? This comes from requirements regarding managing logs and rolling off (deleting) logs when the storage gets full. States require capability to keep previous election records (paper) for 22 months. Is the data copied or erased? (Machines in Arizona are erased after elections. Back up records are kept.) Good model is dumping data onto once writable CDs. Is there a requirement for writeable media in the voting system?

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.


[* 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 200420052006 and upcoming in 2006.

*************

 

Security and Transparency Subcommittee (STS) Conference Call *
February 6, 2007

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:

1) Administrative Updates

2) Discussion of cross sub-committee topics

a. For HFP; prepare for the HFP-STS joint conference call on usability and software independence.
b. For CRT; the proposed CRT approach to COTS (see paper entitled COTS discussion paper" at: (http://vote.nist.gov/TGDC/crt/COTS-20061016/COTS-20061016.pdf )

3) Discussion of software independence impact on setup validation requirements (see paper entitled "Impact of software independence on set up validation requirements" at: http://vote.nist.gov/TGDC/sts/Potential-impact-of-SI-on-setup-validation-requirements-012507.pdf )

4) Other items

5) Next call Tuesday, February 20, 2007 @ 10:30 AM EST

Administrative Updates:

  • Allan: Tomorrow is the first of two/three hearings that the Senate Rules Committee will be conducting on Electronic Voting Technology. Rush Holt will be a witness followed by a panel with Rush Holt, Brit Williams, Connie Schmidt, and a representative from the Brennan Center. (Testimony is available at: http://rules.senate.gov/hearings/2007/020707hrg.htm )
  • Allan: Reminder that on Friday, February 9, 2007, there is a joint teleconference call with the HFP (11 am EST).
  • John W: Thanks to David Wagner for email with pointers to best practices and procedures; also received some from other voting vendors.
  • John W: At the next teleconference we need to discuss how our draft requirements are presented. (seems there is some divide on how it should be presented) [Nelson noted that comments will be looked at this week. Bring back to mailing list for follow-up discussion.]

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).


Interoperability

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.
Need to prioritize the risks from viruses (exposure). Networked systems and PCM/CIA cards are high risk. When a voting system accumulates votes with one machine, there is a high risk for viruses and you would then require an external port. There is a spectrum here in voting systems- not black and white. Also discussion followed on indirect communication between systems.

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 200420052006 and upcoming in 2006.

*************

Security and Transparency Subcommittee (STS) Conference Call *
January 23, 2007

Agenda:

1) Administrative Updates
2) Discussion of software independence on Access Control and System Event Logging requirements
3) Discussion of security related topics for other subcommittees
4) Discussion of innovation class - overview, high level requirements
5) Other Items
6) Next call Tuesday, February 6, 2007 at 10:30AM.

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):

  • Board of Advisors Meeting today (1/24/07) – John Wack is giving a presentation on the status of the VVSG – similar to the presentation given at the Election Center last week. A panel discussion will take place after his presentation – this panel consists of several TGDC members and will be looking at usability and accessibility issues.
  • Last week NIST/NVLAP recommended to EAC two initial labs that were compliant with our ISO standard (17025) – iBeta and SysTest. The reports have been posted on the web. Allan has since received calls from two additional labs interested in applying.
  • Allan also posted some state regulations regarding DRE audit procedures.

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.

ACTION: STS subcommittee should review both the access control document and the event logging document and provide comments to the STS mailing list. The access control document will be considered ready for TGDC review, the event logging document will be brought up at a future STS subcommittee meeting.

Discussion of Security Related Topics for Other Subcommittees:

  • COTS and the impact of software independence on COTS. (see Flater's presentation: http://vote.nist.gov/COTS-20061016.pdf.
     
  • Reliability issues with respect to paper records and the reliability of printers. This should be moved to CRT. Nelson will discuss with D. Flater/A. Goldfine.
     
  • Interoperability issues – primarily an export format for cast ballot records. CRT should have the lead, but STS should be involved in to make sure auditing is possible. STS will provide high level requirements to CRT.
     
  • Chain of custody procedures related to electronic records. STS will have the lead but will ask CRT for comments.
     
  • Usability and accessibility of paper, including bar coding, etc. for the blind. (This is our biggest crossover issue.) Nelson and Sharon will schedule a joint STS/HFP meeting. Framework of issues will be provided via email before meeting.
     
  • Usability issues with printers and audit mechanisms. Transfer to HFP. STS will prep HFP on the issues. Consideration on how we deal with auditing records of accessible systems.
     
  • Possible discussion with CRT: OEVT and software distribution.

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.

ACTION: Prepare white paper with details outlining plausible way to organize panel, plausible timeframes, effort levels and scope of responsibilities. Criteria for recommending one way or the other should be provided. Rene Peralta will be contacting Ron Rivest offline regarding this issue. The process can evolve over time.

Next STS teleconference is Tuesday, February 6, 2007, 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 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 200420052006 and upcoming in 2006.

*************

Security and Transparency Subcommittee (STS) Conference Call *
January 9, 2007

Agenda:

1) Administrative Updates
2) Summary and status of STS activities (the summary document will be posted to the STS list before the call)
3) Discussion of security related resolution and impact on security requirements
4) Other Items
5) Next call Tuesday, January 23, 2006 at 10:30 A.M.


Participants: Alicia Clay, Allan Eustis, Angela Orebaugh, Anoop Singhal, Barbara Guttman, Bill Burr, David Flater, Helen Purcell, John Wack, Nelson Hastings, Patrick Gannon, Quynh Dang, Ron Rivest, Santosh Chokhani, Sharon Laskowski, Wendy Havens

Administrative Updates:

Allan Eustis:

  • New disclaimer will be read at the beginning of every telecom. Meetings are formally announced in Federal register. What is said at these meetings is public and welcomes any and all new listeners.
  • New articles and public comments have been placed on the TGDC website.
  • Mark Skall and Allan attended Donetta Davidson's installation as Chief Commission of the EAC. Outgoing chief expects approval of new EAC members in January.
  • Transcripts from the TGDC December 4 and 5 meeting are on web page.
  • Any combined TGDC subcommittee meetings will be worked into current schedule of meetings. New meetings require a couple weeks notice to schedule.

John Wack:

  • Mark Skall and John spoke at a recent Election Center meeting. Mainly gave an overview of TGDC meeting and resolutions that were passed. Audience zeroed in on software independence and systems with paper trails. Strong objections from listeners were expressed. John stressed that requirements were going to be passed on handling paper. Usability issues were addressed. Vote Here expressed that they have machines that can meet our requirements.
  • John is looking at our progress to date and an overall view of what needs to be done, especially as a result of the SI decision, with the hope of being done in April/May. Should we be less stringent on requirements because of SI?

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.
Profile specific security and audit function overviews and testable requirements: This covers paper record requirements, electronic records requirements and other profile specific requirements. Draft requirements are written for paper records; also an outline and white paper are written for electronic records. John Kelsey is working on overall section with John Wack.
Profile independent testable security requirements: This section is taking the longest, with ten sub sections. Draft requirement written for cryptography; key management under revision; access control, software distribution, system event logging, and setup validation are largely written; system integrity management and physical security have draft requirements under revision. In the process of creating a new security documentation that will be separate. Added section on minimum requirements supporting audits and testing that was not specifically mentioned at TGDC meeting - this is just a placeholder for now - this is a possible place for OEVT discussion.
Voting systems innovation class: We have to come up with high level guiding requirements that would help manufacturers get to certification and a white paper discussing the evaluation process. Draft white paper done on overview. Discussion still active on evaluation process. This is a struggle to develop. Usability requirements in regards to security were discussed. HFP subcommittee is only looking at user interaction requirements. Innovation class design should be discussed among all the subcommittee of the TGDC. Design guidance needs to be addressed as well as performance. Requirements must be flexible - basics need to be met - but we may not foresee all future designs.

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?
 

Where are we in respect to volume testing and running a trial election and a complete audit check? From a usability stand point, this testing would point to "potential" problems. This is more for reliability and performance testing. An entire set of operations for the voting process (including audits) needs to be exercised and examined. Would be nice to see a report from the public's point of view on use of equipment before states purchase.
 
Would be nice to see removal of impediments on new vendors. It is tough for new vendors to sell equipment to states that already use certain vendors.

Caltech/MIT voting project is planning a small brain storming session with academia and vendors to discuss new innovation class (not a public meeting) in March.
 
Testing Documentation: We will be working on this soon. OEVT draft white paper has been prepared. This details how testing labs will test all the equipment.

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:

Tempest: Dutch have de-certified voting machines because of strong tempest releases. Should a standard be written? This is being handed to CRT subcommittee to investigate.
 
Holt Bill: What are the impacts on what we're doing if this is passed? Congressional Hearings will be held in early February to discuss.

Next teleconference - Tuesday, January 23rd at 10:30 a.m. 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 200420052006 and upcoming in 2006.

*************

 

 

Created January 8, 2020, Updated January 16, 2020