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 - 2006

Security and Transparency Subcommittee (STS) Conference Call
November 28, 2006


1) Administrative Updates
2) Preview/Review of draft presentations
3) Other Items
4) Next call?

Participants: Allan Eustis, Barbara Guttman, David Wagner, Helen Purcell, John Kelsey, John Wack, Nelson Hastings, Quynh Dang, Ron Rivest, Sharon Laskowski, Wendy Havens

Administrative Updates:

  • Allan: TGDC members should have received the advanced CD for the meeting next week. Some papers will be revised. John Wack will send out new ones, notebook will have the accurate copy.
  • Allan: Sunday night reception will be in Rockville room of the hotel.
  • John W: Wondering if TGDC should be sent an email specifying a "reading list". Ron Rivest to send out email about what STS recommends reading.

Preview/Review of Draft Presentations:

John Wack had suggesting rearranging topics on the agenda.

The current flow of the agenda was captured as follows (discussion points that were addressed regarding each are also included):

  • Curt Barker leads by saying auditing is good - generically that is how we secure systems in the world today;
    [Plans to talk about the auditability of systems from a security perspective, general information about other auditable systems such as financial systems, etc. This will set the stage for the talks that deal specifically with voting systems.]
  • John Wack builds off that - we don't know how to write good requirements for closed box DREs;

    [Concern is that some people on the TGDC will not be happy about banning stand-alone DREs - an aggressive discussion may ensue at the meeting. Going to say that NIST conducted lot of research, did a lot of threat analyses, observed elections, worked with vendors, and NVLAP test labs, and kept coming to same conclusion - people that used VVPR machines were more secure and most resistant to threats. NIST cannot write requirements to make up for lack of audit capabilities in closed box DREs. Not a good direction for VVSG 07. NIST researched IDV, and the goal is to write requirements for paperless software IV systems that are independently auditable.

    Unable to derive general testable requirements. NIST would investigate further, but they would be design specific. Conclusions about VVPR and problems. We should talk about all the work that's being done in STS and CSD, not just the material we determined would be of most interest to the TGDC.]
  • Ron to talk about software independence and innovation class - followed by resolutions;

    [John Wack sent some rough draft slide to Ron last night for the SI presentation. Also sent two draft resolutions. We need a third resolution for wireless - an amendment to an existing resolution. Slides say STS has developed strategy recommending software independence; possible paperless SI approaches; what is software independence; why end-to-end would be premature; and roadmap for new approaches to voting systems (innovation classes). Recommendations need to be built into the 3 hour period. [Recommendation for Resolutions: To write requirements only for SI based systems, innovation classes being implemented, and recommendations to EAC (?). Before the December 4 meeting, John/Ron to ask EAC if they would like resolutions/recommendations that might be useful for talking to Congress.

    We do not know how to do software independence for blind voters. There are lots of classes of disabilities that we do not know how to handle. For typical voters, we want software independent systems. For voters with disabilities, we need flexability. We need reasonable accommodations for voters with disabilities. Verification is a tough one to figure out. [NOTE: Software independence has to do with the auditing of the system, not for the usage of the voter.]

    Procedural defense: We need to have sighted people use the assistive technology and vote and look at their paper record to verify their vote. This gives you the security property you want. VVPAT is ok because it is not the vote of record - there are accessibility problems with VVPAT.
    HFP to discuss changes and additions made to HFP section. Sharon to think in terms of accessibility in the voter verification process. Sharon to include slide on "next steps".

    A good strategy has been developed in how the security work should be approach in the VVSG 07. If the SI stuff goes down in flames, do we have a contingency plan? Yes. If we don't have an agreement from the TGDC on SI, it will not radically change what is being done in security analysis or the IDV.
    We want the TGDC to recommend that NIST work on the SI stuff and write requirements for those.
    What about non-SI systems? If the TGDC says we should write requirements for them, then the burden is on those people to say what kind of approach should be taken.

    What requirements do we write for the current set of DREs if it is recommended we do so.]
  • John Kelsey to discuss audit architecture and IDV - the high level approach to writing a security standard; identifying threats and addressing those threats

    [Building IDV is still a research problem - we're not ready to write standards for it. Point out that problems experienced with paper systems could get better.]
  • Other significant changes - status, wireless with amendment of resolution introduced by Ron, then VVPR, setup validation, electronic record requirements - Nelson
  • Discussion/questions should be expected regarding hardware change requirements

What happens to grand-fathered systems, such as the closed box DREs? This should be discussed at beginning of meeting. It deals with all 3 subcommittees - Mark should discuss at beginning of meeting. There may be objections because people may think that what we have now in the paper machines may be the best we can do - there are lots of improvements that can be made - it needs to be built from the ground up to work appropriately.

The main point of this meeting is to be able to go out and write requirements for VVSG 07.

Presentations will be circulated around to STS members for vetting before meeting.

Other Items:

  • Allan and John recommended new way to do teleconference. Pick issues that would become focus of teleconference, overlapping with two or more subcommittees.
  • Ron Rivest to make phone calls to other TGDC members for preliminary discussions.
  • Next teleconference will be December 19, 2006, at 10:30 a.m.
Action Items:
  • Ron will be writing the next draft of the resolutions for Software Independence.
  • John Wack will be preparing the next draft of the amended wireless resolution.
Teleconferences from 200420052006 and upcoming in 2006.



Security and Transparency Subcommittee (STS) Conference Call
November 21, 2006


1) Administrative Updates
2) SW independent/dependent and innovation class presentation details
3) Final TGDC December meeting agenda for STS
4) Other Items
6) Next call Tuesday, November 28, 2006 at 10:30AM.

Participants: Alicia Clay, Allan Eustis, Angela Orbaugh, Barbara Guttman, Bill Burr, David Wagner, Helen Purcell, John Kelsey, Nelson Hastings, Quynh Dang, Rene Peralta, Ron Rivest, Wendy HAvens

Administrative Updates - Allan Eustis:

  • Draft papers for the December have been posted on the TGDC website. (Some may be modified over the next few days.)
  • There will be hard wire internet capabilities during the December meeting if anybody wants - just send Allan an email request.
  • STS will be first on the agenda for the December 4th meeting, followed by CRT the HFP. Allan has allotted more time to STS and CRT since HFP needed less time. A two hour timeframe has been added on to second day for introduction of resolutions & discussion.

SW Independent/Dependent and Innovation Class Presentation Details - Bill Burr

Plan to advocate developing a process where we can address an innovation class of voting machines that would include end-to-end, and possibly IV, solutions. The reason for a process instead of requirements is that (we) don't feel we're ready to write the kind of requirements that would be used for a test lab process except for very particular designs that would cut off innovation in an area that has hardly begun to develop.

The discussion will be about what that process will look like and when we'll have an outline for it, and who will be responsible for organizing it. This (evaluation panel) depends on experts doing it. There will be a lot of issues how this is put together, panel members - paid, FACA? Who will be motivated to put together a credible proposal and what is our role?

This will be a recommendation put forth. It is an EAC decision to implement and run the panel/group.

The evaluation process demands a high level of expertise. It is important to get a good panel, and this should be discussed. The process from the vendor's point of view: is it a one shot demand to build a credible system with the new innovation or is there an introductory period to get buy-in to a general idea of a new development. Maybe this should be done as a grant process to develop the new technology.

[NOTE: EAC is going to Congress to get authority for certain things like collecting money and assigning it out. Also to assign vendors to certain labs.]

Innovation class evaluation models were discussed: First one looks like an AES competition followed by the FIPS module evaluation. Second model looks like FDA (clinical trial) approval. A couple of states have talked about doing pilots with new systems.

There are costs for the vendors in developing new hardware; and cost for the experts evaluating them. Patents were discussed - if a vendor comes up with new technology, they may want to patent it so other vendors are not able to start with their work. Opinions were expressed that this shouldn't be a competition, but maybe it should be a qualification process.

Question came up about whether there should be a competition for the cryptographic algorithm protocol that the academic could do, and then once appropriate algorithms or protocols from that competition, you let the business community pick up from there.

An interesting discussion on examples, possibilities, and processes for how this would work took place, taking into account some entirely new technology and also changing existing profiles.

The innovation class model may want to be done also at a minor level taking into account machines that were pre-certified but have enough new variations to warrant a review.

