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 2004, 2005, 2006 and upcoming in 2006.

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

Link to NIST HAVA Page

Last updated: July 25, 2007
Point of Contact

Privacy policy / security notice / accessibility statement
Disclaimer / FOIA
NIST is an agency of the U.S. Commerce Department