Last week we told you about D.C.’s intention of running an insane live experiment on live voters in a live election with an untested, wholly unverifiable, easily-manipulated Internet Voting scheme this November, and about just some of the computer security and election experts who have been desperately trying to warn them against it.
And now we find out that the very short planned pre-election test phase, in which hackers were invited to try to manipulate the system, has been abruptly aborted in the wake of a, um, disturbing (if not wholly unpredictable) development.
The failed system in D.C. was developed with the Open Source Digital Voting Foundation, an outfit that is working with election officials around the country to push Internet Voting everywhere, along with other computerized voting schemes. Simply because a system is “open source” does not mean it’s secure, particularly when it relies on concealed vote counting, as all of their e-vote schemes do.
Below, along with our quick list of other recent known e-voting hack events, computer scientist Jeremy Epstein in “The Risks Digest,” which describes itself as a “Forum on Risks to the Public in Computers and Related Systems,” offers the quick timeline of recent developments in the District of Columbia’s plan “against advice from many computer scientists, pursuing a trial of a prototype system for the November election.”
The result, as seen below, in this latest assault on citizen-overseeable democracy is, of course, a stunning surprise to absolutely nobody other than perhaps the D.C. election officials interested in this horrific scheme and the profiteers who must have tricked them into believing that it was a secure and/or good idea [emphasis added]…
- Summer 2010: DC announces the pilot, with the open testing period to be in August
- Sep 20: DC releases a network map and requirements document; test server to be available Sep 24-30 [1]
- Sep 24: Common Cause and Verified Voting write to Mary Cheh, chair of the DC Council oversight committee on elections, suggesting that Internet voting appears to violate DC law due to lack of voter-verifiable ballots [2]
- Sep 24: 13 prominent computer scientists and lawyers write to Mary Cheh, pointing out numerous difficulties with the test program [3]
- Sep 24: Test server availability delayed for an undefined time
- Sep 28: Test server available, source code availability announced publicly; test period to run through Oct 06 at 5pm
- Sep 30 morning: After casting a “vote” on the test server, the browser plays the Univ of Michigan fight song
- Oct 01 afternoon: DC takes the test server down, citing “usability issues”
It’s unclear when the test period will resume, if it all. It’s also not clear at this point the extent of the compromise of the system. While it’s true that the DC BoEE can fix whatever problems allowed introduction of the “fight song,” it’s also clear that this is the tip of the iceberg – we know from 30 years of experience that the “penetrate and patch” method doesn’t produce secure systems.
The RISK? Ignoring the advice of computer scientists and charging full steam ahead on a technology project doesn’t work!
While we don’t have the time today to detail all of the hacks of electronic voting systems used across the country today — which are already easily manipulated even without relying on the Internet to make matters worse — here are a few of note from recent years, including one as recently as this past August when “white hat” hackers were able to hack Pac-Man onto a touch-screen voting system without disturbing its supposedly “tamper-evident” seals. (For the record, one of scientists involved with the Pac-Man hack, and a number of others listed below, is J. Alex Halderman, who is now an assistant professor of electric engineering and computer science at Michigan University. Just saying. [Insert fight song here]. 🙂 )
- Sequoia AVC Edge DRE, 2010, Pac-Man hacked onto machine by scientists from University of Michigan and Princeton University without breaking “tamper-evident” seals.
- Sequoia AVC Advantage DRE, 2009, hacked by computer scientists at UC San Diego, University of Michigan, and Princeton University by swapping out its chips in a matter of minutes, with no access to source code or other “closely guarded technical information.”
- Sequoia Edge DRE, 2007, hacked by computer scientists at U.C. Santa Barbara (video release in 2008)
- Diebold, ES&S, Sequoia, and Hart Intercivic systems, 2006 & 2007, Independent tests commissioned by the states of CA, OH, and CO all found they were able to hack every system tested. In seconds.
- Diebold Touch-Screen, Op-Scan Systems, 2007, Physical key to all Diebold voting systems (same one is used for every machine) confirmed by Princeton computer scientists as accurately copied from photo of key posted by Diebold in its own online store.
- Diebold touch-screen system, 2006, hacked by computer scientists at Princeton
- Sequoia tabulator, 2006 accidentally hacked by Michael Shamos in PA (while trying to demonstrate that the system was not hackable)
- Diebold touch-screen system, 2006, hacked by Harri Hursti in Emery County, UT
- Diebold optical-scan system, 2005, hacked by Harri Hursti in Leon County, FL (video)
UPDATE, 2:24pm PT: Washington Post’s Mike DeBonis reports on the hack, says D.C. officials will nix their ill-considered plan for allowing votes to be cast on the Internet — for now — and quotes computer scientist Jeremy Epstein (whose coverage we noted above) stating what should be the obvious in regard to the hackers exploiting a security hole in the Internet voting scheme to play the Michigan fight song: “In order to do that, they had to be able to change anything they wanted on the Web site.”
Anything. They. Want.
Other than that, let’s keep working towards Internet Voting! It’s a great idea! Local e-voting has worked out so great, what could possibly go wrong by extending it onto the Internet?!
CORRECTION: As Epstein notes in his comment below, he is not of “The Risks Digest,” as we originally described him, but rather, it is “a public forum for computer scientists and others to share risks for over 25 years.” Our apologies for the imprecise accreditation there. We’ve changed “of” to “at” in the story above to correct the record.
UPDATE 10/5/10: As we posited above, University of MI’s J. Alex Halderman was, indeed, behind the attack. He fesses up, saying: “Within 36 hours of the system going live, our team had found and exploited a vulnerability that gave us almost total control of the server software, including the ability to change votes and reveal voters’ secret ballots.” Full details now here…
Brace yourself for the Ohio State backlash.
woah! Brad, let me make sure that I read this correctly… You mean to tell me that in the face of incontrovertable facts, bone stupid common sense and (perhaps!) an acknowledgement of the minimum procedures necessary to run a democratic election, election officials in DC actually DID THE RIGHT THING (at least for now) and stopped an attempt to undermine our democracy with technology? My mind is blown! This goes against everything that I thought this country stood for since Shrub! I need to sit down and think about this for awhile!
Brad, good coverage. But you should know I’m not “of the RISKS Digest” – the RISKS digest has been a public forum for computer scientists and others to share risks for over 25 years.
Thanks, Jeremy. Will correct that right away. And thanks for ur good work on this beat! Have a feeling this latest (Internet Voting) nightmare is just beginning… 🙁
On the banks of the Red Cedar
There’s a school that’s known to all
Its specialty is winning
And those Spartans play good ball
Fie on Wolverines, I say, fie!
Brad, your links used to post to Facebook with titles, graphics, and description, e.g., on June 22 at http://www.facebook.com/SaveOurVote. Now all we get is the reproduced link. We add the titles but it still lacks the picture. Anything you can do on your end?
Why did these peeps not use OpenBSD as the server operating system for this e-voting application??? It’s the most SECURED O/S on the planet and free to download & use. It’s based on Berkely Unix which was developed at the University of California (Berkeley) back in the 70s.
Not even the CIA can hack into a BSD system.
Visit the OpenBSD project in Western Canada at http://OpenBSD.org and be amazed.
Paper ballots are remarkably resilient from remote manipulation. Just sayin’.
Barbara Glassman – Thanks for pointing that out. Haven’t made any changes on this end, so let me look into that!
Thanks, Barbara! I was wondering the same thing.
I just want vote by mail. Easy for me and the post office needs the business.
@Max, you said “Why did these peeps not use OpenBSD” – I’m not sure whether or not they did (according to the DC diagram at http://www.dcboee.us/DVM/Visio-BOEE.pdf, they’re using VMWare ESX, but it doesn’t say what they’re running on top). But the vulnerabilities were application vulnerabilities, not OS problems. So they would exist regardless of the underlying platform. That’s the problem with application-level vulns – hardening the OS generally doesn’t help.
Why don’t they just use a paper ballot system? Even the most SECURED system would still leave us wondering if somebody on the inside could mess with the votes. Go back to the future – paper ballots, hand marked, stuffed in a clear plexiglass locked box, then dumped out on a table and counted before anybody that wants to watch. How hard is that?
shw
Brad-
A couple of points:
1. Your assertion that the Foundation is advocating Internet voting is patently wrong, and void of intellectual honesty. Anyone who reads the trustthevote.org blog will be properly informed on just where we stand regarding “Internet voting.” the record is clear, we do NOT support widespread use of it. Which leads me to point #2:
2. Our role in the D.C. project was to deploy our ballot generator, and we also assisted them with developing a “worked example” of returning ballots by some means other than their current process of eMail or Fax (!) We fully intended this public evaluation to uncover any problems that might prevent its safe use (i.e., the PDF uploader vulnerability that is the center of attention here). They (U. Michigan) DID, and the BoEE thanked them and did the RIGHT THING: took the site down and canceled its use this November. (we applaud them too) However, without this worked example to illustrate what could go wrong, everything was academic jousting. To that extent, we believe this entire exercise has been a complete success (particularly since the D.C. BoEE did the right thing and took the site down.
But please refrain from falsely accusing us of something we’re NOT doing: advocating the use of Internet voting systems. We’re busy working on voting system source code that can be adopted adapted and deployed to bring about accuracy, transparency, trust and security in any voting system that uses a computer for counting and in some cases preparing or casting a ballot. NONE of our system architecture is intended for any public packet switched network; NONE of it. Your charge just killed your credibility in my mind because perusing our blog posts would set that record straight. I have been a big supporter of you and your cause, but this just baffles me why you would make such a baseless charge.
Jonathan Simon has written an excellent piece on the recent special election in Massachusetts and its anomalies.
http://electiondefensealliance.org/files/BelieveIt_OrNot_Final8-30-10_1.pdf
Hope that link works. If not, go to the Election Defense Alliance and read his article– Believe It Or Not.
To those who say “why don’t you use paper”, the DC system (and similar systems) are intended for UOCAVA voters – military and overseas voters who may be a thousand miles from the nearest ballot box and with irregular mail delivery. The goal is to allow them to cast their vote – many overseas voters who request absentee ballots never receive them, and some number that get sent back get lost in the mails.
(As an example, my sister, who has lived in the same small town overseas for 40 years, sometimes gets her blank ballot and sometimes doesn’t. And it’s a whole lot harder for military people who are moving from location to location, so between when they request their ballot and when it arrives they may have moved several times.)
I don’t say this to endorse Internet voting, but rather to suggest that it’s not as simple as “drop your marked ballot in the clear ballot box”.
Of course we could do like some countries and do away with absentee voting, but methinks that would be a political non-starter!
Gregory Miller @ 14:
Happy to correct and/or amend the article above to point folks towards your comment and/or objection to my coverage.
But before I do, quick question to help me under stand OSDV’s position: While you say that OSDV is not “advocating Internet voting” and that you “do NOT support widespread use of it”, do you support it’s use under federal grants available for pilot programs for Internet Voting use by overseas and military voters? (as occurred in this D.C. sitch?)
Also, did you warn D.C. against their Internet Voting scheme before you participated in the program, or anytime during its implementation? If so, do you have any documentation of that? If not, why didn’t you? And why would you participate in a program that you believed to patently unsafe and unsecured for voters? Wouldn’t a principled stand require you to not participate at all in such a scheme?
Look forward to your thoughts.
Brad-
To your questions:
1. For those jurisdictions with military and other qualified overseas voters who have no other reasonable means to return their ballots in time, we support the DoD/FVAP program to explore the LIMITED use of online services. The risk of doing so is clear and present, but we believe it is up to the Elections Officials to make that risk assessment. So for this limited use of overseas UOCAVA voters, the alternative is eMail or Fax return, which we believe is even worse. So call it a choice of evils, and in that regard, we support the FVAP effort, so long as it is limited to qualified UOCAVA voters. By qualified I mean that they can demonstrate that relying on alternative means like those provided by the Overseas Vote Foundation (for instance) is not reasonable to ensure timely return and avoid disenfranchisement.
2. Yes, we have discussed the dangers of using the public packet switched network with several officials in D.C. We’ve presented slides from Dr. Appel and felt we informed them. NO, unfortunately, I do not have documentation of that, but there are officials in D.C. who would verify my assertion here. And to provide some protection, we strongly pursued the concept of a public test of the demonstration system BEFORE any public deployment and that if any vulnerabilities were uncovered that could not be timely resolved (and re-tested) before going live, then it had to be pulled. That happened. No live data was ever used; no real ballots, and no access to any voter information was ever involved.
3. We participated in the program on the basis that we would have an opportunity to put some of our open source components (the ballot generator for instance) into a production setting, and this production setting involved a very restricted use of a digital means of ballot transfer for qualified overseas “UOCAVA” voters ONLY. We continue to believe the Internet is unsafe for transacting ballots. We believed the method the District wanted to use was better than eMail or Fax, and if one looks at their architecture rationale document (43 page technical white paper available on their site) the approach appeared to offer a means worth examining and piloting for this very restricted audience, whose alternative return methods are guaranteed less private or secure.
In retrospect, had we known that putting this system into a public review cycle, with fully transparent code would result in such a backlash if a vulnerability in deployment was uncovered, we never would’ve participated.
To be sure, the greatest enemy to all sides was a mismanagement of time. The cycle time for evaluation was greatly compressed. The rush to deploy components resulted in basic block-and-tackle errors (from what we can tell; we have NO role in the data center, access to it, or even visibility on what exactly happened on their back-end.) But for sure, the mismanagement of time and process is the real teachable element here. I say that, because in a more reasonable time frame, the configuration screw-ups that occurred would’ve been trapped and corrected before the public review. But the theory was to put it out there and let people have at it BEFORE any decision to turn it live was made.
I also point out, that one of our agenda items was to push this along so the elections verification community could, in fact, have a venue, forum, and real worked example on which to make their case. And they have it and are doing so. I still think that there is a success in what happened.
One final point, the CTO’s office in D.C. is conducting their own internal investigation into the U. Michigan’s findings. I understand there will be more to come out, that may clarify the Haldermann team’s findings. We’ll see, it is entirely out of our hands.
Call me suspicious, but the actual name of the Michigan Fight song is “The Victors”. Perhaps someone leapt to conclusions re; the meaning of the message? Also, a really clever hack might have used the Iowa Fight Song. Go Hawks!