We want to keep in mind that we created this innovation class for a specific reason. For the December meeting, we should get agreement from the TGDC that this is a good direction to proceed in and then when the standard comes up for review in four years, we can look into how to expand on the innovation class or how to expand on existing profiles. It still has to be determined if we can lay out a process for the innovation class by July. Consensus seemed to be that it could be done. We need criteria for when the project begins. We have to have barriers for people to enter the grant competition so we only get credible proposals.

Systems would still have to go through ITA/VSTL for testing, but they would have to go through a special security panel to make sure they meet security requirements. There needs to be a review of the design and implementation at some time.

For things where we can write testable requirements, the test labs will be able to evaluate systems. When we get into innovation class, we won't be able to write requirements that are testable, i.e., the crypto protocol or an IV system. [Testing labs hire contractors, and they should be able to hire the experts that could do the evaluations. A lot of pressure is on the manufacturers to do the testing, part of the process is getting independent reviews and tests of new systems.]

For the December meeting we're looking for their approval to proceed in this direction, and we will provide them with a process in VVSG 07. Is the process specified in the standard or separate (in July as well)? There must be a path within the standard that tells you where the process is - we may have to leave some details vague. There should be no mention of possible grants.

We need to start having some substantive discussions with EAC about what should be in the standards and what should be outside the standards. We're looking for buy-in from the TGDC in December and if it goes in the final for VVSG 07 it could be determined that the EAC will work with NIST to come up with the process. STS should draft a resolution for the December meeting saying that TGDC supports the innovation class and asks NIST to develop the process.

STS Agenda Items for December TGDC Meeting

Presenters are still being decided for each section of the agenda.

#1 - Restructuring the security components of VVSG 2007 (very high level discussion) (30 min)

  • New architecture with audit base (paper forthcoming, main piece is about threats)
  • Related, high level testing expectations (will include discussion of OEVT [white paper before meeting] and security documentation)

#2 - Position on SW dependent systems and the innovation class alternative (white paper posted) (90 min)
(Ron and John Wack to decide who's doing what part of the presentations.)

#3 - Significant changes in requirements (60 min)

  • Wireless (may be members that understand and think they need to do wireless, white paper to be posted)
  • Changes to HW (what the policy is about backwards compatibility, currently states use new standards when purchasing new equipment)
  • Set-up validation - as time permits
  • New VVPR requirements - as time permits (white paper)
  • New electronic records requirements - as time permits (white paper)
  • Others?

There should be good abstracts/summaries at the beginnings of all our white papers. Papers are due to Allan by Wednesday, November 22, cob. Slides to Allan by Wednesday a.m., November 29.

John Wack to send email about developing standards for software IV, some NIST staff feel we could/should be doing more work, and some disagree. This issue should be discussed before meeting. Some EAC members feel we should be forthcoming with more requirements for this class. John Kelsey needs to be ready to discuss.
John Wack will send out note to TGDC with more details about what each committee will be presenting.

Charter for TGDC runs through June 2007.

Next meeting, Tuesday, November 28, 2006.


Teleconferences from 200420052006 and upcoming in 2006.



Security and Transparency Subcommittee (STS) Conference Call
Tuesday, November 14, 2006, 10:30 a.m.


1) Administrative Updates
2) SW independent/dependent path forward
3) Revised TGDC December meeting agenda for STS (See attachment TGDC Agenda_draft_110806.pdf)
4) Clarification of content for security documentation requirements
5) Other Items
6) Next call Tuesday, November 21, 2006 at 10:30AM.

Participants: Alicia Clay, Allan Eustis, Bill Burr, David Flater, David Wagner, Commissioner Donetta Davidson, Helen Purcell, John Wack, Nelson Hastings, Patrick Gannon, Quynh Dang, Rene Peralta, Ron Rivest, Santosh Chokhani, Sharon Laskowski, Steve Berger, Wendy Havens

Administrative Updates:

  • Allan: EAC/NIST are starting to plan when the next TGDC meeting after December will be. Tentatively week of March 15-16 or 20-25 are in play.

Review of EAC/NIST/TGDC Meeting on November 13

  • John W: Ron had sent his software independent paper to the EAC. John is writing Bill Burr's version of this combined with an internal NIST paper focusing on what we'll be presenting - a white paper outlining our strategy. Donetta Davidson will email Brian's concerns about this paper for Ron and John's response.
  • Issue from meeting: Are we making big changes in VVSG 07 or not? Discussion of Incremental changes how state laws may have some affect on those changes.
  • We should discuss where we are and what we have left to do for the December meeting.
  • Ron: We need to nail down as much as possible for the security and risk management piece.
  • The software independent system was discussed a lot, both specifically and in regards to what it means to the larger picture of other kinds of voting systems.
  • Black box DREs without software independence would not be certified under the new system.
  • Two categories of voting systems: independent dual verification (viability in the marketplace) and end-to-end cryptographic systems which would be software independent, but we could be more specific about the kind of requirements we write for them. Coming back from the EAC/NIST meeting with a clearer view that the independent dual verification system not be excluded.
  • Alicia question: When Mark Skall said he wanted us to move forward on the innovation class, does he want us to write requirements to get certified or the process? There was discussion but no conclusions. We could probably write high level requirements, but we definitely need more discussion. This should be brought to full TGDC committee. Is it enough to say "we want to encourage innovation; we realize it's not happening fast enough"? How do we stimulate vendors to produce a new designs. We should have an open door policy - we need a certification process that makes it clear that they can request certification of a system that involves innovative approaches.
  • There was discussion about disabled voters and accessibility and how it relates to software independence and voter verification. Whitney Q will help work on the white paper.
  • Everyone on the EAC/NIST call felt comfortable with our approach on wireless.
  • OEVT was mentioned, not much time for discussing.
  • Also discussion led by Whitney and Dan on their subcommittees priorities.
  • Donetta: EAC has testified before congress that VVSG 07 will be delivered in July 07 and we cannot change our timeframe. We need to prioritize the most important elements in the security area that we need to address. We need to evaluate the security risks and how they fall into place. Think about cost factor. Think about time element - TGDC needs to give guidance about how long it will take manufacturers to meet requirements. Will EAC be holding a hearing with the vendors to get their feedback? This should be brought up at ITAA vendor meeting. EAC is going to have a summit about the costs of doing certification.
  • Helen feels that they were rushed before with the VVSG 2005 standards and buying voting equipment to comply with HAVA and does not want that to happen again.
  • Donetta hopes election officials will ask questions at the TGDC meeting so that they understand what we are doing with VVSG 2007.

Software Independent/Dependent Path Forward

We seem to be making good progress for the December TGDC meeting. We don't support software dependent systems, so black box DREs will not be certified. But there is the innovation class if someone has something new.

How do we best move forward with this thrust at the meeting? We have the paper John is revising. Do we need a resolution? Ron will be making a presentation at the meeting. We need to determine what is the best approach?

John: From an engineering point of view, the DRE architecture is not something we should put forth. The threats say this is not a good architecture. In general, it was something rushed to the market and does not have an audit trail. That is the reason we should give for not going this route in VVSG 07. Not suitable for the future.

Bill B: Accepting stand alone DREs is saying that security is not very relevant. The system should be designed from the ground up to be audited. If you accept these DREs as is, your avoiding the possibility of errors or the possibility of someone manipulating the code.

Barbara: In the context of error, in regards to the situation in Sarasota, FL, 18,000 votes may have been lost. This is where doing forensics on the machines becomes important. After the analysis, it might be interesting to use in our presentations. Paper trails may not have helped in this situation. However, we don't know what happened. Patrick is in Sarasota. Each county designs its own ballot. Is this a software problem or a ballot design problem? What are we doing in this committee that could have helped? If it was a software glitch, definitely the stuff on software independent would; whether the setup validation should be written in a way that's useful for post election checking.

John K: Is there a process in various states to look at the machines in a forensics way, take them apart? Donetta feels that could wipe out election results if they didn't know what they were doing. Need to do examination like computer/criminal forensics. States have nothing set up.

What happens if L&A tests pass before election but fail after? Answer- Review of whole election.
In DREs, is the ballot image kept on the machine or memory card? Answer- Both with an audit trail.

In getting back to TGDC, it looks like we can come up with good reasons why we're not writing requirements for stand-alone DREs. What are we going to do with the requirements (high-level or not) for the IV systems? Propose we have requirements to certify against or build against? If someone wants to propose a software dependent system like IV, it must go through the innovation class mechanism for evaluating.

EAC is looking at this committee for leadership trying to architect approaches within the class of IV that people can build to. This may be hard for this committee to do. However, there is an expectation on this subcommittee that we try to clarify our feelings and technical issues with this area and try and position the IV system somehow so that someone could propose a system in this area and what kind of architecture fits. The innovation class is hard to design.

