eac-requested vvsg research overview and status june 2008 mark skall chief, software diagnostics and...
Post on 18-Jan-2018
219 Views
Preview:
DESCRIPTION
TRANSCRIPT
EAC-requested VVSG Research Overview and Status
June 2008
Mark SkallChief, Software Diagnostics and Conformance
Testing DivisionNational Institute of Standards and Technology
1
6/17/2008 Page 2
Contents Overview of EAC-requested research
tasks NIST approach Status of each task Next steps
Additional research EAC requested that NIST conduct
VVSG-related research 6 items in response to Standards
Board/Board of Advisors resolutions from Dec 2007 meetings
Final results to EAC Sep 2008
3
Overview of six items1. Alternatives to software independence2. Developing standards for ballot on demand
systems3. Impact of the VVSG on vote by phone systems 4. Ramifications of separately testing and certifying
components plus requirements for interoperability5. Impact of the VVSG on early voting or vote centers6. Developing alternatives to goal level requirements
in the VVSG
4
The NIST role EAC, not NIST, makes decisions wrt VVSG
requirements NIST research will contain options as
appropriate, each with pros and cons NIST goal is to provide useful data for EAC
decision making: Provide complete set of options Include any ramifications to other EAC activities, e.g.,
certification, testing Think outside the box and be creative
5
1. Alternatives to software independence
Should retain focus on security, verifiability, and auditability in the VVSG
Research should be conducted on what changes need to be made to the VVSG to accommodate each alternative
6
Current analysis While various alternatives to SI exist, they all
have significant cons: Increased design and development costs Need for more rigorous and expensive testing Will take at least 3 years to develop:
Will require significant research Will require standardization efforts Need for funding or possible development incentives
Could be major ramifications to other areas of the VVSG that will need further study, e.g., usability, accessibility
7
Approaches under consideration
Along with IVVR, conforming alternatives could include
End-to-end (E2E) cryptographic approaches Independent Verification (IV) Systems – also
known as IDV Secure Audit Port requirements Also, remove SI restriction from Innovation
Class
8
Page 9
Overall strategy
SI - Auditability
Innovation Class
IVVR
Auditability
SI
IVVRIV Audit Port
E2EInnovation Class
Current draft next VVSG: With inclusion of alternatives:
Page 10
Overall strategy Make auditability, not SI, an overarching requirement Moves focus to the trustworthiness of audit records Allows some reliance on software based on trust in audit
records How is auditability achieved?
Software independent approaches: IVVR E2E systems
Independent verification systems Secure audit port Innovation class without SI restriction
Page 11
E2E cryptographic approaches
What is an E2E system? Allows voters to verify votes cast as
intended, counted as cast Strength of crypto algorithm for
encoding/decoding ballots is proof of correctness
Audits can be much simpler, voters can self-audit own ballots
Usability and accessibility issues easier to address
E2E cryptographic approaches
PresidentGovernor
Receipt101001101010
Voting Stage
E2E cryptographic approaches
Receipt101001101010
Remote access
Home PC
Verification Stage
Pros: Generally considered to be software independent Election is verifiable by public Electronic audit records
Cons: Emerging technology Usability/Accessibility issues to be addressed Long-term effort (research, standardization,
implementation) No commercially available implementations
E2E cryptographic approaches
Page 15
Independent Verification Systems
What is independent verification? Two or more devices record cast ballots Voter verifies that records match Alternatively, one of the devices is a trusted device
Page 16
Independent Verification Systems
Voting Device
Witness Device
PresidentGovernor
PresidentGovernor
Independent Verification Systems
Pros: Electronic audit records Redundant independent cast vote records Usability/Accessibility potentially easier to address than
with IVVR Possibly an add-on technology to current voting systems
Cons: Software dependent Long-term effort (research, standardization,
implementation) Limited commercial availability Architectural building a trusted device Certification and interoperability issues
Page 18
Secure audit port What is a secure audit port?
Similar to Independent Verification systems One-way communication May not be direct voter verification Records voter and machine actions to
construct voter choices- not necessarily cast vote records
Page 19
Secure audit port
Audit Device
Voting Device
President
Governor
Secure audit port Pros:
Electronic audit records Allows for audit device innovation Allows choice of audit devices Similar to existing commercially available architectures
Cons: Software dependent Certification and interoperability issues Security dependent on audit device functionality No audit device specifications in VVSG Medium-term effort (standardization)
2. Ballot on demand BOD: device that can print ballots on
demand for use in elections Reduces need to pre-print and transport ballots
to polling place NIST to research the feasibility of including
BOD requirements in the VVSG Do election official needs require further
research before requirements can be written?
21
Current analysis BOD not a mature product yet Earlier NIST research with EAC boards
identified diversity of opinions on what BOD should encompass A backup EMS application for emergencies A dedicated application possibly integrated
with an epollbook Somehow integrated with a DRE
22
Feasible, but NIST would need to conduct more research to focus on specifics
VVSG impacts BOD in various ways Core: reliability, accuracy, misfeeds Security: ballot accounting, voter privacy,
forgery-proof paper Human factors: usability for voters and poll
workers, suitability for audit, accessibility
Current analysis (cont)
23
3. Vote by phone systems VBP: voters use telephones and
guided prompts to place votes, electronic and paper ballots printed out at remote office
Does the VVSG, as written, prohibit VBP?
24
Analysis Is feasible to permit VBP, but
Will require some reworking of VVSG device class structure
Will require strong cryptography and other communications security
Would need to research usability of guided prompts for voters
May not meet interpretation of HAVA regarding accessibility
25
4. Separately certifying components, interoperability of
data format
26
1. Develop a feasibility study of the ramifications of the EAC separately testing and certifying components
2. Research requirements for interoperability between systems and system components
3. NIST to research whether a specific standard for format of electronic election data can be required
Current analysis
27
VVSG conformance testing does not address interoperability:
Adherence to a standard is alone not sufficient, implementations will still differ
A separate interoperability testing program would need to be contemplated
There is still a need to test the voting system as a whole, i.e., “The system is more than the sum of its parts.”
A voting system architecture would need to be specified to know what needs to be interoperable
Current analysis (cont)
28
Premature to require a specific standard for the format of election data, more vetting needed Whatever chosen should natively support all
voting variations in the VVSG Should be vetted by U.S. voting system
vendors Interoperability should be demonstrated
5. Early voting & vote centers
Addresses questions as to whether VVSG prohibits or impacts use of voting equipment in early voting or vote centers
Especially of concern with regard to use of epollbooks
29
No impacts seen, CRT requirements accommodate early voting and vote centers VVPAT requirements anticipated multi-precinct
use of equipment Electronic poll book requirements permit
network connections to central voter registration databases
Caveat: cannot network poll books to vote capture devices and databases at same time
Current analysis
30
6. Goal level requirements Identifying goal level requirements
Requirements that can identify goals but are untestable
Requirements that could be tested but testing will be subjective and non-repeatable
31
Page 32
Why Goal Requirements? Some requirements express a goal
to be met by the vendor Is kind of a performance
requirement, but without clear performance measures
Often done to avoid constraining design requirements
Obvious examples Systems SHALL maximize integratability with
other systems and/or devices of other systems. Goal is for interoperability, but is untestable
The procedures for system setup, polling, and shutdown, as documented by the manufacturer, SHALL be reasonably easy for the typical poll worker to learn, understand, and perform.
Testing will be subjective It will be non-repeatable
VVSG has roughly 20-30 goal level requirements33
Could be deleted or included as informative text or as “should” requirements
Additional research could be conducted to make the requirements more specific Trade-offs exist as to amount of research Expert judgment may suffice in some cases
Current analysis
34
Summary
35
Snapshot of current analysis was presented Research is very preliminary NIST vetting is not complete Analysis could change by September
Final document due in September
top related