Voters want to be confident that their votes have been counted as cast and that their anonymity has been maintained. Election officials want to be certain that their voting equipment, voting systems, and overall processes have functioned correctly from start to finish and that the will of voters has been truly expressed.

The path to provably secure, high assurance, open source election systems capable of protecting elections and providing such certainty may seem daunting. However, the process of achieving that goal can be broken down into a series of useful, common sense steps, each of which positively affects current election systems and processes. We consider these steps in three phases, starting with the most basic and building to fully trustworthy and transparent systems and vendor relations.

Phase I: Audits, testing, and a security mindset

Adopt a security mindset

The first step you can take is to consciously adopt a security mindset. This does not have to be a costly undertaking—it is more a shift in perspective. You should begin to work from the assumption that “bad guys” will try to hack your systems and manipulate your elections, and constantly seek ways to improve security within your existing systems and processes.

If nobody in your office is up to date on technology trends in security and cryptography, consider reaching out to your local university’s computer science department. An intern or software engineer who can think like a hacker can be your security eyes and ears.

Risk-limiting audits

An easy way to increase confidence in election results is to conduct risk-limiting audits (RLAs). This is a straightforward process requiring relatively little resources or technology. It may even be something the computer science student you hired to help you with security could learn in a day. Qualified third parties can also conduct RLAs for you. An RLA is essentially a random check of a relatively small number of ballots to determine whether the digital cast vote records in your system match their corresponding paper ballots. If an election is not extremely close, an RLA can statistically show whether the tabulated results are correct using a surprisingly small number of ballots.

Parallel testing

To help quickly detect any technical issues that may arise on Election Day, you can conduct parallel testing. This involves casting test ballots on a number of randomly selected voting stations under conditions that simulate actual Election Day usage. In such tests, the ballots used are known to the testers and can be compared to the recorded results.

If you conduct both parallel testing and a post-election RLA on the results you will know with great certainty whether anything has gone wrong with your process or equipment, all with very little expense.

Phase II: Improving the RFP process

Part of the reason that high assurance, open source election systems are not yet widely prevalent is that few jurisdictions specifically require them. Election vendors, in turn, create systems that only satisfy the requirements put forth by the jurisdictions. They then offer those systems to other jurisdictions to save on costs. To break out of this vicious cycle, RFPs must explicitly promote more trustworthy systems and reward practices that are in the long-term interests of jurisdictions, especially in terms of providing greater flexibility and control. The following four aspects are key:

  • Open the bid process to greater competition.
  • Allow for a modular implementation approach.
  • Demand evidence backing up vendor claims.
  • Demand price transparency and allow for the use of commercial off-the-shelf (COTS) hardware.

Competition

RFPs that only legacy election vendors can win reduce competition, impeding innovation and slowing progress. Most RFPs have preconditions that essentially eliminate competition by posing nearly insurmountable barriers to entry, including for reputable vendors with years of relevant experience.

To encourage competition, jurisdictions should consider the following requirements: national or international experience in elections; expertise in designing, implementing, and deploying mission-critical systems; peer-reviewed evidence of best-in-class work; and strong referrals at the local, state, and federal level relevant to mission-critical systems.

High assurance, open source techniques currently used to develop mission-critical systems would greatly increase security and trustworthiness if applied to election systems. However, the organizations capable of designing and building such systems have little incentive to do so if there are no potential customers. Opening up RFPs to competition on these fronts would encourage such development and innovation.

The benefits of encouraging competition and new entrants are not limited to technology choice and critical systems expertise. Competition can also drive down costs as more vendors start to respond to the market need for secure and transparent election systems.

Modular Approach

Most current election systems are monolithic, meaning that their individual parts cannot be distinguished or separated. This leads to a variety of issues after systems have been purchased and put into service. A modular approach gives jurisdictions far more flexibility and control.

For example, imagine that a jurisdiction using a monolithic election system really likes their current ballot design system, but has decided based on audit results from multiple elections that the voting machine software is insecure or inaccurate. They have only two options: first, they can replace the entire system, losing the ballot design system they have already paid for; second, they can ask the vendor (that has already supplied them with software they dislike) to fix the system. This puts the jurisdiction at the mercy of the vendor.

With modularity, there is a third option: the jurisdiction can reach out to a qualified software vendor of their choice and request a drop-in replacement for the part of the system that they dislike.

Modular systems are made possible through the use of open APIs and open data formats. This approach is beginning to impact the nature of federal and state RFPs, as witnessed in the Healthcare.gov reboot at the federal level and in new compositional, agile, open interface-based RFPs coming out of the state of California. Moreover, the U.S. Election Assistance Commission (EAC) and the National Institute of Standards and Technology (NIST) are moving toward a component-based certification process in the next version of the Voluntary Voting System Guidelines (VVSG).

Evidence of Vendor Claims

