In a recent posting, I noted that despite current voting systems’ basic flaws, it is still possible to do more to provide the public with details that can provide peace of mind that close contests’ results are not invalid due to technology related problems. Now I should explain what I meant by basic security flaws, especially since that was the topic of a panel I was part of recently, a group of security and/or election professionals on addressing a DHS meeting on security tech transfer.

We agreed on three basic security and integrity requirements that are not met by any existing product:

  1. Fixed-function: each machine should run only one fixed set of software that passed accredited testing and government certification.
  2. Replace not modify: that fixed software set should be able to be modified, and can updated only by being replaced with another certified system.
  3. Validation: all critical components of these systems are required to support election officials’ ability to validate a machine before each election, to ensure that it remains in exactly the same certified configuration as before.

These critical properties are absent today, because of a basic decision made by vendors years ago, to quickly bring new voting technology to market by basing it on ordinary turn of the century PC technology that was, and remains in today’s market, fundamentally unable to support fixed function systems inherently capable of validation. All voting systems today lack these basic properties, and without them, all other security requirements are largely irrelevant — and compliance with current certification requirements is impossible.

Crazy, eh? Then add to that:

  • the remarks of panelist and voting system security expert Matt Bishop of UC Davis on the many software-level security functional problems encountered in reviews of voting systems, problems found despite the official federal testing and certification process intended to find them; and
  • Virginia’s Election Commissioner Edgardo Cortez’s examples of system-level security issues found in their review of voting system that was subsequently banned for use in VA. A few minds were blown in the audience.

The Consensus and One More Thing

The consensus at this DHS event, for both panel and audience, was that any future voting system that is worth having, should be validated by a future testing and certification process that among other goals, specifically required the architecture-level security requirements that I outlined, and focused on the types issues Cortez and Bishop described – and one more thing that’s important for completely different reasons.

That one more thing: future voting systems need to be designed from scratch for ease of use by election officials, so that they don’t have to take today’s extra-ordinary measures with so much human-level effort and human-error-prone work needed to operate these systems with reasonable security that can be demonstrated in the event of disputes.

So, leaving aside “known unknowns” about recent hacks or lack thereof, we have some really important “known knowns” – there is enormous potential for improvement in a wholesale replacement of voting tech that meets the 3 basic integrity requirements above, can be feasibly examined for the issues that our panelists discussed, and can be easily safely operated by ordinary election officials.

— John Sebes