Update on the UOCAVA Working Group - PowerPoint PPT Presentation

1 / 31
About This Presentation

Update on the UOCAVA Working Group


Update on the UOCAVA Working Group Andrew Regenscheid Mathematician, Computer Security Division, ITL http://vote.nist.gov – PowerPoint PPT presentation

Number of Views:7
Avg rating:3.0/5.0
Slides: 32
Provided by: Andrew1129
Learn more at: http://www.nist.gov


Transcript and Presenter's Notes

Title: Update on the UOCAVA Working Group

Update on the UOCAVA Working Group
  • Andrew Regenscheid
  • Mathematician, Computer Security Division, ITL
  • http//vote.nist.gov

  • The TGDC UOCAVA working group has three
    outstanding task items
  • High-level guidelines for UOCAVA voting systems
  • Narrative risk analysis on current UOCAVA voting
    process and demonstration project system
  • Low-level guidelines for demonstration project

Page 2
Meeting Objectives
  • This session of todays meeting has three
  • Decide how to proceed on the high-level
    guidelines, including decisions on
  • Intended scope and purpose
  • Auditability/verifiability guidelines
  • Usability/accessibility guidelines
  • Resolution of FVAPs comments
  • Decide on a course of action for conducting a
    risk analysis on the current UOCAVA voting
  • Discuss process/timeline for approaching
    demonstration project guidelines

High-Level Guidelines
  • EAC and the TGDC, with technical support from
    NIST, and input from FVAP, will identify
    high-level, non-testable guidelines for remote
    electronic absentee voting systems. This effort
    will focus on the desirable characteristics of
    such systems and serve as a needs analysis for
    future pilots and research and for the purposes
    of driving industry to implement solutions.

High-Level Guidelines
  • Purpose
  • Fulfill charge from UOCAVA Roadmap
  • Interpreted the UOCAVA Roadmap language as asking
    for aspirational, high-level guidelines intended
    to identify goals for future UOCAVA voting
  • Intent is that these high-level guidelines would
    form basis for the development of low-level
    guidelines for the demonstration project and
    future UOCAVA voting systems
  • Scope
  • Included both demonstration project systems and
    future systems
  • Guidelines intended to be all-encompassing,
    covering roughly the same scope as future
    low-level guidelines

High-Level Guidelines
  • Goal was to identify a small number (25)
    high-level guidelines that covered all important
  • Build consensus around high-level concepts, and
    flush out details in low-level guidelines for the
  • Emphasis on aspirational goals- we recognized
    some may not be achievable today

High-Level Guidelines Topics
  • Current high-level guidelines draft includes
  • Voting functions
  • Auditability
  • Quality assurance and configuration management
  • Reliability and availability
  • Usability and accessibility
  • Security
  • Interoperability

High-Level Guidelines Process
  • NIST staff initially drafted high-level
    guidelines in sections using
  • Earlier drafts of high-level guidelines
  • Council of Europes Legal, Operation and
    Technical Standards for E-Voting
  • Research done to support VVSG development
  • Existing relevant standards
  • UOCAVA and UA working group members reviewed and
    edited guidelines
  • Properties of the current UOCAVA voting system
    were taken into consideration, but did not limit
    the guidelines

Voting Functions
  • Primary, basic guidelines expected from any
    voting system, e.g.,
  • One cast ballot counted per voter (hlg-2, 3)
  • Accurate and reproducible vote counts (hlg-4)
  • Supply voters with correct ballot style (hlg-5)
  • Some were derived from CoE E-Voting standard

  • Primary guideline The UOCAVA voting system
    shall create and preserve evidence to enable
    auditors to verify that it has operated correctly
    in an election, and to identify the cause if it
    has not.
  • Two controversial proposed guidelines
  • The audit system shall provide the ability to
    compare records and verify the correct operation
    of the UOCAVA voting system and the accuracy of
    the result, in an effort to detect fraud, to
    prove that all counted votes are authentic and
    that all authentic votes have been counted as
  • The UOCAVA voting system shall make it possible
    for voters to check whether their vote was cast
    and recorded as they intended, and shall make it
    possible for observers to check whether all cast
    votes have been counted and tallied correctly.