We can not shut the door and say the paper is the way we're going to go. There are continuing problems and issues. Having it as the only thing would be bad, but having it as a check on the electronic record is very viable approach.

What we're saying is right now what we know is how to write standards for are paper systems if we want them to be auditable. We would like to write them for electronic and end-to-end systems but we don't know how to do that yet. Ron thinks we can do high level for both, David for end-to-end, challenging but feasible, IV impossible. Rene Peralta disagrees, he thinks we can write specs for IV.

John W: Good for December meeting to get the points across and maybe come with some high level requirements, but writing them by the meeting may be impossible. Maybe a short white paper.

Alicia: If we go into the Dec. meeting with requirements for paper, and high level requirements for systems we're putting in the innovation class that we're not going to be certifying against, we will be saying people have to use paper. Ron thinks even if the requirements are high level for the innovation class , there will be a rigorous process for achieving certification.

It sounds like we're saying the door is open for other systems, but not very far. It could be a 5 or 10 year process. From the time a vendor designs, builds, tests to go through our process which is probably not going to be a quick process.

Donetta: Have you talked to the vendors to see about the future to see if they plan to come up with a different type of voting system at various levels of abstraction. The vendors think that VVPAT is not the way to go, that the DRE architecture is fine. We should be looking at secure system approaches to building better DREs. Not looking at other forms of IV.

To build a secure system out of a functionally insecure architecture, you'd have to start from scratch.

We're giving the vendors limited amounts of freedom, limiting the available options to the vendor, specifically printers, there's a lot we can do about what printing technology would hold up to this use scenario. It should be easy to do a solid audit trail - we should be able to do something that would record keystrokes off the machines.

John W: Strategy was agreed at last conference call, which is what we briefed Bill Jeffrey on. Much confusion on our strategy after EAC/NIST/TGDC meeting on Monday. Innovation class versus the IV class. Certification path for the innovation class was agreed upon. Hearing agreement about IV, Ron and David feel not worth going down, others disagree. Feels there should be discussion at TGDC meeting why IV is difficult.

Software dependent machines much have very strong requirements.

John Kelsey would be able to discuss proof of concepts at the TGDC meeting.

Bill B: If we go in with an absolute notion of software independence and an absolution notion of voter privacy and secret ballots, can we develop systems that do both? David W: YES. These things can be done, they're challenging but can be accomplished. Is it possible to get an end-to-end system certified now if you showed it couldn't be worse than a certified system? Risky.

Agenda for December TGDC Meeting

STS has three hours. Draft agenda as proposed after discussion:

#1 - Restructuring the security components of VVSG 2007

  • New architecture with audit base
  • Related, high level testing expectations (will include discussion of OEVT and security documentation)

#2 - Position on SW dependent systems and the innovation class alternative

#3 - Significant changes in requirements

  • Wireless
  • Changes to HW
  • Set-up validation - (as time permits)
  • New VVPR requirements - as time permits
  • New electronic records requirements - as time permits
  • Others?

Meeting Concluded: 12 Noon.


Teleconferences from 200420052006 and upcoming in 2006.


Security and Transparency Subcommittee (STS) Teleconference

Tuesday, October 31, 2006


1) Administrative Updates
2) Discussion of voter verifiable paper records (VVPR)
3) Discussion of end-to-end voting systems
4) Path forward on IDV in VVSG 2007
5) Other Items
6) Next call Thursday, November 9, 2006 at 10:30AM.

Participants: Allan Eustis, Angela Orbach, Bill Burr, David Wagner, Helen Purcell, John Kelsey, John Wack, Nelson Hastings, Quynh Dang, Rene Peralta, Ron Rivest, Steve Berger, Wendy Havens

Administrative Updates:

  • Allan: Lucy Salah sent out email. For those who have not completed travel plans, there are some deadlines for hotels and flights.
  • Allan: There will be a reception on Sunday night, 7:00 p.m. - 9:00 p.m., in the Hilton bar. EAC commissioners, NIST staff plan to attend. Monday begins at 9:00 a.m., Tuesday at 8:30 a.m. Draft agenda available soon.
  • John W: We are putting up presentation material on the web by November 20. It will be mailed in final form November 27.
  • John W: Security Assessment of Diebold Scan by Univ. of Conn.
  • John W: David Wagner emails about priorities for December.
  • John W: Meeting with NIST Director about recommendations for presentations and positions we are taking. We need a short summary paper about why we want to mandate(?) software independent voting systems.

Priorities - Ron Rivest

  • Metaphor - this industry is a lot like the children's toy industry when talking about regulations - wireless is like something with a sharp edge.
  • Number 1 Priority - Software independent /software dependent. We should push hard to ban software dependent profiles of voting. We don't want secret code where an undetected bug could cause undetectable changes in the election outcome. If not good for TGDC, we should make the code public.
  • Number 2 - Security Documentation. Make sure we have burden on vendor.
  • Number 3 - Open-ended Vulnerability Testing.
  • Number 4 - Banning Wireless.
  • Number 5 - Requiring Set-up Validation. Wants to change "should" to "shall". If not, recommend we mandate systems that don't have validators have hard wire reprogrammable program memory.
  • Number 6 - Having an innovation class. We spend too much time on design modes of new classes of voting systems that aren't designed, electronic IDV.

Topics for December? Yes. End-to-end crypto systems as well? Maybe. Are we going to introduce resolutions for all these? Wireless - if appropriate. Security Documentation already in resolution. Setup Validation - maybe not necessary.

Setup validation is a precursor to IDV discussion. Not including requirements for electronic IDV -- should this section be if you know you're going to consider them. [If we say that we only want software independent system, then the electronic IDV is out.]

Major confusion about deliverables and requirements that are due for VVSG 2007. We need test bases to implement standards we have more than revised standards. Committee has been operating under the assumption that July 2007 is the target date new sets of resolutions and requirements to replace 2005. Memo sent out last summer discussing purpose of TGDC. EAC wants TGDC to do what is best and will secure the election system. This is what STS has been discussing, and software dependent systems have come to the top as having extreme risk.

We do not have adequate tools today to validate that the equipment being used is the same that is being certified. The certification process is incapable of ensuring there are not critical bugs.

We need better information flow and coordination between state's vigorous evaluation process and federal process and requirements. Could use TGDC help, but may be out of our scope. Maybe TGDC could identify where redundant independent testing adds value and where it doesn't - especially open ended testing with security.

As far as December meeting priorities, there appears to be concern with banning software dependent machines - primarily for transition. We also need to think about the public confidence message we send. We need to show them that people are working to improve the processes. If drivers of deployment are economic we may not do any better with deploying non-broken systems than last time. Some machines are easily certified within current resources, others are much more expensive. No amount of money would help us completely evaluate software dependent systems. We are trying to develop a class of systems that can be certified with the resources available.

If there are no funds provided to the states from the federal government, it will be difficult for the jurisdictions to make significant improvements. Members thought we were looking at 2007 to give guidelines to vendors and officials where we were going to go.

Transition plan. Current systems are grand-fathered. When buying new systems after 2010, then you'll have to choose from the ones that are certified. The TGDC was not tasked to make plans and regulations for grand-fathering systems, however, should keep that in mind when making changes.

Each subcommittee will get about 3 hours to present at the December 4 and 5 TGDC meeting. An hour for resolutions will be at the end.

End-to-end Systems

Bill Burr had passed around a note and there has been some email discussion about this topic.

If we're talking about a whole class of innovative systems, the most interesting comments were on the process. If we're talking about end-to-end systems being software independent, David's requirements has that all code had to be public to certify such systems. If we have software independence, end-to-end, Bill's not sure why we have to do this. [David: The evaluation process has to determine whether the system is indeed software independent (checking crypto protocol implement properly). Evaluation has to be done by someone, and the best way to do that is have a security evaluation panel to evaluate security issues and to make sure that panel is not structured the same as the testing labs. Ron: The current feeling of manufacturers may be reluctant to reveal their source code because of how it's written, while manufacturers that are writing newer code with more knowledge on it might be more agreeable. Fear of disclosing code because of trade secrets.]

There's no logical requirement that the code be public because you're not dependent on that code. [John K disagrees. Because you have to have some way to verify that the code in the machine is actually implementing the protocol you think it's implementing, making sure it follows the rules, making sure it doesn't violate voter privacy or giving out information so an attacker can buy votes, and you have reliability issues.] Not having the source code does not mean you can't validate the election.

We don't want to spend duplicate money for doing the software evaluation for end-to-end voting systems the same as you do for the closed boxed DREs.

Should we be drafting separate class and requirements for that class for end-to-end systems or whether we should lump it into a larger innovation class and provide for new systems to be included in that? What else will be in the class? VVPAT, paper opscan, fraud-like opscan device.

David Wagner: What are the 3 biggest things we could be doing to improve security. 1) Mandating software and hardware independent voting systems (banning ones that are software dependent), 2) instituting some kind of security evaluation process, and 3) source code disclosure. Those are in priority order, so the first one is the one I would want most.

