Security
and Transparency Subcommittee (STS) Conference Call *
January 9, 2007
1)
Administrative Updates
2) Summary and status of STS activities (the summary document will be
posted to the STS list before the call)
3) Discussion of security related resolution and impact on security
requirements
4) Other Items
5) Next call Tuesday, January 23, 2006 at 10:30 A.M.
Participants: Alicia Clay, Allan Eustis, Angela Orebaugh, Anoop
Singhal, Barbara Guttman, Bill Burr, David Flater, Helen Purcell, John
Wack, Nelson Hastings, Patrick Gannon, Quynh Dang, Ron Rivest, Santosh
Chokhani, Sharon Laskowski, Wendy Havens
Administrative
Updates:
Allan
Eustis:
-
New
disclaimer will be read at the beginning of every telecom. Meetings
are formally announced in Federal register. What is said at these
meetings is public and welcomes any and all new listeners.
-
New
articles and public comments have been placed on the TGDC website.
-
Mark
Skall and Allan attended Donetta Davidson's installation as Chief
Commission of the EAC. Outgoing chief expects approval of new EAC
members in January.
-
Transcripts
from the TGDC December 4 and 5 meeting are on web page.
-
Any
combined TGDC subcommittee meetings will be worked into current schedule
of meetings. New meetings require a couple weeks notice to schedule.
-
Mark
Skall and John spoke at a recent Election Center meeting. Mainly gave
an overview of TGDC meeting and resolutions that were passed. Audience
zeroed in on software independence and systems with paper trails.
Strong objections from listeners were expressed. John stressed that
requirements were going to be passed on handling paper. Usability
issues were addressed. Vote Here expressed that they have machines
that can meet our requirements.
-
John
is looking at our progress to date and an overall view of what needs
to be done, especially as a result of the SI decision, with the hope
of being done in April/May. Should we be less stringent on requirements
because of SI?
Summary
and Status of STS Activities:
Changes
reflect the new table of contents that will appear in the VVSG2007.
Currently appears as:
Security
and audit architecture overview: Several draft white papers have
been written. John Kelsey is working to consolidate his papers and edit;
he is working with B. Guttman to get into right format. This is where
the threat analysis is housed, as well as assumptions, verifying integrity
of vote, and audit requirements. Ron mentioned we haven't discussed
specifics on auditing techniques. How do we handle the things that can
not be handled by the testing labs but need to be supported in this
document? Are procedures being handled in VVSG 2007? Usability of auditing
procedures and auditing techniques need to be included.
Profile
specific security and audit function overviews and testable requirements:
This covers paper record requirements, electronic records requirements
and other profile specific requirements. Draft requirements are written
for paper records; also an outline and white paper are written for electronic
records. John Kelsey is working on overall section with John Wack.
Profile
independent testable security requirements: This section is taking
the longest, with ten sub sections. Draft requirement written for cryptography;
key management under revision; access control, software distribution,
system event logging, and setup validation are largely written; system
integrity management and physical security have draft requirements under
revision. In the process of creating a new security documentation that
will be separate. Added section on minimum requirements supporting audits
and testing that was not specifically mentioned at TGDC meeting - this
is just a placeholder for now - this is a possible place for OEVT discussion.
Voting
systems innovation class: We have to come up with high level guiding
requirements that would help manufacturers get to certification and
a white paper discussing the evaluation process. Draft white paper done
on overview. Discussion still active on evaluation process. This is
a struggle to develop. Usability requirements in regards to security
were discussed. HFP subcommittee is only looking at user interaction
requirements. Innovation class design should be discussed among all
the subcommittee of the TGDC. Design guidance needs to be addressed
as well as performance. Requirements must be flexible - basics need
to be met - but we may not foresee all future designs.
OFF AGENDA
DISCUSSION: Audit requirements (in chapter 2) - issues regarding usability
and accessibility regarding paper based systems will be handed over
to HFP subcommittee.
At
the election center discussion (last week), manual counting was brought
up and issues about what could be done to make it easier. John Wack
talked about bar codes as a possibility. How do you write a usability
standard for this?
Where
are we in respect to volume testing and running a trial election and
a complete audit check? From a usability stand point, this testing would
point to "potential" problems. This is more for reliability
and performance testing. An entire set of operations for the voting
process (including audits) needs to be exercised and examined. Would
be nice to see a report from the public's point of view on use of equipment
before states purchase.
Would
be nice to see removal of impediments on new vendors. It is tough for
new vendors to sell equipment to states that already use certain vendors.
Caltech/MIT voting project is planning a small brain storming session
with academia and vendors to discuss new innovation class (not a public
meeting) in March.
Testing
Documentation: We will be working on this soon. OEVT draft white
paper has been prepared. This details how testing labs will test all
the equipment.
Discussion
of security related resolution and impact on security requirements:
David
Wagner questioned whether we should go easier on some of the requirements
now that SI is being included. If so, what should be done? Now that
we have an emphasis on auditability, it is appropriate to consider making
some "shoulds" to "shalls".
Looking
at the 3 resolutions that passed, we've already looked at innovation
class.
Next is
wireless security resolution: straight forward how requirements are
written and the implications on wireless technology.
Third
is software independence: specific questions and examples regarding
setup validation. Two categories of setup validation: the physical condition
of the system and the validation of the software on the system. How
does SI impact this? How much do we care about the accuracy of system
setup information before the election - these are still important. Cost
versus necessary functionality. With SI, you can audit after you vote.
Existing systems that don't offer SI need to continue to be certified
under 2007 standards, but new standards must have SI. "Grandfathering"
strategies will be developed by the EAC and are outside TGDC's scope.
Setup validation strategies will also be brought up to the EAC - requirements
are not useful if they're not used. Consensus on the phone call to reduce
setup validation requirements if there's a strong cost benefit to do
so, since we have independent verification. Nelson Hastings should come
up with possible changes/reductions.
NVLAP
will have accredited labs announced soon that will be able to test VVSG
2005 requirements.
Other
Items:
Tempest:
Dutch have de-certified voting machines because of strong tempest releases.
Should a standard be written? This is being handed to CRT subcommittee
to investigate.
Holt
Bill: What are the impacts on what we're doing if this is passed? Congressional
Hearings will be held in early February to discuss.
Next
teleconference - Tuesday, January 23rd at 10:30 a.m. EST
[* 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 served 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.]
|