Security and Transparency Teleconference Meeting
Thursday, September 19, 2006 at 10:30AM

Participants: Allan Eustis, Angela Orbaugh, Bill Burr, David Flater, John Kelsey, John Wack, Helen Purcell, Nelson Hastings, Patrick Gannon, Rene Peralta, Rick Kuhn, Ron Rivest, Thelma Allen, Wendy Havens

Agenda:

1) Administrative Updates
2) Updated Cryptography Section;
       -No modifications to requirements but put into VVSG 2007 final format
       -Security documentation example requirements
3) Discussion of Security and Audit Architecture
4) Discussion of Threat Overview
5) Other Items

Meeting commenced at 10:30 a.m.

Administrative Updates:

• Allan worked at the polls last week in DC. Everything went smoothly, mainly because there were no major changes in voting equipment or procedures in DC from the 2004 elections. Voters Still have choices between OpScan and Sequoia DREs. Allan sent out his trip report from his experience in WY. Allan will be going out to Washington state for post election canvassing.
  
  
• Plans are to go to Arizona in November for L & A testing before the election.
  
  
• Rene Peralta went to Washington state for the Logic &Accuracy test. Stated that Seattle was an eye opener. VVPAT was a special case in WA where most voting is by mail. The DREs only require VVPAT, and the DREs are only used for special accessibility. Officials looking for emergency legislation about machines because there is a possibility of confidentiality being breached if only 5 to 6 people use a certain machine.
  
  
• John Wack worked the polls in Montgomery and had a very different experience than Allan. He has sent his comments out to wgvote and Ron Rivest. He will edit and then share with the rest of the TGDC. Voter access card was just a small part of the problem. John didn't like that every DRE has modem that could be connected. Any machine could be made into an accumulator. All the new equipment, including the electronic poll books, could be one of the reasons mistakes were made and the voter access cards weren't delivered.
  
  
• Frederick County, and other western counties, elected not to phone in results. They decided not to do counting at the polls which seemed to cause less hassle. John feels that it might be better to do these things at a central location where election activities are less hectic.
  
  
• John would like to discuss white papers regarding controversial issues that he wants to get in front of the TGDC.
  
  
• Helen would like to hear more about the electronic poll books and the poor manufacturing standards. Helen said that the Arizona primaries went well. Said very few people used the Sequoia Edge DRE equipment. Most problems caused by inexperienced poll workers and problems with new equipment. They did a full hand recount (not certified) of 24 precincts just to have the experience before a general election. Things were much better than expected. All were done by hand, nothing was supplied by Sequoia for the hand count.
  
  
• Allan and John will be attending the AEI-Brookings Election Reform Project on Friday September 22nd from 8:30am - 12:30pm, located at the Wohlstetter Conference Center in Washington D.C. Charles Steward of MIT is one of the panelists. Allan will send around URL for conference. A representative of ESI will be there and they hope to get some good information about how VVPAT systems performed.

Updated Cryptography Section - Nelson Hastings

• Nelson did not make any changes to the text of the requirements; the main reason that he wanted this on the agenda was to show the final format (which is in question). [John - Some things may change on the format, but the structure should remain the same.] Wanted to point out that short titles have been added before requirements. We have a couple of "applies to" fields, as well as a test reference field.
  
  
• Ron: Looks nice. Also source and impact fields? [John W: Source is basically a reference for the requirement. Impact is an internal field saying what is the impact of this requirement to existing technology and existing systems. Not sure this field is necessary.]
  
  
• John W: Usage of glossary terms and how they should be used in the text. In the "requirements" text we should probably link each use of the glossary term to the glossary. Consistency of usage needs to be clear.
  
  
• Nelson: The other thing is about security documentation. Wanted to look at a couple of examples in the cryptography requirements of documentation requirements and see if they meet Ron's expectation. [Ron: Do we have a definition for security services? Nelson - Section 2.1. We need to make sure how those services get used are also discussed. And also about encryption security cards.] Nelson would like Ron to look at this section and let him know if there is anything he feels is not covered in the documentation requirements.
  
  
• Ron: We need to think about what we want the vendor to provide, everything from the declared security objective, policies for the machine, how to configure, what security mechanisms there are and how they work, and then to justify to the evaluator the architecture and the rationale for the machine.
  
  
• Nelson: If it is determined that the security documentation provided in the cryptography document meets our needs, should they be kept in that section or pulled out separately. [Ron: A security document as part of the evaluation package is important. Ron's opinion is that all the security regulations should be done in a larger combined document and refer to other things as necessary. We need to give guidance to vendors about what can be expected as far as structure of the documentation. Not just a list of items that need to be there.]
  
  
• John K: Should there be a section regarding the security documentation with links throughout the document where it states that it imposes this additional documentation? Sections that state what the requirements for the technical documentation are? Throughout should there be statements that say in order to meet the security documentation this is what you need to do? [Ron feels that having the security documentation together might be the right way, but this is open for discussion.]
  
  
• David F: In the outline that we're following, within the chapter on user documentation, there is a distinct section on security documentation requirements where these types of documentation would go. [Ron: User documentation means poll workers, voters, and election officials? David: It means the customer. However it is also included in the technical data package.] With the outline, all requirements could be moved into the chapter on user documentation, and they could be cross referenced with the security requirements section. The security documentation would be a chapter within the user documentation. [Ron: There may be other things regarding security that the user doesn't see, having to do with the internal architecture and the structure of the machine.] Maybe there should be a separate section for the TDP. [John K: Seems like these would be two completely different things for the users and the test labs.] [Ron: There needs to be evaluation to make sure the user is being adequately instructed.]
  
  
• [John W: As far at the documentation that should go to the labs, was there a questionnaire? ] Ron will dig it up and revisit it as a checklist for the vendors, making sure they extend the level of detail we're looking for. The vendor needs to know that the default for the system is insecure and it will only be deemed secured when it goes through all the requirements. The burden of proof is on the vendor for security. Ron will turn this into a better organized list. Maybe we can all generate questions we'd like the vendor to answer.