Bill's paper was meant to be a short introduction, to sell the concept. Would like to have Bill Jeffrey read this as well as the 3 ballot paper. David Wagner agrees with model, just suggests changes in the evaluation process.

Bill: How do we cope with the new public crypto key systems that are being pushed for federal use? A lot of process things we need answers to. A paring based crypto system. It's not obvious that using a government approved crypto system is so important. Technology is evolving and we'd like to have some kind of strong evaluation process. Innovation class is open. If someone can make software dependent systems work, we'll listen to them.

The evaluation process only validates that the systems are certifiable at some high level of security.

With the new innovation classes, we need to provide a lot of publicly disclosed information. New innovation class would definitely have a generic high level state of requirements. More specific requirements would be architecture dependent.

HAVA requires that standards be examined every four years. There needs to be some sort of change process for adding modules. Maybe we should mention this at the December meeting. We may need to update the VVSG on a continuing basis.

Under new model, the way to have an IDV system certified is to go through the new innovation process we're discussing. We need to get the high level requirements right, and then the vendor could design something and bring it to the table.

We need manufacturer push instead of NIST pull on this stuff. States should ask if there are classes that are not currently on the market that they would like to see. Bill needs to write section at the end to invite vendors to write proposals and that the burden would be on them.

We need to have a budget set aside to support innovation. For either evaluation process or for people designing new innovations. NIST needs to stay away for designing. We should be looking at the evaluation process.

We need to have as much discussion as possible with the TGDC before the December meeting.

Will there be an issue about whether or not we need to write VVSG 07 or whether we should be looking at other testing issues instead? Steve believes that will be the case, and thought that was already settled. Steve please send out his last summer memo regarding this issue.

When you talk about TGDC not doing design work, I agree. But please elaborate exactly what you mean. When talking about design election mark up language for IDV or the protocol between devices, or pairing classes is inappropriate for this committee. Steve things that when discussing interfaces that work reliably, not doing a complete system. This should be a continuing discussion about interfaces. This also goes to software, and better firewalls.

This is a huge issue if the TGDC members decide to do something besides the VVSG 2007. We need to discuss this!

Next meeting is Thursday, November 9, 2006.

Teleconferences from 200420052006 and upcoming in 2006.


Security and Transparency Subcommittee (STS) Teleconference

Tuesday, October 17, 2006

Participants: Alicia Clay, Allan Eustis, Barbara Guttman, Bill Burr, David Flater, David Wagner, Rene Peralta, Helen Purcell, John Kelsey, John Wack, Nelson Hastings, Patrick Gannon, Quin Dang, Ron Rivest, Wendy Havins


1) Administrative Updates

2) Summary of October 7th administrative meeting

3) Discussion of proposal for voting system key management

4) Other Items

5) Next call Tuesday, October 31, 2006 at 10:30AM.

Administrative Updates:

  • Allan: Welcome to David Wagner (STS) who is now officially part of the TGDC, as well as the other three new members: Philip Pearce (CRT), Tricia Mason (HFP), and Paul Miller (CRT). We are setting up an orientation teleconference, hopefully before the  end of October.
  • Allan: Reminder, the next plenary session of the TGDC is December 4 and 5, 2006  here at NIST. A letter will be sent shortly  to Committee members so that travel plans can be made. Also available for anyone who can not attend will be teleconferencing capabilities and webcasting. Schedule (preliminary): Reception on Dec. 3, (7 pm).  9:00 a.m. start on Dec. 4 (finish 5:30 pm), and 8:30-2:00 on Dec. 5.
  • John W: EAC agreed that for the VVSG 07, voting systems should not have wireless capabilities. Using IR to read valid activation token is not a bad idea, since smart cards wear out. There is an ITAA  vendor meeting on Friday, John will question them about e-poll book usage. [Ron questioned whether the e-poll books should be in the scope of the committee.] John wil  write position piece on issues and decisions on e-poll books to vent with other subcommittees and EAC.

Summary of October 7th Meeting

  • Alicia Clay took notes for meeting  minutes. A lot of good work at the meeting. Final notes will be sent to STS.
  • Group came to an agreement on the revised outline for the security related topics for the VVSG 07,it will be circulated for comment. The basic idea is to start with a security and audit architecture overview, talking about threat and securing the systems; then profile specific security and audit functional overviews (testable requirements), broken out into software independent voting systems and software dependent voting systems. The next section is profile independent tactical security requirements (where the bulk of the material from the original outline will go). Last will be a section on end-to-end verifiable voting systems, starting with an overview of principles behind how each system works. The last section will different in that instead of just testable requirements, it will start with submission requirements. An electronic copy of the outline will be available shortly.
  • General comments on the security component.
  • Documentation requirements: Need a decision about what should be in  public test package and what shouldn't; how we could make these test packages support  good procedures. Make sure we get requirements from the labs to get their understanding of how security works to ensure that they look at the details of the system.
  • Decided to require FIPS 140-2, Validated Hardware Crypto models for certain functions - for all digital signatures.
  • Also considering having two kinds of keys for every voting machine - one permanent key and one changed for every election.
  • Received an verview on open-ended vulnerability testing.
  • IDV: General ideas for IDV systems that will be presented in VVSG 07 and coming up with a position paper on why we were not discussing detailed requirements for stand-alone DREs in VVSG 07.
  • Someone needs to update the working outline on the web. The revised outline from the meeting is written at a high level.

Discussion of proposal for voting system key management

Proposal from Bill Burr on key management and crypto models.

The module uses or generates the following data elements:

  • Module serial number - a unique serial number for the module, created by the module manufacturer, and stored in the module. The module serial number can be read from the module.
  • Module key - a signature key pair generated once by the module during module initialization and never changed during the life of the module. This key is used to sign election keys and election closeout records. The device private key is never exported from the module.
  • Module certificate - a public key certificate, issued by the entity that initialized the module, binding the module serial number and the module key.
  • Election key - a signature key pair generated by the module for each election; the election private key is never exported from the module and is zero'd by the process that generates the election closeout certificate; thereafter that election private key no longer exists. {the election key may also be used to sign some kind of initial system configuration record, and other kinds of logged transactions}
  • Election counter - a running count of the number of election keys generated by the module
  • Election signature counter - a count of the number of signature operations performed by the current election key.
  • Election certificate - A public key certificate signed by the module key, that certifies an election key. The election key is generated at the start of the election certificate generation process and the election certificate is exported from the module after it is generated.
  • Election closeout certificate - A certificate signed by the election key that is created at the conclusion of and election. The election closeout process creates this certificate, then increments the election counter and zeroizes election private key before outputting the election closeout certificate.

David Wagner points out that we haven't dealt accurately with the threats that this is intended to meet. That's because Bill thought the overall threat discussion belonged a level above this proposal.

How much overall responsibility is the crypto module and how much is the machine that houses it and the overall structure? The write-up was written to apply to a whole family of voting machines.

Suggestion from David Wagner: Append a nonce  to each signature. That implies that the whole record to be signed into the crypto module and let it generate the hash with the random number and sign the whole quantity. This would encapsulate more of the security protections in the crypto module.

David Wagner's comments, which were shared among the STS subcommittee were discussed.

David W: This is a good idea. A lot of our machines depend on use procedures and physical security handling procedures to ensure chain of custody and this would help reduce the amount of dependence on that.

