Voting: August 2008 Archives

 

August 22, 2008

Turns out that the AntiVirus software on Premier's EMS wasn't the cause of miscounting after all:
The error occurs when multiple memory cards are being uploaded at the same time, and it is more likely to occur in jurisdictions that have several voters and use touch-screen voting systems, said Premier spokesman Chris Riggall.

Allen, Texas-based Premier, a unit of North Canton-based Diebold Inc., supplies touch-screen voting systems as well as scanners for paper ballots. The problem is more likely to occur in touch-screen systems because they use more memory cards, one for every touch screen.

Premier said in its product advisory that the problem can be corrected as long as officials monitor whether the memory cards are being uploaded, and if they are not, reload them until they are.

Joe Hall has the details. The Premier reports aren't that clear. Here's the "technical background".

The GEMS poster works by receiving concurrent uploads from the memory cards and then saving that data in temporary files for posting to the election databse in a serialized manner, i.e. one at a time. This design is used to optimize the database access performance as well as the upload data performance.

The issue identified is a logic error that allows the poster to attempt to post a file that is still being received when two or more files are received in sequence, and the first file takes longer to save than the second file. If a sharing violation occures, the posting of the first file is the one affected. Note that files typically take very few milliseconds to save, whereas large files, with large number of votes, can take up to 100 milliseconds.

This kind of race condition isn't exactly uncommon in concurrent systems. On the other hand, if there's one race here, perhaps there are others. It's worth asking if there are ways where the file would be marked successfully uploaded but the votes get lost.

 

August 16, 2008

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.