Threat Overview and Threat Tree

• John K sent around something. We've been looking at outline to see what the components met. We weren't sure what we needed to write, so he took a stab and that is what he sent out. Part 1 is a draft threat overview.
  
  
• We have the Brennan Center report. Is the vision here that we need more into material?
  
  
• JK: We have two sections, the threat overview and the threat tree that are here to set the tone of how we're thinking about the threats at a high level. The big thing John wanted to do with the overview was describe the type of categories of threat we cared about, and how we think about these attacks; what we mean when we talk about an attack on a voting system, who are potential attackers and what kind of budget they have. [Ron: This is just informational for the reader, cluing in the vendor about how each of these threats can be dealt with.] The overview is not normative, neither is the threat tree. There are no "shalls" in the threat tree. [Ron: The benefit is to educate the reader about why the security requirements are there. Some of the requirements may link back to this.] John doesn't have a good intuition how this is all going to fit together.
  
  
• John Wack thinks the introduction of the VVSG would be a good place to put controversial topics because it would be more accessible. This may be a good place to discuss these threats. We at NIST should talk about this before going further.
  
  
• Ron: In terms of writing various security requirements, do we have a policy for tying them to particular threats or providing a justification for the requirements or to the higher level security? John Kelsey does not see the logic of tying each requirement to a threat. John Wack thinks that it might be a good idea to have the introduction state something about how the requirements might prevent certain groups or types of threats. In the discussion field we might be able to do traceability. Thinks doing the introduction this way would be very useful.
  
  
• David F: The same things we're seeing here, could be used on the requirements for the security documentation to require vendors to explain how your system prevents each of these classes of attacks.
  
  
• Ron: We just want to make sure that vendors explicitly considers voter attempts to subvert his own privacy.
  
  
• John K: It's worthwhile to point out these classes of attacks and to go into a little more detail in the attack tree, but concerned about requirements that say demonstrate how you prevent the broad attack of subverting the election. Multiple requirements you want to uphold because they prevent multiple kinds of attacks.

Security and Audit Architecture

• John K: I don't feel like I know what we need to accomplish with this section. This is just a first take to see how others felt. We need to discuss architectural profiles on the different type of voting systems to make sure each piece of the voting process can be audited.
  
  
• David F: One of the first questions to answer is, which kinds of auditing are you concerned with? Not only that the recorded votes were counted correctly but also that the votes that were intended to be cast by the voter were recorded correctly. Some of the specific designs we have only accomplishes one or the other. If you're auditing for all the above, then that will determine your responses. [John K: should audit for the full correctness of the system, so that final vote totals are substantially correct.] Where does ballot accounting fit in? [John K. would expect that to go in this section. They assumed that the poll books were part of the auditing trail. It was disconcerting to see that both the electronic poll books and DREs were from same manufacturer.]
  
  
• John Wack: The electronic poll book that he used wrote to the smart card that activated the ballot. [Ron - they're called voter activation systems]
  
  
• This section is all about auditing even though we divided it into a separate section. Thought the audit section should be about audit longs and audit trails and how to accomplish the auditing technically.

Voting Activities Section:

• David F.: In the outline for VVSG 07, there's one major chapter regarding general requirements that seem to apply globally throughout the voting process. Following is another large division of requirements by activity that goes chronologically throughout election day with requirements that are more specific to the individual activity than the voting process.
  
  
• Ron: You need to divy up type of audit material. You need to organize the auditing section by the information you want to have available after the election to do any kind of checking. [John K: It's not enough to specify the information has to be produced, you also have to specify how its going to be used and make sure the architecture of the voting system supports that.] The high level goal here is to make sure we have some kind of coherent organization discussing the various kinds of auditing that can be done, what the information is that is produced, what the procedures are, how the audit information gets protected.
  
  
• John K: We don't have to specify what the procedures are, but we do have to specify that what they do, like audit this against this.
  
  
• John W: In the threat overview, you'd have to reference various type of audits as addressing some of the threats but was wondering about a section that says these requirements exists to support the following types of audits.

White Papers

• Possibly on VVPAT. Privacy requirement in effect won't permit paper rolls. New VVPAT requirements versus old.
• Possibly another on 8022 wireless.
• John Kelsey has concerns that asking someone to do white papers at this point would be a bit much as everyone already has enough deadlines.
• Group should come up with a list of major controversial items. This will be a dynamic list.

Next scheduled meeting; Tuesday, October 3rd at 10:30-11:30

Meeting adjourns at 11:45

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

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