Quality Assurance and Configuration Management
  • System must be fit for use
  • System must be developed, monitored and
    maintained in accordance with applicable best
    practices for quality assurance
  • Documented, tested, and stable configuration
  • Guidelines based on research done to support VVSG
    2.0 draft

Reliability and Availability
  • Definition of critical failure any functional
    failure, the occurrence of which jeopardizes the
    validity of the election, or casts doubt on the
    credibility of the election result
  • Probability of critical failures and overall
    system availability must be fit for intended use
    (hlg-1, 3)
  • Assure reliability of system through application
    of best reliability engineering practices and
    standard reliability analysis procedures
  • Based on CoE guidelines and supporting VVSG 2.0

  • Security guidelines were developed accepting
    risks of the current mail-system, e.g.,
  • Low-level compromises of ballot secrecy is
    accepted (hlg-2)
  • Some low-level fraud accepted- the goal is to
    prevent an undetectable change in the outcome of
    the election (hlg-3)
  • Some new issues unique to electronic systems
  • Strong user authentication for voters,
    administrators, officials (hlg-1)
  • Systems must be free of vulnerabilities that
    allow remote attacks (hlg-4)
  • Prevent malicious software on terminals from
    impacting election integrity (hlg-5)
  • Recommended use of penetration testing (hlg-6)

User-Centered Development (hlg-1)
  • Develop with best practices in user-centered
    design and user testing
  • Incorporate these principles throughout the
    system development cycle and as part of
  • Evaluate system usability and accessibility via
    user testing with representative test
  • Include usability evaluation of procedures and
    documentation for system administration

Accessibility (hlg-2, 5, 7)
  • Make system accessible to voters with
  • Built-in access features
  • Interoperability with personal assistive
    technology (PAT)
  • PAT as supplemental rather than necessary to
    ensure system accessibility
  • Maintain privacy and independence throughout all
    phases of voting process
  • Ballot marking, verification, and casting
  • Voter has same accessibility accommodations
  • Comply with legal mandates

Best Design Practices (hlg-3, 4, 6)
  • Follow human factors design best practices, for
    both system and ballot design where possible
  • EACs report Effective Designs for the
    Administration of Federal Elections
  • American Institute of Graphic Arts (AIGA)s
    report Top 10 Election Design Guidelines
  • Adhere to current standards and guidelines
  • VVSG
  • World Wide Web Consortium (W3C)s Web
    Accessibility Initiative (WAI), specifically the
    Web Content Accessibility Guidelines (WCAG 2.0)
    and WAI for Accessible Rich Internet Applications

More on Ballot Design
  • FVAP expressed some concern over including ballot
    design in the high-level guidelines
  • To clarify
  • High-level guidelines are not intended to
    supersede State laws
  • Election Officials control formatting of ballot
  • High-level guidelines are intended to address
    only those ballot design features controlled by
    the UOCAVA system
  • For example, navigation and user interface
  • UOCAVA system should support implementation of
    good ballot design

More on Accessibility
  • FVAP requested high-level guidelines focus on the
    demonstration project, which would limit the
    scope of accessibility
  • Suggested that only Section 508 be referenced
  • Implications of this are unclear
  • Section 508 does require accessible design and
    some PAT interoperability
  • Section 508 Refresh on the horizon
  • How much of W3Cs WAI guidelines should be
    implemented in the demonstration project?
  • Will we learn enough about accessibility from the
    demonstration project to inform future work?

  • Open issues
  • Intended scope and purpose
  • Auditability/verifiability guidelines
  • Usability/accessibility guidelines
  • Resolution of FVAPs comments

