Over 9000 jurisdictions (counties and states) in the U.S. run elections with a variety of voting machines: optical scanners for paper ballots, and direct-recording “touchscreen” machines. Which ones of them can be hacked to make them cheat, to transfer votes from one candidate to another?

The answer: all of them. An attacker with physical access to a voting machine can install fraudulent vote-miscounting software. I’ve demonstrated this on one kind of machine, othershave demonstrated it on other machines. It’s a general principle about computers: they run whatever software is installed at the moment.

So let’s ask:

Which voting machines can be hacked from anywhere in the world, through the Internet?

Which voting machines have other safeguards, so we can audit or recount the election to get the correct result even if the machine is hacked?

The answers, in summary:

Older machines (Shouptronic, AVC Advantage, AccuVote OS, Optech-III Eagle) can be hacked by anyone with physical access; newer machines (almost anything else in use today) can be hacked by anyone with physical access, and are vulnerable to attacks from the Internet.

Optical scan machines, even though they can be hacked, allow audits and recounts of the paper ballots marked by the voters. This is a very important safeguard. Paperless touchscreen machines have no such protection. “DRE with VVPAT” machines, i.e. touchscreens that print on paper (that the voter can inspect under glass while casting the ballot) are “in between” regarding this safeguard.

And now, the details.

To hack a voting machine remotely, you might think it has to be plugged in to the Internet. Most voting machines are never plugged directly into the Internet. But all voting machines must accept electronic input files from other computers: these “ballot definition files” tell the vote-counting program which candidates are on the ballot. These files are transferred to the voting machine, before each election, by inserting a cartridge or memory card into the voting machine. These cartridges are prepared on an Election Management System (EMS) computer. If that computer is hacked, then it can prepare fraudulent ballot-definition cartridges. Are those EMS computers ever connected to the Internet? Most of them probably are, from time to time; it’s hard to tell for sure, given the equivocations of many election administrators.

The ballot definition is (supposed to be) just data, not a computer program. So how could it convey and install a new (fraudulent) vote-counting program onto the voting machine?

Voting machines designed in the 1980s (Shouptronic, AVC Advantage, AccuVote OS, Optech-III Eagle) store their programs in EPROM (Erasable Programmable Read-Only Memory). To install a new program, you need to remove the EPROM chips from the motherboard and install new ones. (Then you can reprogram and reuse the old ones using an EPROM “burner” device.) Those machines are not likely hackable through the Internet, even indirectly via corrupted EMS computers. (What if the EMS sends fraudulent ballot definition cartridges? This should be detectable through pre-election Logic and Accuracy testing, if it’s thorough. And in some cases it can be detected/corrected even after the election.)

Voting machines designed in the 1990s and 2000s took advantage of a new nonvolatile storage technology that we now take for granted: flash memory. They don’t use EPROMs to store the vote-counting program, it’s kept in flash. That flash memory is writable (reprogrammable) from inside the voting computer.

Almost any kind of computer needs a mechanism to install software updates. For most voting computers that use flash memory, the upgrade process is simple: install a cartridge that has the new firmware. For example, the Diebold AccuVote TS examines the ballot-definition cartridge; if there’s a file present called fboot.nb0 instead of (or in addition to) the ballot-definition file, then it installs fboot.nb0 as the new bootloader! Using this mechanism, it’s easy and convenient to install new firmware, but it’s also easy and convenient to install fraudulent vote-counting programs.

It’s not just the AccuVote TS that installs new firmware this way. This technique was industry-standard for all kinds of equipment (not just voting machines) in the 1990s. We can assume that it’s used on all voting computers that use flash memory. (One might imagine–one might hope–that after the voting-equipment industry came to understand this issue by reading the Feldman et al. paper, they would use a cryptographic authentication mechanism to accept only digitally signed firmware updates. But since the voting-equipment designers undoubtedly connect their own computers to the Internet, determined hackers could infiltrate and steal the signing keys.)

