Company Defends Electronic Voting System
Diebold Election Systems said computer security experts at Johns Hopkins University in Baltimore reached their conclusions by using outdated computer code for its touchscreen software. The company also said the researchers ran the software on a device on which it was not designed to work.
In addition, Diebold said many of the weaknesses attributed to the operating system on which the software was tested are inapplicable to the operating system used by the North Canton, Ohio-based company.
OK. I just read the report, and I'm not done digesting it. The analysis covers a different area of the overall e-voting system than my last blog entry on GEMS, which is on the ballot server, not the touchscreen units that would be deployed in the field. This report focuses on the actual touchscreen units, which are discussed somewhat in Bald-Faced Lies about Black Box Voting Machines -- and according to one of the technicians interviewed, the touchscreen units are running Windows CE.
Some things to keep in mind:
When you install upgrade software on your computer, you use a floppy disk, CD, or download an archive from some location on line.
Installing or upgrading software on an embedded system (your DVD player is an embedded system) you frequently save the new software to a PCMCIA or other kind of 'smart card', and insert that card into the device. An area of memory ('flash') on the device is overwritten, and that constitutes installation. So the card is like your upgrade CD.
My recent blog entry focused on GEMS, Diebold's back-end server (ballot server). This entry and probably a much longer one will discuss the touchscreen units and precinct-ballot server communications, as analyzed in the John Hopkins ISI report.
Diebold is currently protesting that the analysts ran the allegedly Diebold source code on a Win2K machine, which was not the correct OS.
I'm going to go out on a limb here, but the differences between WinCE and Win2K are probably smaller than the differences between RedHat linux and BeOS. The code compiled on the 2K box, and after reading the John Hopkins ISI report, nothing they discuss concerns the compile OS, beyond the broad discussion of the implications of using an unsafe OS -- such as any version of Windows.
The OS protest is bull. I'm sorry, guys. My best advice to you right now is to pull your methodologies together, get a serious QA and project management team in place if you haven't found one by now, and completely redesign and rewrite the application, including tossing legacy code. It's obvious the older stuff had minimal oversight in development (this, by the way, is typical for software teams' first projects, and the reason why I'm not an early adopter of any technology that might come near my money, in fact, why I've been known to laugh out loud when discussing 'emerging' software).
The report does discuss certain distinctions between Windows and WinCE with regards to CE's treatment of smartcards, that is, how smartcards 'appear' when mounted on a system running CE, and what dangers may be present in a touchscreen box running the e-voting system they analyze. That's the only OS-specific discussion, and it's about the 'right' (runtime) OS.
Some initial notes:
The language of choice of the analyzed application, which is allegedly a version of the current Diebold application, was C++, which, like C, makes it easy to induce errors in memory management. Not on purpose.
Each instance of a voter corresponds to a voter card, a 'smartcard' provided to the voter either via mail or at the time of sign-in at the precinct (the process is not defined).
There are multiple ways to attack one of these systems, as discussed in the JH ISI report, and *not all of them* require advanced computer knowledge. Some of the CS-experience-required include reordering ballot lists so candidate 1 gets swapped with candidate 2 and gets their votes, creating a fake admin/ender card to terminate the election prematurely, generating fake cards that ignore the 'this card's vote complete, cancel card' function call, to permit substantial re-use and multiple votes. Flaw in e-voting software? by Randall Edwards mentions reprogramming a smart card to enable a voter to cast multiple votes for one candidate. The scary thing about this idea is that once programmer A has created this card, they're easy to duplicate and don't take any technical savvy to actually use. The Hopkins report discusses different scenarios, including (shudder) taking advantage of code that appears to permit use of the preinstalled 'manufacturers' password present on every smartcard at the time of sale. So you don't even need the 'real' password to use a smartcard.
In addition, whether you try to hack the touchscreen end of the system, by building fake smartcards, or whatever, when all is said and done, election data is transmitted IN THE OPEN, in this version of the application. Not to mention the passwords in the open between the touchscreen and the card.
You know how when you go shopping online, your browser changes from http to https, thus indicating you're now about to transmit your credit card data via a secure connection (SSL)?
Not in use, here. Should be in use. Without that kind of protection, someone can perform a 'man in the middle' attack and intercept data sent from a precinct to the main ballot server via the Internet (dialup too, if you know the right kind of person), and
a. simply keep it from getting to the final destination (if the ballot server doesn't have builtin checks for precincts, this would drop a balloting station off the map)
b. replace the ballot data with a modified set, thus falsifying election results.
This one flaw by itself is enough to warrant not using the application.
Transmission of election results, if made online, must be encrypted. Further, no handshake or data integrity analysis is performed when data from a precinct station is transmitted 'home', which means that data could be intercepted, its format parsed, and replaced with a false data stream. Worse, a precinct could be simulated entirely, sending false returns to the ballot server.
I heard on the radio that e-voting (I assume, Diebold) units are slated to appear in San Diego elections in the not too distant future. I am thoroughly opposed to the introduction of these systems without substantial oversight, and that means a non-partisan, non-corporate affiliate group analyzing both the code and the process. Where's a standards Working Group when you need one?
I'll say two final things on this subject (for now):
I'd feel a lot more comfortable if the source for these systems were in the open - because e-voting is an emerging technology, and involves a critical process concerning the government of this and other nations. It needs to be secure.
Failing that, I'd feel a lot more comfortable if I were one of the people working on this application.
Possibly both.
John Hopkins Information Security Institute: Analysis of an Electronic Voting System
Diebold Election Systems
Bald-Faced Lies about Black Box Voting Machines
Company Defends Electronic Voting System
Flaw in e-voting software?
No comments:
Post a Comment