Next Topic Risk Analysis
Page 19
Risk Analysis
  • TGDC Resolution 02-11 directs the UOCAVA Working
    Group to prepare a narrative risk assessment
    comparing the current UOCAVA voting process to
    electronic absentee voting systems used in a
    demonstration project with military voters.
  • Currently, the demonstration project system is
    not defined
  • First step analyzing risks in current UOCAVA
    voting process

Risk Analysis Transactional Failures
  • Current UOCAVA process has a number of
    transactional failure points between voter
    registration and ballot canvassing
  • Voter registration failures
  • Ballot delivery failures
  • Ballot marking errors
  • Ballot return failures
  • These failures are observable and measurable
  • An analysis of these failures can lead us to an
    overall failure rate of the current process

Risk Analysis Identifying Risks
  • Transactional failures are only one type of risk
  • The UOCAVA working group can analyze one or more
    representative current UOCAVA voting processes to
    identify other potential risks
  • What is the potential vulnerability?
  • Who is in a position to exploit it?
  • What is the impact of a successful exploit?
  • What is the probability of a successful exploit?
  • Challenge 1 Impacts are not always easily
    quantifiable in comparable units. What is the
    value of a vote?
  • Challenge 2 Probabilities for malicious attacks
    are notoriously difficult to estimate

Risk Analysis Comparing Risks
  • It will be important to compare and balance risks
    between different types of systems, as well as
    different types of risks within a given system
  • We can create quantifiable comparisons of impact
  • Example Comparing the impact of lost ballots and
    tampered ballots to the outcome of the election
  • Collaboration with NIST Statistical Engineering
  • Explore use of EAC Election Operations Assessment
  • Qualitative comparisons will be done in other
    areas, such as malicious attacks or risks

  • Feedback on Risk Analysis Path Forward

Next Topic Demonstration Project Guidelines
Page 24
UOCAVA Demonstration Project
  • Work is building up to the implementation of a
    remote voting demonstration project for military
  • EAC has tasked the TGDC in developing guidelines
    for the demonstration project system
  • TGDC Resolution 02-11 stated TGDCs acceptance
    of this task, and directed the TGDC to develop
    guidelines for a demonstration project with
    simplifying assumptions
  • Military voters only
  • Use of Common Access Card (CAC) for
  • Use of professionally-administered machines

(No Transcript)
Mitigated Risks
  • The simplifying assumptions mitigate some risks
    identified in NISTIR 7551 A Threat Analysis on
    UOCAVA Voting Systems
  • Use of CAC mitigates authentication-related
    risks, including voter impersonation and phishing
  • Digitally signed ballots using CAC could mitigate
    some malicious attacks on servers
  • Use of professionally-administered machines
    mitigates risk of malicious software on voting
    terminals impacting ballot secrecy or integrity
  • Use of military network could help to mitigate
    some remote attacks on servers

Page 27
Other Risks
  • Other risks may need to be mitigated by other
    means, pending results of risk analysis
  • Network-based attacks may not be mitigated by the
  • Internet voting systems inherit many of the same
    potential risks as electronic polling place

Page 28
Demonstration Project Prerequisites
  • Several items need to be completed prior to
    development of demonstration project guidelines
  • TGDC tasked with the high-level guidelines and
    risk analysis
  • TGDC/NIST also need
  • Concept of operations of the demonstration system
  • Expected high-level system architecture
  • Clearly defined scope for demonstration project
  • How extensive will this project be? One-time
  • What functions must be provided?
  • Who decides appropriate tradeoffs and accepts

Demonstration Project Timeline
  • Current work complete near-term deliverables
    (i.e., high-level guidelines and risk analysis)
    intended to inform low-level guidelines
  • Demonstration project guidelines expected to take
    24 months to develop, vet through a public
    comment period, and approve in TGDC and EAC
  • 12 month development process
  • 6 month vetting process
  • 6 month revision process
  • For a 2016 demonstration project, guidelines
    would be needed by mid-2014

Page 31
Write a Comment
User Comments (0)
About PowerShow.com