Note 1: “Sort of.” DRE with VVPAT, that is, Direct-Recording Electronic (touchscreen) voting machine with Voter-Verified Paper Audit Trail. This allows the voter to see his/her votes, printed on paper, behind glass; the voter can in principle confirm that the correct selections are printed, but most voters don’t do this; election officials can in principle recount the paper that the voter actually saw, but the format can make recounts difficult. This technology is a kind of voter-verified paper trail that’s recountable by hand, so it’s protection against hacked computers. But it’s not as good as optical-scan paper ballots that the voters actually marked themselves.

Note 2:Doug Jones writes, “Early versions of the iVotronic use flash memory (not EPROM), but changing the firmware was done by opening the case and either doing a chip swap or by using an external programmer to reflash the chips. Later versions, after they added the Compact Flash card interface, could have allowed reflashing the firmware from the CF card. I do not know if they did this. There’s a strong security argument to not do it, and there’s a strong convenience argument to do it. I believe they understood both arguments back at the time I dug into the guts of the iVotronic.”

Note 3: AVC Advantage models 1 through 9 count votes on a Z80 computer, executing from ROM. Model 10 still has a Z80 motherboard, but an 80386 daughterboard counts the votes; this daughterboard has flash memory and the a potentially hackable-by-cartridge interface. Some versions of the Model 10 have a VVPAT printer. I am not sure that any states use the Model 10; I believe NJ and LA still use the model 9. (See “Daughterboard vulnerabilities” in this paper.)

Note 4: This machine uses flash memory to store its program, but I don’t know whether it accepts firmware upgrades on the same cards that are used to carry ballot definitions.

Post navigation

One response to “Which voting machines can be hacked through the Internet?”

I think you’ve been a bit too easy on the older generation of machines by focusing on the security issues that are present when a machine holds its firmware in flash memory.

The underlying weakness that matters is the ability to deliver code to a voting machine. Yes, machine code matters, but any code is a threat. Specifically, some voting machines include interpreters that can interpret code from files on the removable memory media. Many file formats can include embedded code, and the software that reads those file formats must contain the interpreter for that code. Among the more widely known file formats that contain embedded code are PDF files and Microsoft Office files (.doc, .xls, etc.). PDF files contain code written in a variant of a funny language called Forth, and Microsoft Office files can contain code written in Visual Basic.

In the voting system domain, the AccuVote OS system uses a file on the removable memory card that contains code written in gbasic, a proprietary version of Basic developed by Global Election Systems (one of the early developers of the AccuVote product line). This gbasic file holds the code used to format and print the reports on the voting machine’s printer. By using a general-purpose programming language for print formatting, whether Forth code in a PDF document or gbasic code on an AccuVote OS machne, the output can be formatted with great flexibility.

Unfortunately, both Forth and gbasic are general-purpose languages. Code that you thought was just formatting data to print it can also change the data, printing something other than what you expected. In 2005, Harri Hursti demonstrated an attack on the Diebold AccuVote OS machines then in use in Leon County, Florida. He delivered fraudulent gbasic code to the AccuVote machine so that it printed result tapes that reflected the vote totals he wanted instead of the honest vote totals. This did not change the paper ballots, a recount would have detected his attack, nor did it change the data stored on the results cartridge. You can read about this on the Wikipedia page on the Hursti Hack, https://en.wikipedia.org/wiki/Hursti_Hack

Later that year, Hursti demonstrated a more thorough attack that falsified everything, but the gbasic memory card attack clearly demonstrates the risks associated with executable code on removable media. These attacks did not alter the firmware on the voting machine, they merely altered code on the memory cards that was interpreted by that firmware. That altered code could easily be made to cheat only during a real election, and I am not confident of any way to defend against such hacked code using pre-election testing.

In sum, any data on the memory cards used to configure voting machines that is not visible during pre-election testing is a potential vector for attack. The problem is not limited to firmware updates delivered by memory cards.