Elections in five states have used or plan to use OmniBallot’s online voting tech.OmniBallot is election software that is used by dozens of jurisdictions in the United States. In addition to delivering ballots and helping voters mark them.
it includes an option for online voting. At least three states—West Virginia, Delaware, and New Jersey—have used the technology or are planning to do so in an upcoming election. Four local jurisdictions in Oregon and Washington state use the online voting feature as well. But new research from a pair of computer scientists, MIT’s Michael Specter and the University of Michigan’s Alex Halderman, finds that the software has inadequate security protections, creating a serious risk to election integrity.
Democracy Live, the company behind OmniBallot, defended its software in an email response to Ars Technica. “The report did not find any technical vulnerabilities in OmniBallot,” wrote Democracy Live CEO Bryan Finney.
This is true in a sense—the researchers didn’t find any major bugs in the OmniBallot code. But it also misses the point of their analysis. The security of software not only depends on the software itself but also on the security of the environment on which the system runs. For example, it’s impossible to keep voting software secure if it runs on a computer infected with malware. And millions of PCs in the United States are infected with malware.
The issue has particular urgency right now because the ongoing COVID-19 pandemic is forcing election officials to make significant changes to election procedures. Right now, most jurisdictions using the OmniBallot software don’t use its “electronic ballot delivery” feature. But enabling the feature would require little more than a configuration change. There’s a risk that election officials, under pressure to make remote voting easier, will decide to enable the software’s online voting feature for this November’s general election.
How OmniBallot works
Experimenting with a live election system would be unethical and likely illegal. Instead, Specter and Halderman obtained a copy of the OmniBallot software, reverse-engineered it, and then created new server software that mimicked the behavior of the real server. This allowed them to experiment with the software without risking interference with a real election.
OmniBallot offers a number of different capabilities that state election officials have the option to offer to voters. The most basic is a blank ballot delivery feature that will provide a voter with a PDF ballot that can be printed out and mailed back to the polling place.
Jurisdictions can also offer a ballot-marking feature, which will mark a ballot on the voter’s behalf before it’s printed out. This can enable blind voters to fill out a ballot independently. It can also prevent overvotes (voting for two or more candidates) and warn voters about undervotes (failing to vote in a race).
But Specter and Halderman argue that this capability comes with some added risks. Malicious software could be programmed to switch votes some fraction of the time. Theoretically, voters are supposed to check that the votes are correct before mailing in their ballot, but research suggests voters are lax about doing so. One study by Halderman and others found that only 6.6 percent of voters in a realistic mock election reported a changed vote to election supervisors.
By default, the software generates the marked ballot PDF on an OmniBallot server, not on the user’s own device. This creates an unnecessary risk to the privacy of the voter’s ballot, Specter and Halderman argue, since it means that Democracy Live gets an unnecessary copy of the voter’s votes.
Fortunately, Democracy Live also offers an option for client-side ballot marking. Andrew Appel, a computer scientist at Princeton, told Ars that this option was added at the insistence of California officials who objected to server-side ballot marking. When this option is chosen by election administrators, the ballot is marked on the user’s own device, without sharing the data with Democracy Live’s servers. The computer scientists recommend that all jurisdictions using OmniBallot’s ballot marking feature switch to the client-side version of the software.
The problems with online voting
While there are some security concerns with ballot-marking software, the researchers say that these problems pale in comparison to security vulnerabilities of OmniBallot’s “electronic ballot delivery” system.
The fundamental problem is that the complexity and opacity of online voting systems creates numerous opportunities for a hacker to tamper with a ballot during the submission process. Malware on the client device could modify the ballot before it’s transmitted to Democracy Live’s servers. OmniBallot is built on Amazon Web Services using JavaScript libraries delivered by Google and Cloudflare. So hackers or malicious insiders at any of these companies could potentially alter ballots if they had access to one of these companies’ systems.
And the nature of online voting means there’s no reliable way for a voter to verify that a ballot was transmitted correctly. Software engineers have developed theoretical designs for voting systems with end-to-end security. These systems use sophisticated cryptography to enable voters to cryptographically verify that their vote has been counted correctly. But Democracy Live doesn’t do anything like that. In their paper, Specter and Halderman describe how an attacker could exploit the lack of end-to-end verification.
“The web app would show a ballot containing the selections the voter intended, but the ballot that got cast would have selections chosen by the attacker,” they write. “The attack would execute on the client, with no unusual interactions with Democracy Live, so there would be no way for the company (or election officials) to discover it.”
Auditing doesn’t fix the problem
Democracy Live conducts post-election audits using Amazon’s AWS CloudTrail software to verify that no Democracy Live employees abused their access to company servers. These checks could detect some forms of election tampering, but Specter and Halderman point out that they are far from foolproof.
These methods wouldn’t detect any attacks executed from the client side. If malware on a user’s PC modified the user’s ballot before sending it to Democracy Live’s servers, that wouldn’t show up in the CloudTrail logs. If someone with access to Google or Cloudflare servers delivered malicious JavaScript libraries to OmniBallot users, that wouldn’t show up in AWS logs. Someone with administrative access to Amazon’s servers might be able to modify Democracy Live’s software in a way that wouldn’t show up in the logs.
Of course, most of these attacks wouldn’t be trivial to pull off. Google, Amazon, and Cloudflare are three of the most sophisticated software companies in the world and take elaborate precautions to defend their systems. The audit I linked to above is from an election for the King County Conservation District. It’s farfetched that anyone would go to so much trouble to attack such a low-stakes election.
But sophisticated attacks would become far more plausible if the software were used to elect members of Congress and even the president. In that case, we can imagine foreign governments like Russia or China being willing to invest significant resources to compromise election results in a way that’s difficult to detect. We don’t know the full extent of these countries’ offensive capabilities, of course. But it’s reasonable to think that they’d be able to compromise OmniBallot’s software in ways that wouldn’t be revealed in a post-election audit.
To be fair to Democracy Live, the issues the researchers highlighted aren’t unique to the OmniBallot software. Rather, there’s an overwhelming consensus among computer security experts that Internet-based voting is a bad idea in general. Halderman and Specter cite a 2018 report from the National Academies of Sciences, Engineering, and Medicine that found that “no known technology guarantees the secrecy, security, and verifiability of a marked ballot transmitted over the Internet.”
Originally Publish at: https://arstechnica.com/