Should voting systems have AV?

| Comments (15) | Voting
Several people have pointed me to this XKCD comic:

Without addressing the design of the Diebold system, I'm not sure I agree with the implicit argument here.

First, it's important to distinguish where the AV software is running. It's not on the voting machine proper but on the election management system (EMS). These machines run Windows (the Diebold touchscreen machines run Windows CE and the optical scan machines seem to run some monolithic embedded app [*]). The way the Diebold system works is that the results are fed into the EMS and then the EMS tabulates them and declares the winner.

I can imagine a number of arguments for why you shouldn't have an EMS that has an antivirus system on it. Let's take them in turn:

You shouldn't be using a computer to tabulate the votes.
This isn't inherently crazy, but given the complexity of elections in the United States, it seems fairly unrealistic. In the Nov 2004 election, my local ballot had 27 separate contests on it. Goggin et al. report that single-person manual counting of optical scan paper ballots takes about 5 seconds per race per ballot (with a 1.5% error), so a 27 contest ballot would take about 2.25 minutes to tally. If you use 4 person teams as used in the California TTBR, then Palo Alto, which had about 5,000 votes in that election, would have required about 750 man hours to do a complete count. Even with only a single person per ballot, you're looking at nearly 200 man hours, so that's 12 people to get results within 8 hours. This isn't impractical, but it's a big change from the existing systems, so we have computers in the game somehow.

If you're going to use computer counting, then you need to somehow program the computers, and that means some sort of EMS. Now, you could use precinct count opscan and/or DREs but tabulate manually, for instance from the results tapes out of the precinct machines. Then you wouldn't have to worry about accuracy of the EMS tabulation, which would remove this particular alleged problem (though of course you would still have to worry about compromise of the EMS during the ballot definition phase). On the other hand, the tabulation part of the equation is the most auditable and transparent part of the process. The State publishes precinct totals, so you can add them up yourself and verify that the totals are computed correctly. I'm not saying there's no risk here, of course, but if you're going to remove computers from the system, this isn't where I would start.

Your EMS shouldn't be running on a general purpose system.
A lot of the polling place devices run on non-standard embedded systems. That doesn't necessarily make them less susceptible to malware. It's true that the generic malware that you see on Windows systems isn't going to run on these platforms, so the attackers would have to get their hands on the target software, but that hardly seems like an insuperable obstacle. Of course, your generic AV software won't run on these platforms, but it's not clear that that's somehow an advantage.

You shouldn't need AV on the EMS because your machines should never be exposed to any kind of malware.
I certainly agree that it's critically important to isolate the trusted county central machines from any source of infection (see here for our EVT paper on techniques for this.) But no isolation system is perfect, so it hardly seems like a bad idea to have some sort of security software (AV, etc.) as a backup in case you accidentally contaminate your EMS. I'm not saying that you should rely on AV; if you discover that your EMS is potentially compromised, but your AV system doesn't say anything, it's probably not safe to assume everything is OK. On the other hand, if your AV does signal some kind of infection, you should definitely be paying attention.

The AV is useless.
One of the big failings of AV software is that it's not that great at detecting new kinds of malware. Modern AV systems are OK at detecting known kinds of malware (e.g., generic viruses), but they they're not that great at detecting new kinds of malware—which is why they need regular updates—and even worse when that malware has been specifically designed to evade that AV software. And since any kind of malware that specifically targeted election results would need to be specially designed, your average AV package is not particularly likely to detect it. That said, AV packages typically do contain some anomaly detection, and you might get lucky and have the malware fall afoul of that. However, given that the EMS probably needs less user level flexibility than your average system, you might be able to design a much more aggressive anomaly detection system (e.g., tripwire + something else) that would have a better chance of catching stuff.

The AV is dangerous.
Given that Diebold is blaming counting errors on the AV, this seems like an argument with some force. I have no opinion on whether the AV is to blame, but given that the EMS is running on a system with a huge amount of software (i.e., the OS), it's not clear why you should be especially concerned about the AV as opposed to that other stuff.

