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

Draft Agenda

1) Administrative Updates
2) Finalize Outstanding Issues Related to Setup Validation, Access Control, and System Event Logging Requirements
3) Discussion of Barcodes
4) Discussion of Read Back for Non-DRE Type Systems - op scan paper ballot and electronic marking systems
5) Other Items
6) Next call Tuesday, May 8th, 2007 at 10:30AM

Attendees: Allan Eustis, Angela Orbaugh, Barbara Guttman, David Wagner, Helen Purcell, John Kelsey, John Wack, Nelson Hastings, Patrick Gannon, Philip Pearce, Quynh Dang, Ron Rivest, Sharon Laskowski, Rene Peralta, Bill Burr

Administrative Updates (Allan Eustis):

A special election was held in DC today (May 1). Allan was a precinct technician there this morning. DC uses Sequoia ABC Edge machines - one of the 1st locations to use DREs due to a lawsuit. These machines have been in service for about 3 years and each machine registers under 2,000 votes. The PCMIA cards tend to go bad on these systems, causing the screen to freeze during voting.

Cost of Testing Summit (Nelson Hastings):

There are approximately 40 people attending this EAC summit, representing election officials, vendors, advocacy groups, and testing labs. One issue raised so far was how much testing Federal testing labs could do so as to minimize testing by states. There was a lot of discussion between vendors and testing labs on the requirements of code review (standard code) - the cost and time for that. States were asked how much it costs to tests - answers varied from small states that didn't do a lot of tests to the larger states that invest around $500K for testing. Nelson reported that there would be no minutes from the meeting. Ron Rivest asked to hear more about what happened at the summit and wondered if the data on testing costs could be acquired. Allan will check with Mat Masterson after summit.

Set-up Validation (Nelson Hastings):

Nelson presented the changes that he had made to set up validation requirements based on previous STS discussions. Set-up validation would be required for system architecture that allowed polling place accumulation of records. Systems such as the Hart system's centrally controlled system and Diebold's networked vote capture devices would require the set-up validation. This currently does not affect the Sequoia systems. STS members present at the meeting agreed with the language as written.

Access Control and System Event Logging (Nelson Hastings):

There was considerable discussion regarding event logging. Possibilities for securing event logging include cryptography and write only memory. The group discussed what they felt should be protected against: software tampering before the election, tampering on the day of the election or tampering the end of the day logging and then discussed what the cost impact of these features would be. The requirement as written requires tamper evidence notification (not necessarily tamper prevention). David Wagner offer two options: 1) stick with current language which includes cryptography method that will protect against attacks on day of election to logs or 2) write requirements that are closer to what systems already do (back off requirements about write-once storage) and required signed audit logs that would prevent tampering at the end of the day. Ron Rivest was in favor of option #2. Option 2 appears to be addressed in electronic records requirements. Requirement should include wording to protect against attempts by human to delete logs through approved interfaces (no normal function should tamper with event log). Angela will re-work language and pass around for comments.

Barcodes (John Kelsey):

John had sent out a summary of high level requirements before the meeting (see below). To summarize, requirements should permit barcodes but they must allow for disabling (this will raise issues because of accessibility); barcode must be in public format readable by any barcode reader; must contain full content of human readable ballot. They may contain error correcting codes, digital signatures, internal representation of cast vote record (concerns expressed about ballot style in barcode - should contain link to ballot definition file). David Wagner expressed that the major requirement was that it must be possible to recover human readable text for accessibility and possible recount. The barcode should be able to generate human readable text that would be used to generate audio read back. David wanted to make a small tweak to the framework proposed by John Kelsey that if the barcode was disabled, that the machine fall back to how audio read back in generated today - from internal memory. Ron Rivest agreed with David's request. Ron pointed out that the auditing requirements for barcodes should be strong. John Kelsey reminded everyone that he had passed out a paper regarding auditing barcodes and asked for feedback.

Read back for Non-DRE Equipment (David Wagner):

David was concerned that the committee hasn't thought about read back for opscan machines or for electronic ballot markers. These cause major challenges. Some challenges for OCR would be multiple columns, a race that expands multiple columns, write-ins. How do we handle the read back? Do we use a separate device? Do we hook up an audio out to the opscan machine? What happens if the voter doesn't like the read back and it's already been scanned in? [NOTE: Ron pointed out that the read back mechanism was required for Access-VS, not all systems.] Sharon Laskowski pointed out that you could use barcodes or OCR on the ballot to do read back. Separate electronic ballot markers could also be used to read what was filled out on the ballots.

