EAC-requested VVSG Research Overview and Status June 2008 Mark Skall Chief, Software Diagnostics and...

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

Contents Overview of EAC-requested research

tasks NIST approach Status of each task Summary

Additional research EAC requested that NIST conduct

VVSG-related research Six 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 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

NIST research will contain options as appropriate, each with pros and cons

5

Task 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 To retain focus on security, alternatives to SI

have significant ramifications: Increased design and development costs Likely need for greater testing Modifications to the VVSG will require several 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 protocols Independent Verification (IV) – also known

as IDV Secure Audit Port

Remove SI restriction from Innovation Class

8

Overall strategy

SI - Auditability

Innovation Class

IVVR

Auditability

SI

IVVR

Independent Verification

(IV)

Secure Audit Port

End-to-End (E2E)

Innovation Class

Current draft next VVSG: With inclusion of alternatives:

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 SI restriction on innovation class could be removed How is auditability achieved?

Software independent approaches: IVVR requirements End-to-End protocols (E2E)

Independent Verification (IV) Secure Audit Port

E2E cryptographic protocols

What is an End-to-End (E2E) protocol (i.e., approach)?

Allows voters to Verify their votes are cast as intended Verify the election tally

Confidence in voting system and accuracy as a result of the cryptographic protocol

Election records are all electronic and encrypted for integrity


President

Governor

Receipt101001101010

Voting Stage

Voters

EncryptedBallot


Receipt101001101010

Verification Stage

Voters

Election Officials

Pros: Generally considered to be software independent Correct tally 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



What is Independent Verification? Two or more devices record cast

ballots Voter verifies that records match Also known as IDV (Independent Dual

Verification), is described as informative text in VVSG 2005

Independent VerificationVoting Device

Witness Device

PresidentGovernor

PresidentGovernor


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 Certification and interoperability issues Issues with same vendor building both devices

Secure Audit Port

What is a Secure Audit Port? Similar to Independent Verification One-way communication May not be direct voter verification Records voter and machine actions to

construct voter choices

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 Requirements alone may not be sufficient to ensure

correct results No audit device specifications in VVSG Medium-term effort (standardization)

Task 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

Task 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

If used as an accessible voting station, it may not meet interpretation of HAVA regarding accessibility

25

Task 4: Separately certifying components & interoperability

26

Develop a feasibility study of the ramifications of the EAC separately testing and certifying components

Research requirements for interoperability between systems and system components

NIST to research whether a specific standard for format of electronic election data can be required*These are all interrelated.

Testing & Certify Components

Change in philosophy, and potentially affects: VVSG (e.g., classes, requirements, etc) EAC procedures Test Lab processes, tests, reporting

Issues to consider, include: Which components? (e.g., all?, only those that plug & play?) Need new requirements for integrating components into the voting

system Define voting system architecture, interfaces, protocols, data formats, etc. Potentially restrictive to manufacturers, require hardware design changes

How do you ensure an integrated system works correctly and conforms to the VVSG?

Can’t test all aspects of voting system unless all components are configured Need new test methods to test for interoperability

Still need to test the voting system as a whole, i.e., “The system is more than the sum of its parts.”

Interoperability

28

Need to define what would be interoperable? Devices? (e.g., vote capture, tabulator) Data? (e.g., Ballot configurations, election results)

VVSG conformance testing does not address interoperability:

Conformance to a standard is necessary, but not sufficient, implementations may still differ

A separate interoperability testing program would need to be contemplated

Interoperability testing is between 2+ items Can be expensive and time consuming

Standardized Data Format

29

Current VVSG requirement = use standardized format

Allows manufacturer to determine format Translators can make data exchangeable

Selecting a specific standardized data format Must support all voting variations Should be vetted by U.S. voting system manufacturers Should be simple and unambiguous to implement Should first demonstrate that it can enable interoperability

(i.e., achieve the objective for a standardized format) Format standard must be explicit with respect to

data structures, data definitions, allowable data values, etc.

Current Standardized Data Formats

30

Standardization efforts: IEEE’s data format standard (project 1622) on hold Hart’s EDX is proprietary OASIS EML is an international standard, not originally built with US

elections in mind EML = dialect of XML + many schemas that define different aspects of

election (e.g., ballot, cast vote, count) Can’t use EML as is Just specifying EML is not enough – need to specify specific schemas Gaps - not all voting variations handled Potential for defining non-conforming EML schemas to handle U.S.

requirements Limited implementation and experience using it

Prior to selecting EML Need additional research to ensure it meets needs of election officials Need to identify, refine, tailor, and build schemas for U.S. use – not

trivial Need to develop data model with all voting processes and variations Need input and consensus from election officials, vendors

Task 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

31

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

32

Task 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

33

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 requirements

35

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

36

Summary

37

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

EAC-requested VVSG Research Overview and Status June 2008 Mark Skall Chief, Software Diagnostics and...

Documents

Transcript of EAC-requested VVSG Research Overview and Status June 2008 Mark Skall Chief, Software Diagnostics and...