On the spectrum between specifying requirements and specifying a particular design this may reduce flexibility if we standardize on this one particular scheme.  [Ron feels that for crypto, we may want to be more specific on the performance requirements than the design requirements, although it's very hard to get the crypto designs right.]  While performance requirements are better, they are harder to write and much harder to test. While we're building, we should use design requirements.

Hopes that exact formal specifications for the bits that the crypto module generates should be standardized.

Threat models - missing a clear statement to what the threat model you're trying to defend against and what are the security goals that you are trying to guarantee.  There's a broad level of ambition, it needs to be thought through clearly.  This scheme will defend against some, not other, so we need to know what we're trying to defend against.  Once we have electronic records and electronic signatures, this should be an easily solved problem.  No matter what else we do, we need to solve threats one and two, to make sure the records are safe from the time they leave the voting machine til they’re reported in the final total.  This would get us closer to a requirement oriented spec, the requirement being that the mechanism needs to defeat all those threats.  [Ron noted that the draft did not say anything about verifying signatures -- that needs to be clarified.]  [John K to send out a paper which covers this topic.]

These threats s should be in a suitable format for web posting should laws and other considerations allow it; trying to push for a publication in general is outside our mandate.

Question about requirement to export electronic cast vote records in some form of interoperable format, we've talked about EML; if they're signed, is there any way to do that and preserve the validity of the signature?  Yes.  Should we standardize, it would be simpler?

The format of all the data signed should be disclosed by the vendor.  We could say that vendors had to use a defined interoperable format.  Or the specs could be published in specific detail so that someone could re-implement something to parse those records to understand what they mean, and one way is to have the vendor provide a translator from their internal format to EML.

John Kelsey is to send questions to Patrick Gannon in regards to what specifically we can do with EML.  Patrick will forward and to elections committee that worked on EML and get back to John.

In addition for the cast vote records, format for audit log information plus zero tape and summary tape contents should be signed.  All information coming out of the voting machine to produce an audit should be in a public format – you should not have to use vendor software to audit vendor software.

A certificate chain  (of custody) needs to be incorporated and checkable because the machine will be signing off on the election key and the election key is signing off on the records.

Question to David about whether all the information in the proposal is good, but maybe it need to be a "should" requirement.  One argument for this being a "should" is that this isn't necessary for the security of the machine - it would improve it by reducing the dependence on the chain of custody and physical security.

Our goal in VVSG 07 is to have a set of minimum requirements -- and those should be “shalls”.

All we can say is how the equipment shall be built – we can not tell election officials how to run their elections.

Signatures provide a security measure when used on both paper and electronic because there is s a check factor between the two.  Digital signatures are a low cost added security feature.  [Ron want to push for digital signature and signature verification.]

Should be push for signatures to be a “should” in hardware?  Protection should be on the signing key.  Without putting the hardware security there, it would be too easy for them to be compromised.  We have a patches issues, any software that's put on the machines should be signed as well.

This should be discussed further via email and then debate again about shoulds and shalls.

Should we append a random number to each signature?  It should be provided at the hardware level. 

Next meeting Tuesday, October 24, 2006 at 10:30 a.m.

Teleconferences from 200420052006 and upcoming in 2006.



STS Teleconference
Tuesday, October 3, 2006

The meeting commenced at 10:00 a.m.


1) Administrative Updates
2) Discussion of paper on VVPAT and Paper Based Voting System Requirements Relating to Usability and Auditability of the Records
3) Other Items
4) Next call Tuesday, October 17, 2006 at 10:30 a.m.

Participants: Alicia Clay, Allan Eustis, Anoop Singhal, Barbara Guttman, Bill Burr, David Wagner, Helen Purcell, John Kelsey, John Wack, Nelson Hastings, Patrick Gannon, Quin Dang, Rene Peralta, Ron Rivest, Thelma Allen, Wendy Havens, David Flater

Administrative Updates:

  • Allan talked to Commissioner Davidson yesterday who informed him that Philip Pearce (Core Requirements Subcommittee) and Tricia Mason (Human Factors Subcommittee) are confirmed as US Access Board representatives to the TGDC. Paul Miller (an election official in WA, Core Requirements Subcommittee) will likely be approved by EAC and NIST soon. David Wagner has bee nominated as the new representative from ANSI to the TGDC.
  • Allan: Observed WA post election activities. The state is primarily a vote by mail state. All four voting vendors have presence in the state of WA with DREs to comply with Section 301 of HAVA. Allan saw 3 of the 4 DREs and 4 counties certification processes. Trip report forthcoming.
  • John W: The official letter ANSI appointing David Wagner has been sent to EAC.

Discussion of paper on VVPAT and Paper Based Voting System Requirements Relating to Usability and Auditability of the Records - John Wack

  • This was intended initially to be a write up to self after reading Election Science Institute's paper and meeting with authors to discuss problems had by Cuyahoga County in auditing their VVPAT systems.
  • In a written response, Diebold has challenged a number of things in the ESI report and so has the Board of Elections in the county.
  • It appears as if the Diebold system was set up to permit rudimentary audits, it didn't seem to be useful; usability seemed to be the biggest problem.
  • A lot of stuff is not VVPAT specific, more so paper records in general.
  • VVPAT defined as DRE with printer.
  • Discussion: Flat sheets of paper vs. paper spools is a difficult choice. Usability issues either way. Which is better? Does the Human Factors committee have an opinion? John's personal experience is that handling the spools is difficult. Spools do maintain a paper record all in one container, but in a continuous non-private record.
  • Bar code issue - Discussed with the Open Voting Consortium. They like using them. It makes the paper record have more integrity. Less resistant to damage. Used for easy sorting. John feels it's an attack vector. You can't trust that audits of the bar code will occur. It's another record you have to keep as well as all the other records. It's not transparent to the voter. If not carefully controlled, it could be trouble in the future. [Ron feels that bar codes were used for visibility. It could be used for accessibility reasons. Also it wouldn't be human readable.] Bar codes can be used for audio translation of names.
  • Do we digitally sign electronic records? This isn't specific for VVPATs that could be done on DREs, could be done by ballot marking devices. It means key pairs on the voting station and how to store them.
  • Records more useful if they were in the interoperable format, we've talked about EML. David Flater and the Core Requirements may be putting something in already.
  • Allan: During his post certification experience in WA, of the paper, mailed-in, op scan ballots, bar codes are used as a record keeping mechanism on envelopes and later auditing processes. Helen uses bar codes to track when the ballots have gone out, and then again when they've come back to tell who has voted. The codes are not on actual ballots, so votes can not be tied to voters.
  • Vendor did not do a good job about documenting how an audit should be conducted or how the records should be used.
  • Issues such as digital signatures on records could be controversial. We want to keep in mind what's most important and then what would be nice to have. Will they be used? What's important to election officials when auditing? We need to be thinking of future.
  • We need to think through how digital signatures will be used, the key management applications. Are they the lifetime of the machine? A memory card for the machine? Per election? What is the signature going to accomplish?
  • John K: We need to write one or two specifications that we know how to test. A little concerned with open-ended testing process being burdened with analyzing key management in a crypto protocol.
  • One of auditors issues in Cuyahoga County: trying to figure out which electronic records came from which machine, comparing what they had to what was still on the machine. Also memory cards that contained ballot layout information actually assigned a machine ID that was not the same as the physical ID. Robust identification would be good. Vendor should contain database linking serial numbers or identifiers on machine to public keys. Looking at electronic records, you should know which machine produced them.
  • Processes for audits have not been tried out or well designed. In the standards, we need to require that someone goes through these audits and make sure they actually work. All information needed for an audit needs to be available, it needs to be in a form suitable for an audit, and procedures need to be tested. This needs to go in document requirements for VVSG 07. Performance benchmarks will have to be done as addendum. [Ron thinks they are easily doable for 07.]
  • Ron: Question is what records should be maintained by the machine and guaranteeing that they're available.
  • In order to get certain pieces of information off machines, a technician would have to be called - this is not a good procedure. Any interaction with the machine should be well documented.
  • John W: Voting machines should digitally sign their records. For linking the electronic records with the paper records and verifying their integrity -- always include the robust machine identifier and include a unique identifier. We have key pairs on voting systems. We should include this in our requirements.
  • John K: If you are digitally signing electronic records, it does not add any value to have that signature on the paper records. The paper record is to mostly check to see if the machine was working properly. There's no added security by putting digital signature on paper record.
  • John W: The reason we have these sort of requirements is to facilitate audits of this nature. Is this the minimum for IV systems? Do we want them to have capabilities for this type of audit, or do we want them to have capabilities for full recounts? [John K has a write up on a proposal about this. Email discussion to follow.]
  • Ron: If paper records are suitable for auditing purposes, and the paper records correspond to the electronic records, why would they not be suitable for recounts? [John W: Possibility that elections conducted on a bunch of VVPATs with paper rolls could be suitable for full recount, but we're getting more into usability issues - more legal issues than technology issues. It's a design consideration for IVs. John K. The minimal requirement is that the system is auditable to see if the machine was misbehaving. It would be nice for records to be suitable for recounting.]

The meeting adjourned at 11:30 a.m.

Teleconferences from 200420052006 and upcoming in 2006.



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


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

Teleconferences from 200420052006 and upcoming in 2006.



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


1) Administrative Updates
2) Update on high-level assumptions and security assumptions
3) Discussion of priorities for STS
4) Other Items
5) Next and future STS calls