The requirement will be written that states the read back must accurately read back accurately what is on the print out, there has to be independent read back capability, and there must be trusted hardware to do the read back. The requirements that are written must be very clear for vendors and testing labs. Currently as written the requirement does not call for independent read back or anything about confidence.
There appears to be confusion and concern over the resolution that was passed by the TGDC regarding the read back requirement. Ron summarized by saying that the requirement must state that some functionality must be used to take durable records and produces audio read back. A clear discussion must be written to go with the requirement and it must cover several key questions including that process, what are the inputs to that process, what are the testing requirements for that process. STS feels that this should be handled by HFP. Allan Eustis will gather these questions together and forward to Sharon Laskowski as a start up for the write up.

Future Meetings (Nelson Hastings):

Two meetings next week: May 8th and May 10th. The agenda for May 8th will possibly include access control, EML, OEVT, and integrity management. For May 10th, the discussion will be about audit strategy requirements - this is critical to discuss before TGDC meeting.

Kelsey E-mail Bar Code Summary:


Barcode = machine-readable, non-human-readable printed thing. (It might not always look like a barcode, but I expect it probably will.)

OCR = Optical Character Recognition = technology for a machine to read normal text that humans can read.

IDV = Using two machines to check one anothers' work, so that machine A audits machine B's totals, and as long as either A or B is honest, problems will be discovered.

SI = Software Independence = using humans to check the work of machines, so that even if all the software used is corrupt, any fraud is almost certain to be detected.


Here are the requirements I think we have, based on an exchange between me and Whitney:

1 Barcodes may be used, but must be possible to disable in accordance with local law. a. Issue: This may interfere with the ability of the voting machine to support verification for blind voters. This may require OCR or some such thing, which may not be practical. We need to get feedback on this from people who have done OCR in the field on this level.

2 Barcodes shall be in a public, fully-specified format

3 Barcodes shall contain the full content of the human-readable ballot.

4 Barcodes may contain only the following informaiton not in the human-readable ballot: a. Error correcting codes, digital signatures, etc. b. Ballot identifiers (these must be possible to turn off)

5 It shall be possible to read the barcode and recover an internal representation of the CVR, possibly using the ballot definition. a. This allows reproduction of the audio ballot. b. This allows reproduction of the human-readable part of the paper ballot. c. This allows counting.

6 The barcode and human-readable records shall appear on the same piece of paper. a. This assumes that a single ballot must never be spread across multiple sheets of paper--sensible, but it does limit the use of off-the-shelf printers/printer paper in VVPAT voting systems.

7 Auditing processes shall be supported and documented a. If you want to use one set of software to test the answers given by another (IDV is your goal), you can do:

(i) Sample 300 or so paper records, verify that barcode-read record = human-readable record.
(ii) Use S/W to count barcodes of all paper records.

b. If you don't want to trust software without verifying the final answer (SI is your goal):
(i) Recount paper records in batches of N (say, 100).
(ii) Produce and print a summary record including all of those batch totals, and subtotals for machines/precincts, and then finally totals for the whole election.
(iii)Choose 300 or so batches to recount. Hand recount the race in question and verify that the counts are right.
(iv) Independently verify the totals for the election from the summary record.

8 Accessibility Requirement: accessible VVPAT shall include barcode reader or OCR reader, which reads back contents of paper record for verification.

a. This is not designed to achieve IDV, but may make some attacks a little bit harder.
b. Software independence requires doing observational testing

9 Provisional ballots may be supported. In this case, unique ballot identifying information shall be printed in human-readable form, and also in barcode form

[* Pursuant to the Help America Vote Act of 2002, the TGDC is charged with directing NIST in performing voting systems research so that the TGDC can fulfill its role of recommending technical standards for voting equipment to the EAC. This teleconference discussion is for the purposes of the STS subcommittee of the TGDC to direct NIST and coordinate its voting-related research relevant to the VVSG 2007. Discussions on this telecon are preliminary and do not necessarily reflect the views of NIST or the TGDC.]

Teleconferences from 2004, 2005, 2006 and upcoming in 2006.


Link to NIST HAVA Page

Last updated: July 25, 2007
Point of Contact

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