15 Comments

Indians run their elections on systems that use hardwired programmable logic, not software. The systems are designed and built by the electoral commission itself, not private businesses, and work very well in practice, despite high illiteracy in the electorate (each candidate has a button on the machine, and an associated icon they use while campaigning, e.g. the ruling Congress party uses a hand as its emblem).

Even a pure paper ballot can be quickly and efficiently counted using divide-and-conquer and by drafting volunteers from the voting public, not relying exclusively on public officials. This also makes the system more resistant to fraud from an entrenched party and avoids controversies like those in Florida or Michigan. The French elections are counted purely manually, and the system works quite well.

Most modern voting systems are woefully inadequate when compared to the elaborate procedures the ancient Athenians used to prevent vote capture, vote-buying or other forms of manipulations as described here:
http://www.alamut.com/subj/artiface/deadMedia/agoraMuseum.html

One of the most significant innovations of the Athenians was to use random lots for public official. This is not as absurd as it may sound at first, after all that's how we select juries, just as they did (except their juries included 200 people at a time and were less vulnerable to individual foibles).

One advantage of running the software on a non-standard platform should that there is much less code that can break. A tailor-made platform is likely much less complex than a general purpose one (unless you're doing it wrong that is).

Er, no -- voting machines, including tabulators, should not be in an environment where they could be exposed to malware, and it's really not all that hard to arrange that they aren't (the big key is that they _don't get attached to the internet_ and that only certified people get access to the hardware in such a way that anything could be run, and even that only before the election machine certification process).

I think the key that you're missing here is that malware is software that changes the behaviour of a machine. Any mechanism that allows modifing the behaviour of a voting machine (including the tabulator! -- it's unlikely that anyone is going to hand-examine the raw voting data for a discrepancy unless the tabulator gives not only implausible but completely impossible results) doesn't just allow the introduction of general-purpose malware of the sort that an AV would discover: it allows introduction of software that could _change the outcome of the election_; this is software that would almost certainly not be detected.

If a machine could possibly end up hit with a general purpose malware package, it is completely unsuitable for being part of an election on the more general grounds that someone is going to be able to tamper with the vote.

And on top of that, yes, every additional software package introduces complexity and potential bugs, even when it isn't a software package notorious for interfering with the operation of other software packages or causing general system problems (and pretty much all antivirus packages, not just Mcafee, have that problem).

I'd reduce your per ballot time estimate by a factor of five using the "sort and stack" method of hand-counting with trained staff, which is appropriate for the manual tally. (Here's an exemplar video.)

Zed:
I'm really quite aware that malware could be introduced onto the tabulator that could change
the outcome of the election. Indeed, one of the major concerns of my recent paper at EVT
was preventing and detecting that case. And yes, I agree that the tabulation systems must
be isolated. But procedural controls are brittle, and the question is whether you introduce
mechanisms to protect yourself if those controls fail. AV is one (highly imperfect) such form of
defense in depth.

Fazal:
We're talking about the tabulator here, not the voting machines. Voting machine design is a
separate question. As for the experience of other countries with hand counting, that's possible
because their elections are much simpler in terms of the number of contests. Experience with
the 1% California manual recount suggests that fully hand counting the election is not practical.

to further respond to some comments:

* The other piece Fazal misses is disability accomodation and support for people who don't vote in English... the Indian system doesn't have to explicitly deal with these cases. Also note that electronic voting on DREs has made its way through a number of pilot phases in France and appears to be poised to become that country's voting technology.