Tuesday, September 19 at 10:30AM
Tuesday, October 3 at 10:30AM
Tuesday, October 17 at 10:30AM
Tuesday, October 31 at 10:30AM
Tuesday, November 14 at 10:30AM
Tuesday, November 28 at 10:30AM

Meeting commenced at 10:30 a.m.

Participants: Alicia Clay, Allan Eustis, Anoop Singhal, Bill Burr, David Flater, John Kelsy, John Wack, Nelson Hastings, Quynh Dang, Rick Kuhn, Ron Rivest, Sharon Laskowski, Steve Quinn, Thelma Allen, Wendy Havens, Wendy Orbaugh, Rene Peralta

Administrative Updates:

  • Allan Eustis will finish up his trip report from Wyoming. He has to scan in some documents, including a contract between the state of Wyoming and election system vendors. The contract states that the vendors will comply will all NIST and EAC standards. Allan is interested in group's reaction. Three counties use Diebold, the rest using ES&S.
  • John Wack: A few people will be volunteering at the polls next week. Alicia and John will be traveling to Denver in two weeks to do a NVLAP assessment.
  • John Wack: Discussed a paper that was forwarded from Election Archives Organization. John doesn't know about the merits of the paper, but it has less than nice things to say about election officials. Allan is waiting to get the author's permission to post it on the public comments web page.
  • John, Ron, and Max had a discussion with Gtech, an organization that makes gaming systems for the gambling industry for a number of states. Intent was to get contacts. Lots to learn from what they're doing in testing and self validation and authenticating process and programs. They're interested in setting up a conference call and discussing the overlaps with what we're doing. Allan's going to find out what the DC lottery procedures are.

Basic Assumptions Update:

  • The basic assumptions section is item #4 on Computer Security Division's (CSD) list of deliverables for NIST's December delivery. They will publish this list of deliverables and their schedule soon on the web. Steve Quinn has updated the basic assumptions bullets internally that were discussed in detail at the last S&T meeting based on comments from that meeting. He will send out a new iteration for further comments and vetting before doing the white paper and becoming part of the standard.
  • Ron felt this was a good start but still a little way to go before we can convert this into a usable white paper. Ron wanted to know how CSD's deliverables mapped to our priorities. Steve will send the matrix out soon. Their bullets were created from the table of contents which maps to the priorities. The priorities should not change what they're writing.

STS Priorities:

Looking at the overall package of what needs to be done for December meeting.

Need to identify what will have the most qualitative improvements in the voting system.

The following 3 items are things for discussion that might/should be at the top of the list:

(1) further definition of requirements for open ended vulnerability testing
(2) security documentation requirements
(3) IDV-related requirements (software independence)

Security documentation is good place to start since we already have a framework in place. Security evaluation process shouldn't be put together from bits from vendors. Requirements, mechanisms, policy need to be articulated by the vendor and why they think is sufficient to support the security objectives listed. Good place to push forward, doesn't require any changes in the systems being sold. Makes the evaluation system for security more robust and reliable. Qualitative improvement should be high.

JW: If voting standards have general statements, you get the least amount possible, so we might want to be more specific with possibly an outline, details about what we expect from the vendor. Our challenge will be to right the specs.

JK: Links to open-ended testing is where there's a requirement statement; there should be a statement saying "how" you are meeting this requirement and point you to where it can be reviewed to verify. Proposed as a high priority item, should it be? Seems like it should be a part of every other component.

JK: Documentation requirements should be included where helpful to the evaluator to judge where it passes/fails.

JW: Two audiences - testing lab and users. Some effort should be put forward to identify each aspect of the system that requires procedures.

SQ: It doesn't have to be human-readable in order to make it into the standard.

AE: VVSG primary users are the testing labs.

JW: We started out in relation to security systems and how they are presented to labs and how they are used by vendors but we've discovered as time goes on that usability and security is important for users and election officials. A lot of the problems we are seeing now are because systems are not well documented and people are not appropriately trained. One of the tests should be whether or not procedures are plausible and can be followed. We realize for 2007 that we are not going to be able to do as good a job for security for poll workers as we would like. Procedures for IT systems needs to be present in order for the security goals of the IT system to be effective - what the labs need to evaluate is the system and its documentation. Vendors must be specific about what operating systems they are using, and what off-the-shelf software they are using.

IDV Related Requirements. Definitional proposal - software independence is a useful term to help us characterize what IDV is all about and what kind of testing we want. System is software dependent if correctness of the election results depends on the correctness of the software, that is to say if an undetected error in the software could cause an undetected error in the election results. CSD is willing to accept this proposal as the framework. The character of the testing we do should depend on whether the system is software dependent or not.

JK: The first question we have to ask is are we in the VVSG 2007 certifying closed box DREs.

JW: Opinion is no, IDV with two sets of records should be way to go. Not discussed with TDGC as a whole. Issues may arise because some states are invested in black box DREs and what happens to them, issue which should be handled by EAC, especially if we go a different direction and those are no longer certifiable. The other issue is the debate on VVPAT systems as one of the major types of software independent systems as to whether or not they actually achieve their goals in providing the detectability and auditability that we want. The current round of VVPAT has some issues. The proposal that IDV systems be the only ones that are certifiable is a good place to start from. If we do not write requirements for closed box DREs and we are overwritten, the security holes will continue to exist and we will do nothing to make it better. If black box DREs are allowable, then a vendor proposing software dependent system needs to go to extraordinary lengths to prove that the software in reliable, this may require formal proofs that other systems do not require. If NIST decides to take this approach, it must be organizationally backed. A fairly simple white paper needs to be put out ahead of December TDGC meeting discussing this approach and framing this issue. If we are not going to support black box DREs, then we need to give alternatives. Make sure that TDGC does not think they're only course of action is to throw out current DREs. We are not talking only about existing systems, but new systems down the road. VVSG 2007 certified systems will not be available until 2012. Based on a 10 year system lifetime, they do not want people to think they have to throw out of the systems that don't meet the 2007 standards. IDV spans both categories - dependent and independent.

ACTION: Paper that Ron did on software dependence needs to be warped into a white paper that STS recommends for review by TGDC members. See John Kelsy's email for possible plausible strategies. Email conversations to follow. Move forward with proposal that black box DREs are not going to be supported.

One of HFP's goal is to increase universal accessibility over several years. HFP wants comparable functionality. Paper is not accessible, but when used with voting system with accessible functionality, it is OK.

Open Ended Vulnerability Testing. Ron feels this is something that can provide major qualitative improvement in the security of voting systems. If we can get this up and flying by December, it will be a major milestone. At the monthly meetings between EAC and NIST, it keeps coming up about what can be done now to improve voting systems. Open ended vulnerability testing keeps coming up. This should be a high priority because we may need to provide material on this before the July timeframe. Some skepticism that open ended vulnerability testing will improve the security of the systems. Might be another matter for the TDGC to take on as a whole. If we are trying to test existing systems, the penetration testing has a lot less appeal than if you were testing future systems. The goal is for certification of new systems primarily, not as important for older systems.

ACTION: Meet internally to discuss options and resources.


  • Questions about what the expectations for deliverables arose. Allan, John, Steve, and Alica meeting offline to look at matrix to see how deliverables map.
  • John Wack: Set-up validation is ongoing and very important. We've requested several times that the requirement in VVSG 2007 be rewritten, currently it is pretty ambiguous. VVPAT is another, as there are no real standards on it right now. John lumps VVPAT in with IDV stuff.
  • Meetings have been moved to Tuesday mornings.
  • Two day MIT meeting (October 5 & 6) on voter identification and voter registration systems. Program is almost set. Ron will send around the URL.
  • Allan and John will forward upcoming conferences around. Will post on the web if we get information provided.

Next meeting September 19, 2006.

Meeting adjourned at 11:55 a.m.

John Kelsey e-mail:

Some Notes on Alternatives for Audit Architecture Strategy
John Kelsey, September 2006

1 Introduction

