Interpreting reports of e-voting failures: part III (malicious failure modes in the polling place)

Yesterday I wrote about non-malicious e-voting failure modes. In today's installment, we discuss malicious failure modes in polling place devices (tomorrow we talk about the back office).

The most powerful attack is if the attacker can gain actual control of the voting machine. There has been a lot of work on subverting polling place devices, but the bottom line is that it looks to me like an attacker with limited physical access can take control of pretty much any of the standard devices (I'll cover attack vectors later). Obviously, an attacker who controls a voting machine can make it do pretty much anything it's physically capable of, including simulating any non-malicious attack. However, there are also more subtle attacks that an attacker can mount. The TTBR and EVEREST reports provide extensive catalogs of the possible attacks, but I'll just cover some of the highlights here, focusing on attacks designed to alter the vote count.

OPSCAN
Because the optical scan interface is so limited, it's extremely hard to distinguish malicious from non-malicious errors. However, an attacker who controls an optical scanner can cause selective failures of the optical scanner in several interesting ways. First, the scanner can explicitly reject ballots cast for particular candidates; for instance, it could claim that some fraction of ballots with Burr selected were undervoted or overvoted. It's not clear how powerful such an attack is, since presumably voters would keep trying and eventually either the ballots would be submitted for exceptional manual processing or the machine would be taken out of service. On the other hand, this could serve as a vote suppression attack for particular districts. A more sophisticated version of this attack would be to have the scanner count votes and if it detects that a lot of voters are voting Burr rather than Hamilton, it starts failing more frequently, suppressing votes in Burr precincts.

There are also invisible attacks: the scanner could simply record votes for Burr instead of Hamilton. As I noted previously, this would only get caught in an audit with a separate scanner or hand counting, since there's no display to the user of the scanned ballot. Even if there were, the scanner could display "Burr" but record "Hamilton", so there's no real way for the user to detect attack. Not all jurisdictions do audits and it's not clear that even where they are done, they're done in a powerful enough way to detect and correct this kind of tampering (more on auditing in a later post as well).

Even an attacker who doesn't control the machine can still perform a DoS attack: optical scanners and the sheet feed mechanisms inside are relatively easy to jam. If you're not worried about getting caught, you could clearly cover your ballot with glue and then shove it in the scanner. There are probably substances you could use that would dirty the scan heads enough to make votes hard to read. Could you do this selectively? Maybe. opscan ballots in Santa Clara are two column, but each race is a single column, so you can't prefer one candidate to another. But what you could potentially do, depending on the scanner, is dirty the section of the head over a given race thus suppressing votes for just that race, which would let you have a semi-selective effect. This would be an invisible attack unless the scanner is configured to report undervotes.

DREs
There's an enormous amount of room for attack with DREs. You could clearly mount a simple vote-flipping attack, simulating a flakey touchscreen and making the machine visibly shift votes from Hamilton to Burr. However, you can do far better than that. The attack that's most obvious—and has generated the most concern—is simply to have the machine record an entirely different set of votes than the voters are voting. [In the research community it's generally considered declasse to just stuff the ballot results with fake votes because at least in principle jurisdictions record the total number of votes and can compare them; intead you change users votes.] This isn't even noticeable to the voter, since the UI all looks right. It's just that a different vote is recorded. Without an independent record of your vote, there's no straightforward way to detect or correct this kind of attack.

If a VVPAT is in use (see the previous post for a description of a VVPAT), the attacker's job becomes a little harder. If he just creates totally phony records, then the electronic results won't match the results on the VVPAT. The obvious attack here is what's called a "presentation attack". The machine accepts the user's input but somewhere along the line it changes the vote. Maybe it does it on initial input but more likely it does it before the summary screen or just on the VVPAT. Studies show that users aren't very good at checking these and so mostly this will work. Even if the user catches it, the machine just lets them correct "their" mistake and then perhaps waits a while before attacking again. A really sophisticated machine might be able to monitor user behavior to try to pick out users who seemed uncertain about how to use the machine and attack them preferentially. The advantage of this kind of attack is that it makes the VVPAT and the electronic records line up, making audits much harder.

Other attacks are possible too: the attacker controls the printer, so perhaps he can print the VVPAT as normal and then when the voter casts their vote, he waits and then prints "VOID" or "REJECTED" (depending on how the machine would ordinarily display rejected ballots) and then prints his own votes of choice. This just looks like a bunch of extra printer activity and since voters don't have a lot of idea how the VVPAT is supposed to behave, it's not at all clear they would notice.

As with OPSCAN, there are also a broad variety of DoS and selective DoS attacks. The machines can be programmed to slow down or crash when you vote for specific candidates. They can fail to display specific races. For instance, if the attacker wants to influence a Senate race and it detects you voted for party A for president, then it could not show you the senate race, thus pushing the race toward party B. Again, you might not notice this in the VVPAT/summary screen. Even without full control of the machine, it's probably possible to crash it in various ways without getting blamed.

Malice, incompetence, etc.
I said at the beginning of this post that an attacker can simulate more or less any non-malicious failure--and has a real incentive to do so. However, as anyone who has worked with computers can tell you, they are perfectly capable of behaving in lots of surprising ways without any malicious activity at all. Any report of failure needs to be evaluated using Hanlon's Razor. We have plenty of evidence that voting machines in particular can do things that look like attacks even when it's pretty clear they are not (see this video, for instance), so while certainly we have to be wary of attack, it's probably a mistake to jump to the conclusion that there's been an attack just because you see something funny.

Next: Malicious failure modes at election central

UPDATE: Fixed cut and paste error.