* I think Zed is bit optimistic about the ability to keep these vulnerable systems in environments free of malware. There are many two-way interfaces (networked or sneakernet'd) between voting machines and EMSs. Worse, modern voting machines are often sent out into the custody of thousands of pollworkers (who are in no way qualified to protect the systems from even a slightly determined adversary). You may respond, "So what? We need to fix these conditions if we value a robust election system." That would be a bit naive... just because we can do something doesn't mean the political will or, often more importantly with local politics, resources exist to make it happen. Elections are undervalued and undersupported in the United States, and that's not been an easy thing to change.

The 2002 and 2005 VVSGs include clauses that could be interpreted as requiring AV software on general-purpose PCs: "Voting systems shall deploy protection against the many forms of threats to which they may be exposed such as file and macro viruses, Trojan horses, and logic bombs. Vendors shall develop and document the procedures to be followed to ensure that such protection is maintained in a current status" (2002 VVSG 6.4.2; 2005 VVSG 7.4.2). There's also 2002 VVSG 6.5.4.2 and 2005 VVSG 7.5.2 for systems that use public telecommunications networks.

The current draft VVSG is much more explicit: in 5.5.4-A, it states: "EMSs SHALL use malware detection software to protect themselves from common known malware that targets their operating systems, services, and applications"; this is then clarified in the discussion:


Off-the-shelf malware detection software, such as antivirus software, anti-spyware software, and rootkit detection, can identify common known malware that attempts to infect an electronic device, as well as identify infections on the device. The scope of this requirement is limited to EMSs because they should have the required resources to use off-the-shelf malware detection software and also because there should be off-the-shelf malware detection software available for their platforms. For many other electronic devices, neither of these conditions is true; also, some platforms do not have common known malware threats, so malware detection software would not be useful.

Just a quick note...Solidcore is something to look at and is becoming a standard on these platforms. Solidcore is already part of NCR's ATM platforms (where AV was replaced with Solidcore), Sharp multifunction printers and POS systems from NEC. Just something to consider instead of Tripwire + something else.

I'd like to build on Zed's statement that "malware is software that changes the behaviour of a machine", as well as Tony's mention of Solidcore.

My main observation about *any* component system of a election system (EMS or polling place device) is that the component does not require the capability to run any new software after it has been built. (They do require being re-built, but the integrity of that process can be managed separately.

Solidcore technology can be used to, for example, turn a windows-based system, which is designed into have its software based expanded, into a system that is very resistant to a state change the allows it to run new software. This would be handy for a windows-based system like the Deibold EMS.

Better, however, would a much much simpler purpose-built OS that inherently lacks the capability to be modified. Such a beast, designed to support discrete election system component "appliances" is one thing that my group is working on at present.

-- John Sebes

joe:

The original discussion context was whether or not a broken voting security system indicates someone doing his or her job horribly wrong, not whether or not it's politically feasible to do it right. If the counterargument is that the government has too much invested in doing the job horribly wrong, I may even concede the point -- but then XKCD is clearly right to mock it.


That said, however, it really isn't that hard to deal with the sneakernet problem, because if the basic design of the system is remotely adequate, sneakernet is only an issue with people with sufficient access to log in with enough access to do something than start the system -- and none of those should be present after certification ends. Even a Windows box can be configured this way -- run your tabulation software as a service, and handle your data transfer by plugging your memory card with the votes into the reader dedicated to the purpose, disable all other data input sources other than the human interface, and election workers don't even have to log in. They just turn it on, and make sure that it gets to its display. If it doesn't, they flag it as inoperative, and go fetch one of the backup units. Systems that are even more modification-resistant such as the Solidcore mentioned by others or even simply setting the code storage system to be read-only are even better, of course, but we're talking about basics here.

This isn't all that brittle, because the only thing that you're worried about at this point is someone committing some extreme and deliberate tampering with the hardware to allow code to be run (or an insider sticking in a chip with vote data designed to cause the tabulator software to do something unexpected), and an antivirus package isn't intended to deal with that threat model anyway.

There's nothing here that's new, and there's nothing that's rocket science. We're not talking about management of advanced threats like how to stop voter intimidation (i.e. vote disclosure issues), corrupt certification management, ballot stuffing, vote switching, manual recount security, denial of service attacks, or the dozens of other things that electronic voting systems have been caught doing wrong. We're only talking about the simple issue of *preventing an outsider from running untrusted code on a voting machine*, which is potentially equivalent to that person being able to replace the voting machine completely. That the untrusted code might contain more generic malware that would be stopped by antivirus software isn't an issue any more than that the schoolteacher might have an STD that would be stopped by a condom.

Another way to look at this -- would you continue to keep your money at a bank that had its ATMs shut down because of an antivirus software causing problems? ATMs have even worse security environments, after all -- the hardware is stored in an unmonitored location all day, and require a network connection to the bank's computers to function at all. Yet I think people would rightly be nervous to discover that the bank was relying on antivirus software to keep malware infections out of its financial transaction systems.

A few notes:
(1) It might be useful to have some background on how the EMS works in most current voting systems. The tabulator needs quite a bit of per-election information in order to actually count the votes. So, either you have an integrated EMS where the tabulator is also used to prepare the ballot defn's, or the tabulator is a separate device in which case you need to be putting media in to carry the ballot defn's, at which point you have a potential malware problem. Yes, yes, you can theoretically have procedures which stop this stuff, but what if they fail? The question then becomes whether you think it's useful to have defense in depth. And no, I don't think it's OK to have the system shut down because some generic virus gets introduced.

(2) Even if you ignore vectors other than the memory card reading, that itself is an infection vector,
and since the cards are read sequentially, it's far from clear that any of the current techniques designed to stop binary replacement will be effective. Now, it's true that AV may not detect such attacks, but that doesn't mean it definitely won't (see the original post) and so, no, I don't think it's crazy to have a
defense against that.

(3) As for ATMs, they're much more analogous to voting machines than the EMS. I think I would be rather distressed to discover that my bank was running Windows on the internal control networks and not running any sort of anti-malware software.

well, that's not to say ATMs might not benefit from generic malware detection:

Celeste Biever. (2003, November 26). Cash machines infected with worm. New Scientist. Retrieved from http://www.newscientist.com/article.ns?id=dn4425.

EKR, by what mechanism, exactly, are you expecting foreign code to execute after inserting a memory card into the tabulator reader, in any remotely sane design? The only plausible one seems to be voting data carefully crafted by an insider to exploit a buffer overrun or backdoor in the tabulator software, which is unlikely to be detectable in the first place.

As an aside, I'd rather have the system shut down completely when a generic virus gets introduced, because a complete shutdown is in fact the correct procedure once a voting machine has been tampered with. Much more worrisome is that the machine would continue to be used.

AV software causes a lot of unpredictable problems just because it sucks just as badly as software in general does, and is hooked up very intimately to the internals of the host OS. Plus, now Symantec (or whoever spoofs their autoupdates) owns the election...

I disagree strongly with this claim from the original post: "Of course, your generic AV software won't run on these platforms, but it's not clear that that's somehow an advantage." A sensible, tight embedded OS vs Windows plus random AV package -- complexity, anyone? Millions of lines of useless but live (undead?) code can come back to haunt you...

BTW, I don't care what my bank runs on its ATMs, since a screw-up is only likely to lose some of the bank's money (or less likely, mine) - and I can always vote with my feet and switch banks. Effecting a "regime change" in my home country is rather more serious and less reversible.

Still, the threat model for election systems shouldn't include network attacks. I think the real hurdle with election systems using general purpose computing hardware is defining the threat scenarios and adequately protecting against them. We need to be concerned with both physical and network/remote tampering for starters.

I think we can design a better voting system solution. Let's say the voting system isn't on site. Then we need to make sure that all voting machines (front-end machines) bidirectional-auth with the tally system. We then carry out all communication via encrypted SSL tunnel, sending our votes to the tally system. The tally system sits somewhere safe (physically) with a huge pipe (to help mitigate against DoS attacks) and accepts communications from only the voting systems (after auth). There are all sorts of ways to actually build this solution like egress-filtered DMZs and highly-restrictive firewalls for the tally system(s). That means only SSL traffic, but a LOT of voting machines talking.

Because the number of voting systems can get high, let's consider a modified alternative. Then let's build regional tally systems (within a county or a state) that sends burst results to the master tally systems under the same security rules.

Am I missing something critical aside from bad implementations of SSL?

Leave a comment