In the last couple of months, we've had a couple apparent changes of direction with respect to what I'll call the architectural requirements for allowing auditing in voting systems. We need to make some decisions about the direction we're going to take, given the time and resources we have available and what we think will actually be used.
The big problem we need to address is that DREs, which are increasingly widely used, have major security problems. These can be broken into two broad categories:

a. The impossibility of meaningful audit of DRE results, and the resulting requirement to trust the in operation of software and hardware.

b. Implementation or design flaws that make the DREs less secure than they have to be.

1.1 IDV

Our original goal was to address (a) with IDV. That is, we could write standards for pure-electronic systems that were designed to be meaningfully auditable. This centered around the idea of some independent piece of software or hardware which could be used to audit the correct recording of the interaction between the voter and the voting machine. (This should sound a bit like Chaum's observer chips.) The good thing about this is that while there are no IDV systems (other than VVPAT) on the market, there's nothing all that hard about building one from available technology. While using an IDV system still leaves us trusting some software and hardware, we only end up trusting that one of two systems hasn't been tampered with.

My sense is that if we have standards for IDV (assuming we can write meaningful ones), we may be able to exclude pure, closed-box DREs. This would be a really good thing, and getting people from unauditable black boxes to pairs of black boxes that audit each other seems like a pretty big win. (We still need to address (b), which is where all the headline-grabbing attacks have happened.) I'm not sure this is possible, but it might be.

The downside of all this is that IDV gives you some audit, but not a really strong audit. It's like the difference between having two different accountants who work in the same office checking each other's work, and having a completely independent auditor come in and go over the books and all the supporting records. It's very easy to imagine that the two different modules in the IDV system will be corrupted at the same time--they'll be stored under the control of the same person, they'll likely have some software in common, they'll be sold by a consolidator who buys the individual components and hooks them together into full systems, etc. What I see as the big problem with IDV is that it pushes us toward a future that is still software-dependent. The clever attacker has to take over two machines, or three, or ten, but then he gets to fix the election.

1.2 Paper (Direct Verification)

John and Ron's software independence paper basically pushed us toward a different direction--not allowing any voting machines which can't be meaningfully audited in a way that doesn't depend on any software or hardware operating correctly. Excluding crypto (which does rely on software correctness, but allows a skeptic to write his own software, and which is not at all ready for standardization), this means we accept only paper systems right now. My concern with this is that I don't think it addresses the DRE question in a way that's actually workable. I'd love to see us say "DREs are no longer going to be part of the standard," and if we can do that, we should. But I think if we write that kind of standard, the TGDC won't accept it, and the EAC will ignore it and keep allowing DREs, and we will be left with no meaningful improvement in the security of the existing crop of DREs, because we won't have written meaningful standards for them.

1.3 End-to-End Crypto

I'm pretty convinced that some kind of crypto voting scheme, like those pushed by VoteHere and David Chaum, is where we'd like to end up. I think there are still some pretty big issues to hash out about them, and we need some kind of operational experience running small elections--I know David Chaum is working on this with the student election competition. I've heard that some states have provisions for the use of experimental voting technology, which is a potential starting point for this stuff. (I keep thinking one of David's all-paper schemes might make a good absentee ballot scheme.) The biggest issue with these is how we standardize the cryptographic protocols. We can describe this class of systems at a high level, and do a Brennan-center type threat analysis of them, but the process of deciding that a proposed voting protocol is secure is going to be harder to deal with. To my mind, protocols are much harder to get right than cryptographic mechanisms like hash functions or block ciphers, but NIST took many years to settle on one acceptable block cipher, and we'll likely do the same with a hash function. It's hard for me to visualize us or anyone else being able to confidently approve a whole proposed voting protocol in much less time.

2 So, What About DREs?

The elephant hiding under the rug (I love mixed metaphors) is what we do about DREs. I see a few plausible strategies, and I'd like to discuss which of them makes sense, both in terms of technology and in terms of what will actually get accepted. (I don't know about you guys, but I'm not really interested in writing standards that get ignored. Life's too short.)

2.1 No DREs in the VVSG2007, Software Independence

We could get rid of any support for DREs in the next version of the standard. Just say no! But then we have to decide what to do about the present and the future. If we go with the software independence notion from John and Ron as a requirement, along with allowing crypto when it's ready, we get a path like:
Today: Use paper
Someday: Use crypto

If we want to do this, I'll be very happy. In that case, we could really try to push the crypto stuff forward, with the hope that existing DREs slowly die off and ultimately are replaced with some kind of end-to-end crypto scheme. But we're a long way from being able to standardize on a crypto scheme, so for the next 10 years or so, probably only paper-based systems would be certified. In security terms, this is probably the best we could do, if it is followed. If we end up certifying DREs anyway, we lose our chance to address some of the huge security problems with them. (DREs could be made very hard to attack for outsiders, though probably not for insiders.)

2.2 No DREs in VVSG2007, IDV

We could also not certify any pure closed-box DREs in the VVSG2007, but write a somewhat theoretical standard (since we have no operational experience, only a few prototypes) for IDV systems. The advantage of this is that some vendor could build a system of this kind from existing components in a couple of years.

This would require writing some pretty extensive requirements for IDV, a lot more than just requiring an audit port on the side of the DRE. One downside here is that we could end up pushing people toward IDV, and thus ultimately away from crypto. Since crypto has the potential to be a lot more secure than IDV, that's a little troubling.

2.3 DREs in VVSG2007, Software Independence as an Ideal

We could write requirements for DREs in VVSG2007 and allow them to continue to be certified, subject to some much tougher testing and security requirements. This is where both the audit port and the OEVT stuff come in. We could then require software independence for VVPAT and Opscan systems (which basically means specifying how they must be audited). We could also write some theoretical discussions of crypto for the future.

This seems like where we're headed right now. We certify DREs for now with tighter requirements, but try to ultimately push software independence where we can. We encourage the eventual move to crypto.

2.4 DREs in VVSG2007, IDV

Finally, we could both allow new DREs with tighter requirements, and also push IDV architecture as a future alternative. I think this doesn't make much sense.

3 My Ideas

I'd like to see us do one of the following:

