Mark Kleiman picks up an important story that I’d half-noticed on Slashdot a little while back, but had given little thought to. Fortunately, Professor K has a better attention-span than I do. While it could well be true that this stuff has had broader coverage in the US than it has in the UK, in which case my apologies to American readers for repeating the backstory, still…
The meat of the issue is that the fair and balanced and impeccably competent voting-machine company Diebold is doing its damn best to suppress the web-publication of leaked internal memos revealing some absolutely shocking security holes in their product.
Fortunately, the Electronic Frontier Foundation thinks Diebold is trying it on, and is backing the defence of the affected websites.
From a geek perspective, I offer the opinion that the whole e-voting thing is bad enough when you trust the political neutrality of the vendors, given the scope for technical fuckups. And it’s also worth saying that we Brits have every reason to fear that we’ll be subjected to similar nonsense given the blind optimism of our government, which appears to be countenancing voting mechanisms which include ‘the use of the Internet, text messaging, interactive digital TV, and touch-tone telephony’. Gah.
Back to Diebold. As someone who fiddles with relational databases as part of my living, I don’t know whether to laugh or cry when it is revealed that the system which is offered as the backing infrastructure for American democracy involves as its lynchpin an Access database.
Access, as any fule know, is a toy program for putting together a database upon which you want to record the details of your CD collection or keep track of the contents of your sock-drawer; it does not supply a platform which anyone with the tiniest bit of nouse would use for anything that actually mattered.
If a reader can provide me, in confidence, with the name of a financial institution which relies on Access as a core component of a critical business system, I shall be gigantically surprised, and then move my account with them, if I have one, when I have recovered. Perhaps I’m just weird, but I really do care at least as much that I can trust the means by which my government is elected as that my bank statements should be correct each month.
(It is of course true that Access could merely serve, via some kind of ODBC interface, as a view of a proper RDMBS behind the scenes, in which case Diebold’s technical architects would not be the shocking idiots they appear, at first sight, to be.)
And now for the full-on, utterly predictable bit where I do my open-source zealot shtick. If we’re going to have e-voting of any kind, I want to see the code. OK, I personally may well not want to see the sources, but I certainly do believe that anyone who reckons that they can make some sense of the them, and might be able to point out bugs and some potential fixes, should have the ability to see all the code for the software that ends up determining who gets to govern us. Security through obscurity won’t do.
Assuming Diebold’s developers to be super-talented and their bosses’ bosses to be entirely disinterested concerning the results of the elections their software is responsible for calling, there will most likely still be holes in the implementation unless there have been a lot of eyeballs looking at the code trying to find the cockups. Black boxes are no good.
Now, if it is mandatory to place the source for your voting system in public view, it may turn out that there is no stable business-model for companies seeking to produce software in this area. If that proves to be the case: too bad. Collectively, we’ll have to work out some other means for generating the software we feel we need.
Chads, dangling, hanging and otherwise, were clearly a menace; but they could be counted after the fact, and it was obvious when the machines which produced them were up the spout, since their innards could be inspected. We should ask for no less when considering their prospective replacements.
{ 9 comments }
Dick Thompson 10.22.03 at 12:55 am
I’ve used ODBC as a link between Access and SQL Server, Microsoft’s database, and it’s neither secure nor very stable. ODBC is a techology whose time is long-gone. Funny, that’s what I thought about Access, too.
Jonathan Goldberg 10.22.03 at 3:11 pm
The machines need not be supplied via on open source business model; the source merely needs to be open to inspection.
Although that’s not enough. AT A MINIMUM one must also have the compilation scripts and the exact vendor and model of the (all, if more than one) compilers used, so that the software can be independently compiled. At that point an MD5 hash must be derived, and it must be verified that it matches the hash of the software on the machines in the field. No deviation is acceptable.
That having been said, a paper trail must still be produced. Speaking as a programmer, I trust paper. Not that paper can’t be tampered with; ballot box stuffing certainly long predates computers. But it’s harder to do it tracelessly and en mass.
coder 10.22.03 at 5:47 pm
Without a hard-copy audit trail, electronic voting is inherently unsafe. Open sourcing the software is not sufficient protection. Techies should already be familiar with Reflections on Trusting Trust. Basically, trusting the source is meaningless if you don’t trust the environment it is compiled, linked, and run in.
The bottom line: there is simply no way to ensure that a completely electronic voting solution is trustworthy.
Philip 10.22.03 at 8:06 pm
http://www.equalccw.com/dieboldtestnotes.html
Lets give credit where credit is due. A guide to hacking Diebold databases.
Tom Runnacles 10.22.03 at 8:08 pm
Jonathan – In some ways I wish I hadn’t mentioned Open Source at all, since my point was certainly not that I think that as a matter of principle, election software should be non-commercial, still less that it needs to be GPL’d.
None of the software-licensing theology that ends up provoking so much ‘IANAL but…’ stuff on Slashdot matters here. I just care that we can all see the code if we want to. Not necessarily modify it or redistribute it or make it the basis of a religious crusade, just look at it, poke it about a bit and see where the developers fell on their arses – since we know that they certainly will have.
Coder & Jonathan: Agreed about the need for all that other stuff too, especially a paper audit-trail. Publicly-visible source is a necessary, but not sufficient condition of this whole thing being remotely worth trying.
Personally, I think paper and pencil work just fine. The most committed defenders of ‘e-voting’, if we must call it that, seem to be people who know little about technology, or are vendors, or (in the apparent case of Diebold), are both.
Tom Runnacles 10.22.03 at 8:15 pm
Dick,
Heh – the ODBC bit was a hedge :)
I figured that some smartarse was going to say that you could have some super-sophisticated scheme whereby Access was in effect a client for a proper DBMS, in which case my whole rant would look a bit less savvy.
I’m surprised, actually, that nobody took up my offer to grass up their employer (and look clever-clever into the bargain) by pointing out that out-of-the-box, Exchange Server relies on the Access database engine (Jet, is it?). I’d pre-emptively constructed my defence on this point, since I hear MS have responded to client pressure by making it possible to use SQLServer as a backend instead.
Personally, I’m a Unix/J2EE guy; I wouldn’t touch ODBC with a bargepole.
Tom Runnacles 10.22.03 at 8:40 pm
Philip – you’ve done better in tracking down the full detail of the controversial memos than I did. Sheesh, that stuff’s terrifying.
I try hard to suppress my inner conspiracy theorist most of the time, but given the depth of talent available to US software shops, this level of fubar is beginning to look intentional.
Alternatively, it’d be interesting to know how Diebold’s compensation packages for (say) developers or architects compare to the rest of the industry.
Anyone?
Neel Krishnaswami 10.23.03 at 5:11 am
It’s possible to use computers to make voting more fraud-resistant, and the Diebold system is a textbook example of how not to do it, but open source is a red herring here. In order to design a more secure model of voting, you need to have a threat model. The threat model I use imagines that voting works like this: the voter arrives at the polling station, and then marks a ballot (which might be real or virtual). The ballots are delivered to a voting center, which counts them up and announces the outcome. There are, in my scheme, three main attacks:
1. Ballot fraud, in which real ballots are modified to be something other than what the voter intended and delivered to the counting center.
2. Ballot stuffing, in which fake votes are generated and delivered to the counting center
3. Ballot destruction, in which some real votes never reach the voting center.
Note that my threat model assumes that the voting center is both honest and secure. You can ensure this by having witnesses from all parties at the counting center, so this isn’t a hugely optimistic assumption for a first-world country.
So, let’s look at the possible attacks. #1 instantly rules out all purely electronic voting schemes, because modified software can show the voter what he thought he did, and secretly make some other choice. The ballot has to be auditable by the voter, and what the voter audits has to be exactly what the voting center uses to count the votes. So our electronic voting machine has to print out a ballot that lists the voter’s choices, so that he or she can look at it and verify that his or her vote was accurate. (This is why open source is irrelevant in a decent system — the voter can audit his or her vote.)
#2. You can make your voting system resistant to ballot stuffing by making each voting machine tamper-resistant, and having it print out a digital signature onto each ballot which indicates which machine it came from. Then, an attacker can’t forge ballots without sitting at the voting machine pumping out votes, and the poll workers there would presumably notice that something was up and call the cops. (You can continue to do what people do today, which is to mark the voter registration rolls with who voted, which sets an upper bound on the amount of fraud per polling place.)
#3. So we have paper ballots. What’s to stop a malicious vote-rigger from simply destroying the votes that don’t favor his side? This can be handled by having the voting machine simply count the number of votes that it processed, and have the poll workers phone that information in to the voting center. Then the center can count the number of ballots from each machine and double-check that everything adds up.
Note that none of this makes vote fraud impossible — it just makes it harder than it is today. You can make it even harder by planning for a more elaborate threat model, but a post on a weblog comment board doesn’t require it, I think.
Tripp 10.24.03 at 6:49 pm
I’m a programmer, and I don’t scare easily. I thought the millenium bug was blown way out of proportion.
But I second what Jonathan Goldberg said. You must have the source reviewed and agreed on, as well as any code involved in creating the executable code. Then that code must be object-signed, and verification made at each polling place that the signed code is what is actually run.
Then you better take a close look at all the back doors. Are patches allowed on the computers? Is there any non-reviewed software running on the computers such as bios, or the operating system? What about activity logs and traces?
The whole thing gets so tough so fast, I can’t imagine why any knowledgable person would ever want paperless voting.
There absolutely must be a paper trail, and auditting of all results.
Comments on this entry are closed.