STS Teleconference

May 3, 2006

Participants: Allan Eustis, John Wack, Nelson Hastings, David Flater,
Jim Elekes,

Rene Peralta, Ron Rivest, Helen Purcell, Angela Orebaugh, John Kelsey,

Patrick Gannon, David Karmol, Wendy Havens, Sharon Laskowski

[Agenda]{.underline}

1\) Administrative Updates

2\) Discussion of paper entitled \"Tamper-Evident, History-Independent,

Subliminal-Free Data Structures on PROM Storage -or- How to Store

Ballots on a Voting Machine\"

3\) Discussion of Setup Validation

4\) Other items

5\) Next call Wednesday, May 17, 2006 at 10:30AM

Meeting begins: 10:30 am

AE- indicates the NIST effort to ensure that the sub-committee meetings
include any TGDC member that is interested in joining in the
subcommittee teleconferences; the outreach is a result of the discussion
at 3/29 Plenary meeting, to make the teleconferences more inclusive.
Donetta Davidson will also join in conference calls when her schedule
allows.

Also, TGDC members must send in receipts from the March Plenary meeting
to Lucy Salah in order to be reimbursed. Any questions please contact
Lucy at 301-975-3345.

JW- brings up concerns of Roy Saltman re: IDV issues in recent
discussion- specifically his professional opinion about the use of \"too
much VVPAT\" and not enough \"IDV\". NIST voting team will meet with Roy
next week to explore the issues further.

NH -- began a review of set-up validation issues for VVSG 2007:

> \- Reviewed teleconference with the ITAA vendor members re: set-up
> validation issues including programmable chips and read-only interface
> (*see (c) below*)

\- Addressable memory chips; programming that could affect the integrity
of the election. These controller chips get programmed usually once. RR
notes there is an issue only if it affects the integrity of an election.
(We perhaps want to evolve standards here.)

-NH will talk to NIST electronics lab engineers on issues.

\- JE raised question about verbal instructions for the poll workers;
considering most poll workers would fall either under the college age
students (IT capable) or the senior citizens (non technology oriented)

-RP noted need for simplicity in set up validation architectures for
poll workers. Need technician training to do set up correctly. Average
poll worker is not capable to accomplish set up validation.

\- Strategy for procedures for election officials should be as
\"simple\" as possible.

\- Documentation to poll workers should be in plain language. SL notes
that from a usability standpoint you want to see instruction manuals and
tst them with poll workers.

AE noted use of IT technicians at each precinct in District of Columbia.

\- HP noted use of trouble shooters in Arizona. They are IT trained. She
noted a preference for set up validation to take place before machines
are sent to polling places. Polling places are spread out at great
distances in western states like Arizona. If set up validation can be
done simply like running zero tape, then this is ok.

-JW/JK raised possibility of random set up validation events at polling
places. RR agreed that the process could be randomized for testing. What
you want is the capability. Also, procedure could be done at the
warehouse or at precinvt level.

\- JW noted Georgia procedures that work using a boot floppy as part of
election management program

-NH noted that vendors are using modified COTs programs that make set up
validation difficult from the point of view of architecture inspection.

RR noted that set up validation is a new issue. Election officials need
to know with a high degree of certainty that voting machines are set up
correctly.

\- RR summarizes paper: \"Tamper-Evident, History-Independent, and
Subliminal-Free Data Structures on PROM Storage -or- How to Store
Ballots on a Voting Machine\"

\- Records of "cast votes" on PROM storage. You can only write once.

\- History independent would be an important contribution.

-DF noted that design requirement to shuffle votes was not present in
either the 2002 VSS or the VVSG 2005.

\- Discussion of trusted component concept; should it be incorporated in
the requirements. RR noted that this gets down to design level. What you
want is a performance requirement. You do not want to put strictures on
architecture. (You want to develop an assurance level here.)

\- Problem with voting systems unique overall; can be better understood
in \"real world\"

-Need to understand patching issues more fully with respect to
recertification. "Significant change" requiring re certification is made
at the Secretary of State level in many instances.

-Discussion of hashing limitations.

\- JE noted Federal Register notice regarding Section 508 review of
information technology issues by a federal advisory committee within the
Access Board.

Meeting ends: 11:35

\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\--

*STS Telcon follow on comments by John Wack:*

*Here are a couple of observations on the setup validation work, based
on the telecon yesterday.  I spoke to Nelson about these observations
and I think we more or less agree.*

*(a) I heard that John K is working on a research paper with someone
else outside of NIST on a secure log approach that might or might not do
the same thing in general as setup validation.  While interesting, this
is a change from the direction we have been going in. My own thinking is
that setup validation works best when you can actually look at the code
on the system, but because this isn\'t the perfect solution to setup
validation, it could be augmented with a more secure log capability. 
So, I see the approach John is taking to be useful in logging but not
necessarily as a replacement for setup validation.*

*(b) I think we have decided that the person who does setup validation
needs to be somewhat technically skilled and that we should not assume
that your average election official can perform the setup validation. 
It is okay if it is somewhat difficult to do, and therefore we should
expect that it will be done on some sort of statistical basis as a
random check on whether the proper code has been loaded and is being
used.*

*(c) Overall, the problem of setup validation on voting systems seems to
be no different than if we were talking about other types of systems
that are embedded.  I am wondering if setup validation could be made
more simple for the vendors by urging them to put as much voter
application code as possible all in one place, for example one flash
prom.  And at the same time, if we have clear requirements as to what is
cots and what isn\'t, then we\'d have a better idea of what needs to be
included in setup validation. To make this more clear, my understanding
is that a number of voting system architectures include cots controllers
that may have very little indeed to do with the voting system
application code.  However, the controllers may be modified in some
cases, and so they aren\'t strictly cots and they probably need to be
inspected by the VSTL.  Another point about the controllers is that they
do not change or if they change, it is not very often.  So, inspecting
them only once at the VSTL may be all that is needed for these sorts of
controllers, and once they are inspected they could be sealed in place
so that any tampering would be evident \-- they wouldn\'t work if they
are tampered with.  Of course, maybe the tamper evident seals wouldn\'t
work in some cases and then, I would think the controllers would need to
be included with what needs to be inspected at setup validation time.
So, at least dealing with these hard to validate controllers at the VSTL
and applying some tamper evident seals to them shrinks the boundaries of
what would need to be inspected at setup validation time. Maybe the
procedure used to flash the voting system code could itself be modified
to dump what\'s in the flashed prom, and then that would serve the
purpose of the setup validation.  Flashing needs to be done by someone
relatively skilled in the procedure, but it\'s not rocket science and I
would think that vendors could change their flashing code in a way that
the procedure could be made more simple and could accommodate dumping
what\'s in the flashed prom to a file on a disk, at which point its hash
could be compared to what was loaded originally at the VSTL.*

*I think having some sort of summary sheet from each of the vendors as
to how their systems are hardware architected could make this problem
easier to understand.  I\'m thinking NIST needs to get some assistance
from the vendors and perhaps we can explore this through these ITAA
telecons.*