It is easy to claim something if there is no way to disprove your claim, and hard to disprove security claims made by companies that sell closed source, proprietary systems. Jurisdictions should demand verifiable evidence from vendors during the RFP process rather than taking vendor claims at face value. Examples of verifiable evidence include federal or state certification, audits, and penetration tests by red teams, which are groups that act as malicious hackers to test the security of a system.

Price Transparency & COTS Hardware

Trustworthiness in election systems is not limited to the technology itself, but also includes pricing and support. Jurisdictions should be just as suspicious of “black box” pricing models as they are of “black box” voting systems. It should be easy to tell how much an election system will cost based on the size of the voter population it will serve.

It is also important to encourage vendors to provide options that allow for the secure use of COTS hardware, which can lower costs and provide much greater flexibility and control. Elections software that only operates on proprietary hardware makes it impossible for a jurisdiction to change vendors without replacing their entire voting system. This puts the jurisdiction at the mercy of a single vendor with respect to upgrade or maintenance pricing. If the software runs on COTS hardware, however, the cost of an upgrade is limited to the cost of the new software, which can be provided by many possible vendors. Pricing is also typically far better for COTS hardware because of the competitive market for computers and tablets.

Phase III: Trustworthiness and Transparency

If you implement the steps in Phases I and II, you will have more affordable, more maintainable election systems and be able to detect any abnormalities that occur on Election Day. However, if something does go wrong, whether a technical malfunction or the work of a bad guy determined to disrupt the election, you will still have to fix it. That may involve a labor-intensive manual recount or even an expensive re-run of the entire election, with accompanying public relations issues and potential loss of voter confidence in both the election outcome and the election system as a whole. Clearly, it would be better to have a trustworthy election system that prevents such problems, with reliable vendors who stand behind it long-term.

There are three key ingredients to the realization of fully trustworthy and transparent systems and vendor relations:

  • Transparent, open source solutions
  • High assurance techniques that provide verifiable evidence of correctness and security
  • Comprehensive vendor culpability and warranty

Open Source Solutions

Open source software encourages security practices that are worthy of trust. Based upon numerous audits, software leaks, and Freedom of Information Act responses, it is clear that existing, closed source voting systems rely on attackers not knowing details about their implementations. If existing systems were made open source, it is extremely likely that many vulnerabilities would be rapidly discovered.

To be most valuable to election officials and voters, open source software in the elections space must have two characteristics. First, jurisdictions who purchase software from a vendor should have full access to, and ownership of, the source code and be able to freely modify the software to serve their own future needs and to hire other companies or individuals to carry out such modifications on their behalf. Second, voters and other interested citizens should have full, immediate, and unimpeded access to inspect the source code. They should also be free to publicly state their observations about the source code and related artifacts, with no restrictions.

High-Assurance Techniques

High-assurance systems are built in such a way that it is possible to prove with mathematical certainty that they work precisely as intended and as designed. These systems provide clear, digital evidence that can be checked by third parties to prove that they work exactly as intended—no more, no less.

High-assurance techniques have been used for decades to produce critical chips and software, mostly for national security purposes. However, they have only recently become powerful and affordable enough to produce large pieces of software like election systems. We strongly believe that democracy should be treated as a critical system, and that voting should be conducted using high-assurance systems.

Vendor Culpability and Warranty

For most physical infrastructure, such as bridges and buildings, architects and engineers can be held liable for design defects and any damages caused by such defects, and contractors can be held liable for defects in workmanship. For example, a civil engineer who claims that a bridge built according to their design can withstand certain weather conditions and bear a certain amount of weight can be found culpable if a bridge actually built to that design fails under those conditions. This is one reason why we see remarkably few failures of bridges, skyscrapers, and other incredibly complex engineering projects.

For computing systems, however, the vast majority of vendors explicitly disavow any liability for defects or damages. Most software license agreements contain language stating that there is absolutely no warranty provided, including warranty of fitness for any particular purpose, and that the vendor is not liable for any damages, of any kind, caused by the software whether it is used properly or not. Most hardware does have warranty protection of some kind, but vendor liability is typically limited to the cost of the hardware regardless of how the hardware fails or what damages such failure causes.

This is unacceptable for critical systems, and customers who need high assurance should demand that software and hardware developers accept liability. Election systems are critical infrastructure, and election vendors should stand behind the systems they design and build just as architects and civil engineers do.

Democracy is a critical system

We strongly believe that democracy is a critical system, and that voting should be conducted using high-assurance systems like those that maintain our physical infrastructure and our national security. Jurisdictions that follow the path laid out here will be able to conduct elections that are worthy of the trust placed in them by voters, candidates, and officials alike. Their elections will run more smoothly from start to finish, and all stakeholders will have the highest level of confidence in the results.

A bill proposed during the 2016 Florida legislative session would have given election supervisors around the state a raise because for decades they have been paid less than their fellow constitutional officers, like tax collectors and property appraisers. The pay disparity stems from the fact that in the past the job of election supervisor was perceived as mostly clerical. Their primary duty was tallying paper ballots every two years. The elections world has clearly come a long way since those days, and it is time for election systems to catch up as well.