a. Move to IDV for DREs now, and push toward crypto in the future. (This probably requires more work than we'll be able to get done in the available time.) Don't support DREs anymore.

b. Don't support DREs anymore. Move to paper now, and push toward crypto in the future.

What I think we'll end up doing, in practice, is:

c. Allow DREs with tightened security requirements and no IDV, and make some vague handwaves about how we would like to see crypto systems in the future. Also make some vague comments about how software independence is worthwhile.

I suspect that (a) is politically possible but pretty hard to actually write, and that (b) is much easier to write but probably will either be changed or ignored by the EAC. That lets us keep relatively clean hands, but it does mean that the current security problems with DREs don't get addressed in any comprehensive way in the standard.

3.1 Timetable

Anything we do with a full IDV spec is going to be a pretty theoretical standard (we'll be standardizing stuff that exists only in prototype form right now), and will take some serious time. However, a lot of that time is going to come from the requirements for
hardening software and hardware systems (OEVT, for example). That work probably has to be done anyway. We're not going to have a complete draft of an IDV section we'd be happy using for actual certification of machines in November/December, as far as I can see.
(Who has time to write it?)

OEVT is going to take another year anyway. So maybe making IDV take that long, and getting down to specific testable requirements then is okay. I'd love to hear some discussion of this.



Teleconferences from 200420052006 and upcoming in 2006.



Security and Transparency Teleconference Meeting
Wednesday, August 23, 2006
10:30 a.m.

Participants: Alicia Clay, Allen Eustis, Angela, David Flater, Helen Purcell, Nelson Hastings, Patrick Gannon, Philip Pearce, Ron Rivest, Sharon Laskowski, Thelma Allen, Wendy Haven

The meeting was called to order at 10:33 a.m.

Administrative Updates:

  • Allan Eustis is in Wyoming observing their post election certification process, receiving an education about canvassing procedures after an election. Laramie county has a secure routine and back up process. Trip report forthcoming upon Allen's return.
  • Allen forwarded a note about CNN's Lou Dobbs Tonight which featured an interview with Verified Voting's Founder, Stanford computer science Professor David Dill, concerning the failed pre-election Logic & Accuracy (L&A) tests of voting machines in Pinellas County, Florida last week.
  • There will be several NIST employees attending upcoming logic and accuracy tests in WA, DC, and MD. Follow up notes will be sent out.
  • Helen Purcell mentioned that they were conducting L&A tests on the August 29th. They are having problems with their DREs because of their size. Everything is not able to fit on one computer, more like 12 - they have over 7,000 ballot styles. They have new legislation in place and must count certain counties (approx 2%).
  • John Wack and Nelson Hastings will be traveling to DC on Friday to observe Q&A tests.
  • Nelson introduced Stephen Quinn from the Computer Security Division (CSD).
  • Alternative dates of Tuesday or Thursday were suggested for the teleconferences. Nelson has sent an email out with new dates.
Basic Assumptions:
  • Steve gave a quick introduction regarding CSD's plans to provide various security input to the group. Sections will be introduced into the group for vetting. A schedule of deliverables will be posted on the web. For the August 23rd meeting, the discussion will center around Basic Assumptions for which a bulletized package was forwarded before the meeting.
  • General comments about the sections organization were discussed, including what was the context of the bullets. The bullets are being provided for background material and for the framework in writing the security section
  • Page 1:
    Bullet 1: This bullet discussing voting systems should be replaced with David Flater's definition of voting systems and voting process.
    Bullet 2: Voter registration systems are not part of the voting system
    Bullet 3: Clarify that the poling place in part of the voting system
    Bullet 4: Procedures for running elections are a part of the voting process but not a part of the voting system and therefore outside of scope
  • Page 2:
    Bullet 1: Regarding changes should be inexpensive - What kind of changes are we talking about? It was decided to remove this bullet and it would be given as a verbal guide.
  • Page 3:
    Bullet 6: Discussion about "possible" adversaries.
  • Page 4:
    Add bullet about certification testing not guaranteeing 100% against vulnerabilities.
  • Page 5:
    Methods regarding voter registration system will eventually appear in the VVSG, not immediately.
    Last Bullet: Needs adjustment. How much tampering is possible. Degree of affect needs to be accounted for as well as the risk of detection.
  • Page 6:
    Bullet 1: Not broad enough. Needs to include states view.
    Last Bullet: Intention of this bullet? Needs to have procedures specified and the operation impact of the VVSG.
  • Page 7:
    Bullet 1: Vulnerabilities during life cycle need to be addressed. This bullet needs to be rewritten to make the context larger.
  • Page 8:
    Bullet 1: This bullet sounds like an "absolute". Should be rewritten to change wording to "shall minimize".
    *Add a bullet about transparency and documentation.
  • Page 9:
    Small changes
  • Document Overview: Some organization would be helpful. Is this comprehensive enough? Steve welcomes comments offline.
  • Transparency and documentation not covered - voter confidence is a part of transparency.
  • Question: If voter system uses Cox product are we going to deal with compliance issues? The answer is yes.
  • This is a good starting point for a white paper that needs to be done to address these bullets in more detail. Ron will work on draft. Steve would like comments by next Wednesday, August 30, 2006, including next steps.

Meeting adjourned at 11:45 a.m.

Next teleconference, Thursday, September 7 at 10:30.

Teleconferences from 200420052006 and upcoming in 2006.



STS Teleconference
August 9, 2006

Participants: Allen Eustis, Nelson Hastings, John Wack, Quynh Dang, John Kelsey, Rene Peralta, David Flater Ron Rivest, Angela Orebaugh, Philip Pearce, Adam Ambrogi, Wendy Havens


1) Administrative Updates

2) Summary of USENIX/ACCURATE Electronic Voting Workshop - <>

3) Follow up discussion on software-independence approach

4) Other Items

Administrative Updates:

AE-while away on vacation, inadvertently two meetings were not recorded because of a low battery level in the audio recording device. The minutes of these teleconferences are available for public review on the web site ( We can fill in past discussion item details when discussing items during this conference call.

AE-informed everyone Paul Craft of the TGDC has recently resigned from the TGDC. Letter of appreciation to Paul and recognition of service will be available soon from Dr. William Jeffrey. His NASED Replacement nominee is Paul Miller who is with the State of Washington's secretary of State's office. The vetting process for his appointment should be completed shortly.

JW-discusses issues brought forth from the NIST monthly meeting with the EAC:

  • 2005 VVSG security requirements, current direction in VVSG 2007 VVSG
  • EAC asked for more information on the NSRL; build environment; hold more than hashes in the future? (RR noted problematic issues here- question of what software has to be hashed.)
  • EAC would like know more about where specific voting systems are located within the US (down to county level),sighting, different jurisdictions have different problems. Also EAC will need to notify jurisdiction of re-certification and de-certification related issues.
  • There is a need to address metadata requirements related to voting systems vis a vis robust inventory control.

JW- Noted effort to look at security standards in gaming industry. AE will research security experts in the gambling security area (States of Nevada and New Jersey) and forward names to STS mailing list.

USENIX Electronic Voting Workshop:

NH-summarizes the workshop he attended in Vancouver;

  • good presentation from the keynote speaker
  • included statistical approach to detect fraud
  • importance of exit polls; are they a reliable source
  • if exit polls are too small, do they stay useful
  • talk on source code "very interesting"; open source and disclosed source
  • John Kelsey talks about testing the "hypothesis"
  • Ron Rivest will look into survey reference material and will forward. If sample is random, you can detect anomalies.
  • usable paper records; paper formats
  • read back; pronunciation of names of candidates
  • issue on use of bar codes- layered on a bad design; Populex approach
  • could there be a convergence of EBMS/VVPR here


JK-after looking at relevant memo (below), concern of "what problem" is trying to be solved.

  • direct verification
  • pronunciation of candidates names re: OCR text
  • mechanical (human use) systems
  • concerns worth looking into- don't want to look at just bar codes
  • Question of Populex System that uses a ballot without printing the name of the candidate
  • OP Scan just reads position on ballot and not candidates name
  • Heart of issue here is to detect errors
  • definition of "verification" procedures: we are re introducing directly verifiable records
  • RR noted that being software independent is not a panacea here.
  • John Kelsey will send comments on the document: You still have implicit trade offs here that depend on procedural mechanisms.

JW-will send out useful overlap VVSG areas in which "gaming" requirements might be informative (FIPs modules, etc.)

Next scheduled teleconference:

Wednesday, August 23, 2006 at 10:30 AM EST

Note on Handling of Voter Verified Paper Audit Trail Requirements in VVSG 2007, John Wack
August, 2006

This is a short note whose purpose is to outline an approach to structuring requirements for VVPAT in the VVSG 2007.Some Terminology-

First, I'll address some terminology. I believe that the acronym VVPAT has become associated with today's VVPAT systems, which, I also believe, are not especially usable
or built well. I would like to use a somewhat different term in the VVSG 2007 so as to differentiate the new requirements from today's systems. I think the term 'DRE-Voter Verified Paper Records' is a better term to use to describe its use with DRE systems (DRE-VVPR). I recommend that VVPAT not be used in VVSG 2007.

Overall Presentation Structure

The VVPAT requirements section in VVSG 2005 started out as a self-contained standard. It was subsequently modified so as to reference usability and accessibility requirements in the HFP section, but otherwise, it still contains many workmanship, reliability, interoperability, security, and cryptography requirements that logically would belong in other sections of the VVSG 07.

I recommend that the requirements be better integrated into the VVSG, that is, the VVPAT section should contain only those requirements that pertain specifically to
VVPAT and other requirements be located in their major sections (e.g. Usability, Hardware, etc).

I recommend using the class structure and the appropriate 'applies to' fields in requirements as the preferred way of doing this. Overall, I recommend that Software Independent Approaches be the highest-level category of acceptable voting systems, with IV being one of the approaches. DREVVPR is one example of IV. Another example is Op Scan-VVPR.


I recommend that VVPAT not violate privacy: paper audit trails shall not store voter's cast ballot records sequentially. This was the TGDC's direction in VVSG 2005 but the EAC subsequently decided to permit sequential storage and require stronger procedures for safeguarding the paper rolls (an un-testable and unenforceable requirement).

Bar Codes

I recommend that bar codes to contain cast ballot records no longer be permitted. I believe the bar codes came about because of the recognition that paper rolls are difficult at best to use in audits and therefore use of a bar code would permit relatively simple and
accurate optical scanning. However, voters cannot verify the bar codes and therefore they can't be used in audits unless they are compared against their plain-text equivalents in sufficient numbers. This adds complexity to auditing and doesn't adequately address
the main problem, that being the poor quality and usability of the paper record. I think
the fonts on the paper record should continue to be required to be OCR fonts (as in VVSG 2005). If printed well, the fonts should be adequate and useful in optical


Created January 15, 2020, Updated January 16, 2020