Donate to 51 Capital March and help to continue our efforts 51 Capital March Online Protest Store Learn how to safeguard our elections Learn what 2004 election fraud has been uncovered and what is suspected 2004 exit polls vs. reported vote totals Learn how electronic voting threatens your vote 51 Capital March - Commited to restoring our votes and safeguarding our democracy
BLACKBOX VOTING Return to Top

WE ALL LOST THE POWER OF OUR VOTES


The election fraud exhibited in the November election, facilitated by the loss of paper trails and "dirty" voting systems, has resulted in the loss of trust in the integrity of our votes. E-voting machines in and of themselves can be easily compromised and manipulated. Bev Harris's Black Box Voting - Chapter 7 sample (If you would like to support the author and publisher of this work, please visit http://www.blackboxvoting.org/support.html. This book is available in paper back at Plan Nine Publishing, www.Plan9.org) reveals the vulnerabilities and threats to vote processing integrity one such widely deployed system contains. (Also, seeDIEBOLD EXPOSED). Furthermore, there are ample 'incidents' of e-voting system so-called 'failures' or 'glitches' in the 2004 November election: see EIRS, Verified Voting.org's 2004 Election Incident Reporting System. the threat transcends the machine we vote on. The really interesting thing about these reported machine 'glitches' and 'failures' is, for each machine model and system type, the very same 'glitches' and 'failures' were consistently reported across the country, wherever each machine/system was used. This, in systems promoted as being designed and developed under one of the IT industry's most stringent software development standards: ISO 9000. Indeed, as an IT systems professional, I know of no professional developer who would design a voting system which can so easily manipulate votes as those systems described here.

Keep in mind these voting systems, while complex, are designed and developed using rigorous requirements, methodologies, planning, and testing. If such a system performs functions consistently and reliably, you can be assured those functions were designed into the system. Let me give you a real example:
DIEBOLD's GEMS software allows systems to be easily configured to default to a specific candidate. When you first approach such a voting machine, a specific candidate is selected before you do anything (interestingly, all default configurations uncovered to date defaulted to George Bush in the 2004 election).
Such machines can also be configured to provide a "feature" whereby voters can choose to vote by selecting a particular party's entire slate of candidates (say, all Democratic candidates, for example).
Also (and this is a very interseting feature), these voting machines can be configured to exclude a candidate selection from being recorded in a given race (say, the Presidential race, for example) when a voter selects to vote a party's entire slate of candidates. WHY???

So, a voter approaches one such e-voting machine, selects to vote the Democratic slate, but as the machine has been configured, no vote is selected for John Kerry and the presidential race defaults to registering a vote for George Bush.
OK, you say, but surely the voter will see this! Right? Well, here is where the system configuration begins to take on the characteristics of an intended and designed exploit:
On DRE machines (touchscreens), the ballot opens for voter review and verification at the very bottom of the ballot, such that battot verification occurs in reverse order from the way the ballot was originally presented to the voter for voting. The presidential race is the first item on the ballot. In order to notice the 'wrong' vote selected for President, it becomes incumbant on the voter to scroll back up through the entire ballot in order to see the 'error' or 'glitch' that has occured. Certainly some voters would conscientiously do such a thorough examination before confirming their votes. Others, however, would not.
So, the voter is unknowingly operating in a "voter beware" environment configured into the voting machine. Never mind that someone is in a hurry, or the ballot is pages long, or the voter has to pass by vote after vote for Democratic candidates to 'discover' the first and only the first candidate selected is wrong!
OK, you say, but this is purely hypothetical! Right? WRONG! This very exploit was described and reported occuring across the country on DREs of various manufacturers (including the DRE I voted on!) and with similar exploits reported on scanning systems as well. Unfortunately, we can never know how many votes were incorrectly cast due to this exploit, but we can know the exploit existed due to voter reports, and we do know these electronic voting systems were "designed" to enable the ability to fool voters.

This brings me to 2 central points, largely ignored, regarding electronic voting systems:
Voters never see their ballot that is counted
Ballots are counted in secret
In these electronic voting systems using scanners and touchscreens, what the voter sees is not the ballot that is counted. The voter sees only a representation of the ballot and casts only a representation of votes. Here is what I mean by that:
On both interfaces (scanners and DREs), a voter's input (touching the screen, marking a paper ballot) is interpreted by a highly configurable and customizable program and is translated into a data record in a database table (like a row in a spreadsheet composed of columns of data).
It is this data record that becomes the voter's ballot that is counted. This is the REAL ballot, the one that is counted, and the voter never sees this ballot.
Is the interpretation correct? Obviously NOT in the real life example I provided above. Is there any opportunity for the voter to examine this REAL ballot? NO!
So, the voter never sees the ballot that gets counted; never has an opportunity to verify the accuracy of the ballot that gets counted; and never has an opportunity to challenge or correct errors in this ballot that gets counted.

Not only is the accuracy of ballots unverifiable in these electronic voting systems, the counting of votes is hidden as well - a fact that violates the Constitution, BTW! Voters have no access to the databases that store the data records that are the real ballots (those that are counted) and that are used to tabulate the vote totals. As you will discover in How to Hack the Vote, these tabulating computers ('tabulators') are so insecure, vote totals can be changed (even reversed) without any trace, in under 2 minutes, and, in some cases (such as in Ohio!), remotely over the Internet. Because electronic tabulators process vote totals unseen by any human, they entirely violate our process of open and verifiable elections.
Aw, you say, but computers do simple addition all day long - its what they do best! Count the rows in a database table and a computer will get the same result every time, right? Well not quite. Of the few audits conducted after the 2004 election NOT ONE AUDIT or machine recount delivered the same result as that reported as the final vote count! Seems our faith in tabulators is a little ill founded. And why, if tabulators are so accurate, as reported in John Conyer's subcommittee report investigating Ohio election irregulariies, did a Triad Systems computer technician, after reconfiguring tabulators in 'preparation' for a so-called recount audit, post the 'official' final vote count in the election office housing the tabulators and 'instruct' election workers to ignore the audit totals and use the posted vote total number he conveniently provided instead (This REALLY DID HAPPEN!)? WHY???
Tabulator PCs are at the heart of 'dirty' voting systems prevalent in 2004. They also counted 80% of the vote in 2004. States with as few as 2 counties with electronic voting machines (like Ohio), by contractual agreement with the electronic voting system vendors, are required to count (tabulate) all votes in the state using the vender's tabulating PCs and software. The 'required' tabulators accept and count the votes from all precincts, regardless of the voting machine employed. Additionally, processes, procedures, and constraints for recounts and audits are contractually stipulated with the vendors as well. Vendors designing electronic voting systems know beforehand exactly how an audit or recount will be performed and, in most cases, provide 'special' configurations under which such audits and recounts take place. That's what that Triad Systems technician was doing in Ohio. In other words, e-voting vendors are told how their systems might be tested and are allowed to change their system in preparation of any such test.

Tabulator PCs, as presently designed, offer the feature of easily changing vote totals without any trace, are highly configurable allowing a single candidate to be cofigured differently from other candidates, provide centralized control of all the electronic voting machines in a county or state, and count all the votes in a state regardless of the voting machine used. Electronic voting systems eliminate the counting of physical ballots, hide the real ballots from voters, and keep the vote counting secret. Consequently, there is virtually no way to detect malicious vote manipulation, no way to verify the accuracy of one's vote, and no way to ensure a fair election. How to Hack the Vote is a tutorial provided by one of the nation's leading "white hacker" computer security experts, Chuck Herrin. In it, you will learn how easily vote totals can be manipulated without any trace.

As you read "How to Hack the Vote", keep in mind one of the findings of John Conyer's subcommitee investigation of Ohio election irregularities. Ohio's tabulators were remotely accessed over the Internet before, during and after the 2004 election by the vendor (Triad Systems). Because these tabulator PCs were accessible by modem dial-up and/or Internet access, it doesn't take a vast conspiracy involving thousands of poll workers to massively subvert the vote. A handfull of connected PCs is all one needs to alter election results by millions of votes!.

These 'dirty' systems has destroyed the integrity of our voting. As it now stands, our voting systems can NOT and should not be trusted. As Americans, we can no longer look to the next election with any assurance that our votes will mean anything. The new voting systems are so easily compromised and so obviously designed to facilitate vote count manipulation that citizens are facing for the first time a future without hope. Without hope, our innate optimism is diminished, our drive to succeed impaired, and our ability to dream lost. That which makes us great as a people and a country will disappear within a generation.

With a compromised voting system, we are open to tyranny and a complete loss of control over our government and elected officials. Without any control on the exercise of power, we now face a very real threat to our democracy and our freedom. No citizen can dare sit idly by in the face of losing all that has brought our country greatness.
Reference Downloads
Rep. John Conyers Subcommitee Report (2.1Mb Adobe.PDF .ZIP file) John Conyers Letter to Triad Systems (.txt 1.2Kb file) VotersUnite's Myth Breakers (828Kb Adobe.PDF file) Chuck Herrin's "The Effect of Computers on the Integrity of Vote Tabulation" Presentation (718Kb Adobe.PDF .ZIP file)


How to Hack the VoteReturn to Top
How to Hack the Vote: the Short Version


11/10/2004 rev. 11/20/2004

Chuck Herrin, CISSP, CISA, MCSE, CEH

Source: http://www.chuckherrin.com


Enron was a conspiracy theory, too. Were their whistleblowers Crackpots?
Were the people who lost their retirements to those corporate criminals just "sore losers"?
I've never been part of the "Tin Foil Hat" conspiracy theory crowd. I'm just a voter who happens to be a Professional IT Auditor.

Author’s Note – Did our votes count? More importantly, will they count next time? We in Information Security have been protesting the use of the poorly designed voting machines from Diebold and others, and as a result of their poor implementation and widespread use, our election remains in question and our country remains bitterly divided. Many people feel that their votes didn’t count, and for good reason. THESE SYSTEMS ARE NOT WORTHY OF OUR TRUST! In an effort to bring this to your attention, I have put together this shortened document that will show you exactly how easy it would be to break into Diebold’s GEMS software, which is the software used to tabulate regional voting results. This software runs on regular Windows machines and counts the votes from multiple precincts that may have used touch screens (which have their own problems) or optically scanned punch cards, including absentee ballots. It is responsible for the accurate reporting of tens of millions of votes cast using these different types of ballots.

That’s right – even if you used the older systems like punch cards, your vote can still be Hacked when the numbers all come together. Wanna see how easy it is?

I am going to show you, step by step and with screenshots, how an attack against our election system could very easily steal a Statewide or even a National election without leaving a trace. This attack would be easy to carry out, difficult to detect, and exert enormous influence on the results, leaving the humble voter coldly left out of the decision-making process.

Here We Go… Oh wait – let me do some CYA stuff first:

**Important** - I would like to stress that this demonstration was performed locally on a system totally under my control, and no unauthorized access to any computer system occurred. The voting database used was the sample obtained from www.blackboxvoting.org, and this election does not reflect data for any election currently taking place. I want to be very clear that this is only a proof-of-concept demonstration, and at no time was actual voter fraud committed in order to prove a point. THIS IS A DEMONSTRATION ONLY, very similar to the well-documented demonstration Bev Harris performed for Governor Howard Dean recently on National television. Also, GEMS software is a trademark of Diebold, and Windows and Access are both copyrights of Microsoft, Inc.**

REQUIREMENTS:

Windows-based PC with 150megs free disk space and 128megs RAM (minimum)

A copy of MS Access. (“The Windows interface also means you can use your familiar office programs in conjunction with GEMS. For example, you can type and spell-check propositions or measures, in word-processing programs such as Microsoft Word® or WordPerfect®, then paste the text directly into the GEMS ballot layout screen”-- http://www2.diebold.com/dieboldes/GEMS.htm ).

The GEMS software is one place to get it:
http://freespeech.metacolo.com/GEMSIS-1-18-17.zip
There are plenty other places on the web.

A Sample Election Database - http://www.blackboxvoting.org/coloradospringscityelection.mdb is one from Colorado Springs, CO. Again, there are several out there.

With all that out of the way – OK! Let’s get started!

Step One: The Before Picture

This is the summary report run based on our sample election from Colorado Springs, CO. This is what the actual, official results looked like before I decided to cast “my vote”.

To get the results, we open GEMS, (username "admin", password "password")



Figure 1 - The opening GEMS screen Go to GEMS > Election Summary Report,

Figure 2: Choose the Election Summary Report for our Before Pictures


And here we go! The official Election Summary Report, as of right now. Note the timestamp at 23:59:07 - we'll come back to that in the Audit Log section.


Figure 3: Election summary report – before

Pay attention to District 3. Here we have Sallie Clark in District 3 winning by a 2/3 majority. But let’s say that for this scenario, Sallie’s daughter is my ex, or she supports gay marriage, or maybe she’s against deficit spending. Whatever – let’s say maybe she’s a Pinko Commie and must be stopped, so let’s have some fun…..

*Note – I do not actually know Sallie Clark or any of these election participants, and therefore cannot speak to her character. Again, this is just a demonstration.*

OK - now we know how the election was supposed to turn out. I do not need the GEMS software to see the results - I could use a software package called JResult (included with the GEMS software) to poll it, or as we'll see below, just go straight to the backend database and view the numbers from there. Having a copy of the GEMS software is not required to Hack the votes. It does show us what the Election Workers can see and what the ultimate vote counts will be.

Step 2: Getting in - The “Hard” Part

The biggest part of step two is getting into the Windows PC in question, either locally or over a network. This is the hardest part, but if anybody thinks that hacking into a Windows PC is hard, you should not be online right now. As anyone confronted with the continuing barrage of viruses, worm, and Hackers can attest, this part is not really a problem. In fact, let’s run through a few sample ways in, just off the top of my head:

If the GEMS machine is networked - (For remote facilities, the votes are transmitted to the central tabulation facility via a closed "Intranet", the Internet or modem.
http://eff.org/Activism/E-voting/20040818_diebold_accuvote-ts_v0.8.pdf )

1) Wander into the building, and quietly put a wireless access point on the same network segment as the Tabulation PC, maybe behind a copier somewhere, and then casually come in from across the street using a laptop and wireless card.

We know they're connected by modems, so:

2) Find the telephone number of the office the PC is located in, and use a “war-dialing” program such as ToneLoc to dial all of the numbers in that exchange looking for a hanging modem. This technique was made famous by the 1983 movie “Wargames” and it still works today. These machines typically have hanging modems installed, so this should be a fairly easy way in.

3) Come in through the Internet. It is reported that many of these machines are connected to the Internet to enable results to be queried using Jresult to pull data from the central PCs. Windows PCs on the Internet are inherently vulnerable, particularly if they’re not behind a firewall. Since a firewall would prevent the legitimate Jresult queries from being made, these machines are likely NOT firewalled and therefore at extreme risk for being compromised through their Internet connection. (“GEMS' standard Internet and reporting capabilities allow the election administrator to quickly report results” -- http://www2.diebold.com/dieboldes/faq.htm )

Then there are the REALLY easy ways….

4) If you’re an insider, you already have the phone numbers and any usernames and passwords you may need. Dial into the machine, authenticate normally, and then manipulate the data as explained below.

5) Again, if you’re an insider - walk up to the machine and use the keyboard and mouse. (Bev Harris and Herbert Thompson recently demonstrated for the state of CA how a 5-line(!) VB Script could change votes and then delete itself - http://www.wired.com/news/evote/

Most poll workers, despite being good, caring people, tend to be political enough to motivate them to volunteer. It’s just human nature to use the tools at your disposal to your advantage, and people have a remarkable knack for justifying even the worst acts if they can convince themselves that the cause is worthwhile.

Then again, some poll workers, like in Gaston County, NC are actual Diebold Employees! (Worst quote: "The county pays a technician from Diebold to operate its systems on Election Day. That person was in charge of transferring early votes from electronic storage to the counting computer.").
http://www.charlotte.com/mld/observer/news/local/10192340.htm

For more on physical access and ways in, check out Jim March's excellent review at: http://www.equalccw.com/dieboldtestnotes.html#appendixB

With a little time and creativity, other ways in are possible. You have probably already thought of a couple more, haven’t you?

Diebold's best defense to this point, as pointed out by following the link above, is the physical security - if you can't get to them, you can't hack them. But we KNOW that election workers, poll volunteers, and Diebold staff all have access and CAN get in. It would be very easy to write a little script to call into the GEMS machines or have the GEMS machines call back out and modify the results at any time. As Mr. March also points out, the IP address listed in the memo referenced on his site is part of a known block of addresses that would have bridged that machine to the Internet when it connected. Let's face it, a lot can go on when a machine is connected to a big bank of modems and a lot of people have the numbers, usernames, and passwords.

Also, there is home video of voting machines being taken home and stored by election volunteers. Watch the video at www.votergate.tv. No physical security in that case.

Side note for non-technical folks - Did you know that in Windows, C: drives are shared out by default? No? Well, they are. But there’s a super-secret Hacker trick to connect to them. You have to call it C$ instead of just C. The $ means it’s a “hidden” drive, but it is still accessible via the network! Pick any Class C (classes are how network addresses are broken up) range of network addresses on the Internet and I’ll guarantee that you can simply “map” someone else’s C: drive over the Internet and browse their hard drives without their knowledge.

Think this couldn't happen? Are you kidding? This happens every minute of every single day. American companies spend Billions of dollars a year trying to protect corporate computer systems from attack - would they do that for no reason?

In any case, once we have access we simply browse the C: drive of the server and go to the C:program filesGEMSlocalDB directory. Here we will find an Access database for each election named <NameOfElection>.mdb. With a copy of Microsoft Access, we open it and find that no, it is not even password protected. The directory it’s in isn’t protected or restricted in any way. The data is not encrypted or even encoded. It is as open as an email message, and this is where all of our voting data is stored. From here, you could add candidates, drop them from the ballots, or delete entire precincts, but all of that is too obvious. A very simple trick would be to switch candidate IDs (see Figure 5 to see what candidate IDs look like), which would cause the vote tallies to simply reverse. In fact, this looks like what may have happened in some Florida counties, where the vote totals were fine, but the party affiliations were almost exactly the reverse of the vote counts. This type attack would be unlikely to raise much suspicion, since the total number of votes cast and turnout numbers would not change. And since Hacking rule #1 is to not get caught, rather than add Homer Simpson to the race and have him win, we’ll be more “subtle” and just change the results.


Figure 4: The c:program filesGEMSlocalDB folder where all of our valuable data is stored

This is the Access database that is the back end for the entire system. Potentially hundreds of thousands of votes could be stored here on a central computer with no access control, no passwords, etc. When we open the database and view the Candidate table inside, we see:


Figure 5: The Candidate table

Ah ha! Look at the first and second columns - Sallie’s opponent, Linda Barley, was assigned 550 as a candidate number, and Sallie is candidate number 551.

From the CandV Table in the same database, we see that the Race ID is 221, and that their Key IDs are 541(Linda) and 542 (Sallie). The Key IDs are what we need to change the vote counts for. Remember that the original vote results were 4209 to 8291, Linda to Sallie. Let’s change that from a 2/3s victory to a shutout victory for the candidate who should have lost.

Step 3: Changing the Votes

I located the Linda’s ID, #541, in the CandidateCounter table and simply by clicking on the cell and typing with my number keys, I gave Linda 111 votes for every reporting unit. This isn’t really hacking – this is changing values in a table. Anybody who’s ever used an Excel spreadsheet has done this before.

There were 71 reporting units, so she should have 7881 votes now, an increase of over 3600 votes. I finally found a way to make my vote count! We’ll come back and check the math later to make sure there are no surprises. When you’re stealing an election, you want to make sure it comes out the right way!


Figure 6: Changing the votes inside the CandidateCounter table

This is repeated in the CandidateSummary table, since some records are cross-linked, and I want to know exactly how many votes I’m changing. **Note – since I’ve tried this, I have found that you can change the totals simply by changing the SumCandidateCounter table, but the results are less predictable due to the sloppy cross-linking and “Dirty” field in the Access DB.**

Once I was done adding 3672 votes to Linda’s tally, I decide to just wipe out all of Sallie’s votes, making her total 0. Pay attention – I just added 3672 votes to one candidate's results and deleted 8291 votes from another in about 45 seconds! Just click the cell, type 0, click the cell, type 0; I’m wiping out votes by the hundreds. Sallie now has 0 votes - hopefully she was so over-confident that she didn’t bother to vote for herself ;-). A real attacker would likely be more subtle to avoid suspicion, but again, this is a demonstration. Unfortunately, since many of the new machines do not produce a paper ballot, a manual recount would be very difficult, if not altogether impossible. This is a clear violation of many state election laws, but elections officials put them in place anyway. I wouldn’t withdraw $20 from an ATM without a receipt, but I guess my vote isn’t worth that much trouble.

Anyway, now that our results are changed, we save the database, and viola!
Step 4: Run the new summary report and declare my candidate the winner!


Figure 7: The new summary report with the results the way I wanted them

Note the final numbers for District 3 – 7881 to 0. Just as I expected, I was able to override the wishes of 11,963 voters and replace their ballots with my own. How hard was that?

My candidate wins in a landslide, although the voters actually voted 2-to-1 for her opponent. This took me about 5 minutes and a moderate exercise of skill. There were no passwords to crack, and all I had to do was figure out the way things were stored in an unprotected, clear text Access database, which fortunately, has been available on the web for quite some time for Hacker-types to practice on. In fact, with the widespread availability of the GEMS software, you can go in and create your own elections to practice on before ever venturing out to touch the real thing.
Step 5: Those Pesky Audit Trails

But what if someone notices? Now that my work fixing the election is done, all that remains is clearing up the audit trail.

From within the GEMS software, let's look at the audit log:


Figure 8: GEMS > Audit Log


Figure 9: Looking for evidence of tampering. See anything?

Above, we see at 23:59 where I viewed the summary report (Figure 3), then closed the GEMS software at 00:00:16. The next entry is at 00:44:56, when I logged back into GEMS and ran another summary report (Figure 7) at 00:45:08 showing the Hacked results. Note the timestamps on the 2 Summary reports earlier in this document - they correspond exactly to the Election Summary Reports that show our candidate winning, and then losing in a shutout. Do you see any evidence AT ALL in the Audit Logs that the votes were tampered with? We know they were - I just showed you step by step that it was done.

Nope! No evidence - so feel free to ridicule anyone who complains as a conspiracy theorist or whining sore loser!

Now, Diebold officially insists that this cannot be done, but as with this example, this has repeatedly been shown to be false. Diebold's staff knows it - in fact, in a memo by Diebold principal engineer Ken Clark in 2001, he says “Being able to end-run the database has admittedly got people out of a bind though. Jane (I think it was Jane) did some fancy footwork on the .mdb file in Gaston recently. I know our dealers do it. King County is famous for it. That's why we've never put a password on the file before.” (http://www.blackboxvoting.org/Oct2001msg00122.html and for more detail, http://www.blackboxvoting.org/bbv_chapter-13.pdf )

In a particularly humorous and distressing response to Diebold’s assertion that “Generated entries on the audit log cannot be terminated or interfered with by program control or by human intervention”, the folks at www.blackboxvoting.org actually trained a chimpanzee to delete the audit logs from an election database. You read that right – a chimp. Well, since it wasn’t a human or computer, I guess they’re technically correct. Here’s a link. http://blackboxvoting.org/baxter/baxterVPR.mov

Another audit log incident occurred during the Washington State primary just six weeks ago. Two interesting events took place here:

1) all entries are absent from the audit log between 9:52 pm and 1:31 am. This includes records of summary reports being printed during that time frame, which is something that is always logged by the system, and shows up when they are printed before and after that block of time. Here is the audit log: http://www.blackboxvoting.org/auditlog.PDF

2) Here are copies of the 5 sets of summary reports printed off during that missing time period, complete with timestamps showing that they were printed during that block of time and signed by the elections chief, Dean Logan.

http://www.blackboxvoting.org/resultspages.PDF

Can anybody guess what it means when you are missing audit logs for a specific block of time, and known events took place that should be reflected in the logs?

Look at our results again. It means you were Hacked!

Conclusions

Would you trust your bank account balance if their systems were this easy to hack? As a result of my hands on testing, I have absolutely no faith that my vote was counted or will be in future elections where this software is used. It is simply too easy to change! Any motivated insider or Hacker of moderate skill can change hundreds of thousands of votes with very little effort and almost no chance of being caught.

The best part is that if anyone tries to question the results, you can ridicule them and call them sore losers! Conspiracy theorists! But won’t this be caught in a recount? Check this out - with the new machines, YOU CAN’T DO A RECOUNT! There’s no paper trail. It’s the perfect crime.

This is the democracy we’re exporting to the rest of the world.

More links for your reference

http://www.blackboxvoting.org

http://www.blackboxvoting.com

http://www.equalccw.com/dieboldtestnotes.html

http://www.whatreallyhappened.com/flawfound.html

http://ustogether.org/Florida_Election.htm

http://ustogether.org/election04/FloridaDataStats.htm

http://www.rubberbug.com/temp/Florida2004chart.htm

http://ustogether.org/election04/PA_vote_patt.htm

http://www.thehill.com/morris/110404.aspx

http://www.makethemaccountable.com/

http://www.votergate.tv/

http://www.thomhartmann.com/

http://www.rense.com/general59/wastheohioelectionhonest.htm

http://www.ejfi.org/Voting/Voting-18.htm

http://www.raba.com/press/TA_Report_AccuVote.pdf

http://eff.org/Activism/E-voting/#info-sheets

http://www.mutanteggplant.com/singleagent.htm

http://www.dailykos.com/story/2004/11/16/225713/53

http://www.wired.com/news/evote/

http://www.pcworld.com/news/article/0,aid,115608,00.asp

"SpeedHacking the Vote" - For Those With a Flair For the Overly Dramatic
(1.6 Million votes, 3 time-stamped reports, 6 minutes, no traces)


Also, check out HackTheVote FAQ

You are free to distribute this document in its entirety or link to this page to help get the word out and change the system. Good luck! Let's get this stupid, stupid system fixed and get our democracy back!

Anybody who wants to try this themselves can get the GEMS software and this same sample database from www.blackboxvoting.org or the links earlier in the document. Go for it! Try it yourself - you'll see that it works. For any wannabe Hackers reading this, it doesn’t get any easier than that!

"Those who cast the votes decide nothing. Those who count the votes decide everything" -- Rush Limbaugh, November 24, 2000 (Also widely attributed to Josef Stalin)

Chuck Herrin, CISSP, CISA, MCSE, CEH

CISSP – Certified Information Systems Security Professional

CISA – Certified Information Systems Auditor

MCSE – Microsoft Certified Systems Engineer

CEH – Certified Ethical Hacker

Email me at chuckherrin.com

Copyright 2004 Chuck Herrin


DIEBOLD EXPOSEDReturn to Top
By providence or luck, IT professionals (including myself) had the opportunity to peer into the heart of Diebold's voting system development process. Inadvertantly, Diebold left their development FTP server open to examination over the Internet. Additionally, thousands of internal emails between programmers, system developers, and Diebold management were left accessible over the Internet as well. This exposure of Diebold's internal proesses, software code, and internal conversations gave IT professionals their first glimpse of the structure and inner workings of Diebold's voting systems.

What follows is an analysis of this wealth of Diebold data that provides a disturbing look inside Diebold's electronic voting system development.

The Case of the Diebold FTP Site

Part of the Voting and Elections web pages
by Douglas W. Jones
THE UNIVERSITY OF IOWA Department of Computer Science

Copyright © 2003. This work may be transmitted or stored in electronic form on any computer attached to the Internet or World Wide Web so long as this notice is included in the copy. Individuals may make single copies for their own use. All other rights are reserved.

Contents

Return to Top
  1. Background
  2. What We Already Knew
  3. What Can We Learn from the Diebold FTP Site
  4. A Warning
  5. Some Disturbing Answers
  6. Rebuttals
  7. Retractions and Reactions
  8. Conflicts of Interest
  9. The SAIC (and other) Risk Assessments
  10. Consequences

For a summary of this story, as of Aug. 6, 2003, see . The Diebold AccuVote TS Should be Decertified.


1. Background

Return to Table of Contents

On Feb. 4, 2003, employees of Diebold Election Systems admitted that they had been using an insecure FTP server to exchange and update some part of Diebold's software. Bev Harris had discovered the server by doing a Google search, and she wrote it up in the on-line journal Scoop. [See Scoop, Feb 5, 2003 and Scoop, Feb 10, 2003] This FTP server was taken offline on Jan 29, and it is alleged to have contained files with names like "rob-georgia.zip", large parts of GEMS (the Global Election Management System), and unknown other software.

Not surprisingly, this disclosure fueled considerable speculation about some vast conspiracy undermining democracy. On April 23, 2003, Britain J. Williams, chair of the NASED Voting Systems Board Technical Committee, wrote a rebuttal to the charges raised by Bev Harris. [See the PDF or HTML versions of this letter] This letter is as a defense of the procedures used by the State of Georgia and the FEC/NASED certification process on which Georgia certification rests. [see the FEC and NASED websites] It shows, among other things, that Georgia has stronger defenses, in some respects, than my own state of Iowa.

The Williams letter assures voters that whatever was found on Diebold's FTP site is irrelevant to the conduct of elections in Georgia because the only path from that site into a voting machine is through the FEC/NASED process and Georgia's certification tests. The letter also contains a bit of denial, for example, a statement that "the contents, or even existence, of the 'rob georgia' folder has not been established."

On July 8, 2003, Bev Harris posted the results of a preliminary examinaton of the files lifted from the Diebold FTP server. [See Scoop, July 8, 2003, Inside a U.S Election Vote Counting Program or Bev Harris's blackboxvoting.com web site; available in revised form from Bev Harris's blackboxvoting.org web site] The accompanying editorial, by the operators of the Scoop web site, included the the Internet address of a server from which this material could be downloaded and advice on how to crack the passwords. [See Scoop, July 8, 2003, Bigger than Watergate] The editorial urges people to make copies of the Diebold files and discuss what they find, and Harris created an on-line forum for this discussion of what was found. [See http://www.blackboxvoting.org/cgi-bin/dcforum/dcboard.cgi]

On July 9, Bev Harris posted specific rebuttals to the defense offered by Britain Williams in his April 23 letter. [See Scoop, July 10, 2003] This posting includes an extended transcript of an interview with Rob Behler, the 'rob' to whom the 'rob georgia' folder had been addressed. A more complete transcript of this interview is available. [See What really happened in Georgia? reposted at [IP] Interview with Georgia Diebold Election Machine installer] This interview makes it clear that the 'rob georgia' folder had nothing to do with an attempt to rob the state of Georgia, but it also makes it clear that the Georgia certification tests were, in reality, somewhat weaker than Williams had claimed, and that patches were indeed downloaded for these tests directly from the Diebold FTP site without passing through the FEC/NASED certification procedures, on the strength of a phone call to the source code auditor to determine that he wouldn't have considered the code in question to be subject to audit.

2. What We Already Knew

Return to Table of Contents

Prior to the disclosures and debate described above, we knew that Diebold Corporation had purchased Global Election Systems in 2001, which had purchased I-Mark Systems back in 1997; I-Mark was the original developer of the Electronic Ballot Station. Global had previously acquired the AccuVote mark-sense system, so naturally, they coined the name AccuTouch for the I-Mark Electronic Ballot Station. This system first passed through the FEC/NASED certification process on 9-10-96, in a kiosk configuration that incorporated CRT monitor. This original hardware was replaced by a portable flat-panel version that was certified on 12-5-97. That was the first version of the hardware I saw, when it came before the Iowa Board of Examiners for Voting Machines and Electronic Voting Systems on Nov 6. 1997. [The minutes of this meeting indicate that Bob Urosevich and Barry Herron represented Global Election Systems at that meeting.] The sales material from Governmental Business Systems provides a good summary of the overall use of the Global System. [See http://www.gbsvote.com/wi/accuvotets.htm]

ISO 9000

Diebold has emphasized, in some of their presentations about this system, that it was developed under an ISO 9000 compliant development process. While it is worth noting that ISO 9000 does not guarantee quality in the product, it does demand use of a well-documented quality assurance system. The important thing is that the system is well documented and that management structures are in place to assure that it is used. ISO 9000 does not guarantee effective quality assurance, only that failures should be tracable to problems that should be evident in the documentation.

Compatability and Modes of Use

The Electronic Ballot Station, in both its kiosk form and its portable flat-panel form, is built from IBM PC compatable parts. In the now widely used flat-panel form, it consists of a wedge-shaped enclosure holding a PC motherboard, flat-panel display and various anciliaries including a smartcard reader, disk, network interface, and a compact internal uninterruptable power supply. Aside from packaging, it is a full featured PC, and when security seals are removed from the various ports on the side, it can be used as one by adding appropriate devices.

The same hardware that runs as an Electronic Ballot Station can also run other software, specifically, the Electronic Poll Book software. There are two practical ways to use the AccuTouch (or AccuVote Touchscreen System) in a polling place: In one, the polling place handles voter sign-in conventionally and has a stock of several hundred pre-recorded smartcards, each of which can be used to enable one voter to cast one ballot on an Electronic Ballot Station. In the other, each polling place has an Electronic Poll Book at the registration table that is used to record, on demand, the authorization card for each voter. Global originally suggested using the same hardware to run the Elecronic Poll Book as they use for the Electronic Ballot Station, but I believe it is as easy to use a commodity laptop with a commodity external smart-card interface for this function.

There is a third alternative to the above two. Originally, I-Mark Systems had intended what they called the "vote anywhere model". In this model, the voter registration cards sent to each voter would be smartcards, allowing a voter to walk up to any voting machine in the county and cast a vote using only his or her voter registration card. In the extreme discussed in early I-Mark sales literature, unattended kiosk-format Electronic Ballot Stations were to be available in public places such as libraries and shopping malls. I have not heard of any jurisdiction issuing smartcards to voters.

Use of Third-Party Commercial Off-the-Shelf Components

From the start, it was clear that the AccuTouch Electronic Ballot Station used a version of Windows and various Microsoft Office components. At the examination in Iowa on Nov 6, 1997, when asked about this, one of the representatives of Global stated, firmly, that the version of Windows they used was purely unmodified commercial off-the-shelf software, and therefore not subject to a source code audit under the FEC/NASED certification rules. [This must have been either Bob Urosevich or Barry Herron, the two company representatives who were present at that meeting.] I discussed potential problems with this in my testimony before the House Science Committee on May 22, 2001. [See Problems with Voting System Standards]

The FEC/NASED Voting System Standards require that all software used in voting systems be passed through a source-code audit, but there is an exemption, in both the 1990 and 2002 editions of this standard, for unmodified third-party 'COTS' software, that is, commercial off-the-shelf software produced by a third party that has not been modified for use in the voting context. Use of Microsoft Windows and Microsoft Office clearly qualifies for this exemption.

The standards do require, however, that all third-party components be documented! For hardware components, this typically means vendor, model, model number and revision number, and the same requirement should be applied to software. That is, the vendor should not be allowed to state merely that a product is approved for use on Microsoft Office, but rather, the vendor must state the version on which it has been certified, and a change of version should require recertification. There is an excellent examples of a revision to Windows that actually destroyed voter privacy on an early version of the Fidlar and Chambers direct recording electronic voting machine. I discussed this example in my testimony before the House Science Committee cited above.

Unfortunately, the configuration documentation required by the FEC/NASED certification process is not public record, and in fact, all of the detailed technical documentation given by the vendor to the independent testing authority and the report of that independent testing authority is covered by nondisclosure agreements between the testers and the vendor. Only the fact of certification is public. Many states require configuration disclosure, however, and in many cases, these disclosures are, to varying extents, public. The states, however, have been sloppy and inconsistant about this! In Iowa, for example, it took us several years before we understood how partial the descriptions we were being given were; we have only recently begun to crack down on sloppy configuration disclosures, and to make a point of asking for model and revision numbers!

There is some debate about the word "unmodified". The narrowest interpretation would consider a third-party commercial off-the-shelf component to have been modified only if the source code for that component was changed. At the other extreme, any change to the out-of-the-box configuration of the component would count as modification. I suspect that extreme is wrong, but I also believe that the changes to the out-of-the-box configurations should be documented and subject to audit. If they claim to be using Microsoft Office XP with Service Pack 3, but with Word, Outlook, PowerPoint, FrontPage and SharePoint deleted, then this should be clearly stated and the audit should verify this configuration change.

Self Modifying Code

The FEC/NASED Voting System Standards explicitly forbid self-modifying code. There are several reasons for this prohibition, but the most important is the following: It is difficult to debug, prove the correctness of or audit software that is dynamically created at run-time. It is far easier to audit code that exists, in total, at the time of the audit.

There are disagreements about the nature of self-modifying code! Some would define it narrowly in terms of machine instructions that are overwritten by other instructions at run-time, while others define it broadly to include any dynamic linkage or interpretive execution, since all of these can be used to change the function of code after the fact.

Microsoft Windows makes extensive use of dynamically linked libraries and Microsoft Applications generally include interpreters for Visual Basic. In addition, it is natural to use mechanisms that border on interpretive for such things as formatting, as with HTML, or report generation, as with the ancient RPG language. The same considerations could lead to use of such mechanisms for ballot layout and canvassing, and in the past, it has been common for systems that border on being interpretive to evolve into fully developed general purpose interpreters; this happened with RPG. Depending on the interpretation of the restrictions on self-modification in the FEC/NASED Voting System Standards, use of these mechanisms could be problematic, and even if they are considered acceptable under the standards, their abuse introduces the possibility of security loopholes!

Communication and Security

Return to Table of Contents

AccuTouch Electronic Ballot Stations can be run in isolation, but the 1990 FEC/NASED Voting System Standards required that the totals for the precinct be automatically consolidated at the precinct, and this requires some communication between the machines at the precinct when more than one direct recording electronic voting machines is used. Some voting system vendors have opted to use local area networks for this, notably Fidlar and Chambers (which became Fidlar Doubleday), while others have opted to use hand-carried cartridges of various sorts; Diebold uses PCMCIA cards, ES&S uses special and somewhat chunky custom built bricks).

Once the data for the precinct is consolidated, it may be printed at the precinct, as is required in many jurisdictions, and it may be transmitted by any of several communications options to the central offices, where precinct reports may be tabulated and printed using GEMS. Among these options are the option of hand carrying the precinct results in a PCMCIA card and the option of transmitting the results by modem.

Programming the AccuTouch machine for a particular election is also done using PCMCIA cards written on the GEMS system at the central offices and then loaded into the voting machine, and the permanent record of the election that is stored for recount purposes is stored on a PCMCIA card (with a duplicate record stored on the internal hard drive of the voting machine in case of failure). The 2002 Examination Report for the state of Washington contains a good summary of the use of PCMCIA cards on this system. [See Sam Reed report of Sept 6, 2002]

The security of all of these network links, including those involving hand carried data, is critical! It is noteworthy that PCMCIA cards are about the size of playing cards and we know that sleight of hand trickery with playing cards is a highly developed art, so cryptographic security of the data on these cards is just as essential as it is for data transmitted over a public network.

In additional discussion at the first Iowa examination of the AccuTouch system on Nov 6, 1997, it came out that neither the technical staff nor salespeople at Global Election Systems understood cryptographic security. They were happy to assert that they used the Federally approved Data Encryption Standard, but nobody seemed to understand key management, in fact, the lead programmer to whom my question was forwarded, by cell-phone, found the phrase key management to be unfamiliar and he needed explanation. On continued questioning, it became apparent that there was only one key used, company wide, for all of their voting products. The implication was that this key was hard-coded into their source code!

The minutes of the meeting reflect this discussion but do not mention the cellphone conversation:

Dr. Jones also expressed concern about data encryption standards used to guarantee the integrity of the data on the machine. DES requires the use of electronic keys to lock and unlock all critical data. Currently all machines use the same key. Dr. Jones stated that this is a security problem. However, the use of a single key for all machines is not a condition that would disqualify the system under Iowa law.

The Iowa Secretary of State's office routinely forwards the minutes of these meetings to the vendor in question, so they did have both written and verbal notice of this serious security flaw; in addition, I wrote several paragraphs on this topic to the Elections Division of the Secretary of State's office on December 23, 1997:

[This] raises another issue that reflects a weakness in both the FEC standards and Iowa law. This weakness has been clearly present in all of the electronic reporting systems we have examined this year! The Wyle report takes it for granted that the use of DES encryption plus CRC error checking provides a sufficient guarantee of accuracy and integrity.

This is not true! First, as the Global representative I talked to informed me, the I-Mark system uses only a single DES key for all voting machines they manufacture. This is comparable to the situation you would expect if all ATM cards issued by some bank had the same PIN!

Unfortunately, there is no record of whether the Elections Division did or did not forward a copy of this note to the vendor.

I have frequently used this problem as an example of the weakness of the voting system standards; for example, I used it in my testimony before the House Science Committee in 2001. [See Problems with Voting System Standards]

I had hoped that this problem has long since been solved! At the examination, I explained to those present that the best practice was to dynamically create encryption keys at the time machines were configured for a particular precinct, so that only those machines were able to report results that would be interpreted as coming from that precinct. I also noted that it was not as important to encrypt the data as it was to use cryptographically secure signatures on the data. The big issue is the authenticity of the data reported from the precinct, not the secrecy, and in fact, in many jurisdictions, precinct totals are printed and posted in public prior to transmission as a measure to ensure that the canvassing process that computes overall vote totals can be audited.

3. What Can We Learn from the Diebold FTP Site

Return to Table of Contents

First, given what we already know about Diebold's products, it is no surprise to find Microsoft Access at the heart of their system. Questions about the appropriateness of using Microsoft products, in general, or about the appropriateness of using Microsoft Office components in an application that is critical to national security are very appropriate here, but nothing revealed by the Diebold FTP site is likely to change the answers to these questions. It was clear years ago that use of Access, Office and Windows is inappropriate in critical or high-security applications. [See Microsoft Access, when to use it and when not to use it or Microsoft Access -- Is it the right database for you?]

What we can learn from the Diebold FTP site are the answers to some very specific questions; had software from another vendor become available for an outside audit, I would likely have asked very similar questions, so this list should not be taken as implying any particular prejudice against Diebold's products:

  1. What third-party commercial off-the-shelf components are actually present in Diebold's software? We know that the contents of the FTP site are not, officially, the versions used in the certified versions of the software, but if we find evidence in these files that some third-party software was included in one or more versions of their system, we have strong reason to ask if that sofware was included in the configuration documents required for FEC/NASED certification and also required by several of the states for state certification.

    If comparison of what is found from the Diebold FTP site does not match prior disclosures under the FEC/NASED process or to the states, then we must ask:

    • Was this software present in the code submitted to the FEC/NASED certification process or to any of the states?

    • If present, was this software included on purpose by Diebold or its predecessors, or was its inclusion inadvertent?

    • If the software was inadvertently included, this would be evidence of serious quality control problems and possible failures in the ISO 9000 process.

    • If the software was intentionally included, there is the possibility that the nondisclosure was itself an accident. If so, this would be evidence of poor configuration management, a serious quality control problem and a possible ISO 9000 failure.

    • If the software was intentionally included, there is also the remote possibility of genuine fraud, the kind of thing the conspiracy theorists have come to expect.

  2. What changes, if any, were made to commercial off-the-shelf components? Were they installed out-of-the-box, or were the installations customized in any recognizable way? If the installation was customized, is there any evidence that the extent of customization was documented in the various configuration documents required by the FEC/NASED process or the states?

  3. Was any third-party software included in the system that was not commercial off-the-shelf software? If so, was the source code for this software included in the FEC/NASED certification process?

    If such software was included and the source code was not disclosed, there is a problem! Only commercial off-the-shelf software is exempt from the FEC/NASED source code review process. All other third-party software must be reviewed, including open-source freeware,

    Again, as above, failures to disclose non-commercial components could be either evidence of fraud or evidence of quality-control failures (an ISO 9000 issue).

  4. What uses of dynamic linkage are made by Diebold's voting system? are these necessary? Are there adequate protections to prevent dynamic linkage to code that has not itself been certified, or is it possible to cause linkage to code added to the machine later, for example, by a crook?

    There are companion questions to this: What uses of interpreters are made? Are they necessary? For each, are the protections adequate to prevent interpretation of code that has not itself been certified, or is it possible to cause interpretation of code added to the machine later, for example, by a crook?

  5. Do the current versions of the Diebold system use appropriate encryption methods and key management to guard the integrity of all data transmitted over external communications links, including hand-carried PCMCIA media? Whether or not they have replaced DES with a stronger encryption system, they should not be claiming that their encryption mechanisms are strong unless they can guarantee that their encryption keys have not been exposed through their FTP site! Ideally, new and randomized encryption keys should be generated by GEMS as the PCMCIA cartridges are created for each precinct.

4. A Warning

Return to Table of Contents

Note that the answers to many of these questions requires that someone who has access to the paperwork from the FEC/NASED process either see the material from the Diebold web site or see a report on what is found in the Diebold web site by others. Since access to the FEC/NASED certification documents is frequently covered by nondisclosure agreements, direct comparison with these documents may be difficult.

On the other hand, if someone who has access to these documents sees that examination of the Diebold web site has revealed something that ought to have been noted in these documents and was not, then I suspect that a public statement of this fact would not violate a nondisclosure agreement. Furthermore, it would seem to me that there is an overwhelming public interest in the disclosure of any apparent omission or inaccuracy found in the documentation submitted by any voting system vendor to the FEC/NASED process.

Whatever the answers to the above questions, any examination of the data extracted from the Diebold FTP site raises additional moral and legal questions. This data may be stolen property, although Diebold's placement of the data on an unsecured and fairly friendly appearing FTP site may constitute an invitation to public download and examination. Nonetheless, the entertainment industry's grip on the interpretation of copyright law is making the copying of electronic media, in all forms, increasingly problematic. On the plus side, for the researcher interested in this material, there are, apparently, no copyright notices in most of the files, but it is my understanding that the absence of such notices does not mean there is no copyright. Furthermore, some of the files are, apparently, encrypted, although Bev Harris tells me that encryption came and went from day to day. As I understand things, the unauthorized distribution of encryption keys for access to copyrighted data and the use of cryptanalytic software to find these keys is a threat to the DVD industry and therefore, in many jurisdictions, it is illegal.

Of course, the fair use doctrine allows quotation from copyrighted work for the purpose of review, and the work that needs to be done here is clearly an example of review, just as much as any literary review of a novel. Furthermore, so long as the copies are made for noncommercial purposes, that is, they are not used to run elections, the damage done to the copyright holder is minimal. A negative review by a book reviewer may severely damage the market for a book, but that damage can't be recovered by a lawsuit against the reviewer unless the reviewer lied about the book. On the other hand, book reviewers are expected to buy their books, not download them in encrypted form from the publishers web site and then crack the password.

There is a second issue that people must face before setting out to download copies of or examine the material from the Diebold FTP site. While novelists are not punished for having read other novels before they write their own novels, the interpretation being made of software rights today is quite different. If a programmer reads one piece of software and then develops software to do the same thing, that new sofware is considered tainted, and the developer of the original may have a legal claim to it! This is the basis of a major argument underlying the current lawsuit by SCO against IBM over IBM's contributions to Linux after having had access to the original Unix source code under licence from Bell Labs. Therefore, programmers interested in developing their own voting applicatons should probably be very careful to limit their exposure to any source code extracted from the Diebold FTP site.

That said, I believe that there is a compelling public interest in obtaining the answers to the above questions! Several of us have been warning for some time about weaknesses in the current FEC/NASED certification process, but public discussion of this process has been hampered, to a significant extent, by the fact that there has been no public access to any source code that has passed through the FEC/NASED mandated review process, and indeed, even the reports of the source code auditors under this review process are confidential.

There are parallels between this case and the case of the Pentagon Papers, where it is clear that they were, indeed, stolen property, but it was also clear that there was a compelling public interest in their disclosure and therefore the attempt by the government to suppress their publication was put down in the courts.

5. Some Disturbing Answers

Return to Table of Contents

On July 24, 2003, Tadayoshi Kohno, Adam Stubblefield, Aviel D. Rubin and Dan S. Wallach released a report on their examination of unencrypted code they had recovered from Diebold's web site. This paper has become known as the Hopkins paper. [See Analysis of an Electronic Voting System] (It is worth noting that I was unaware of this paper while I wrote the first 4 parts of this work!) This paper confirms that the Diebold web site contained not only code for the GEMS system used to manage elections, but also code for the AccuTouch terminal. Furthermore, this paper makes it quite clear that the errors I had pointed out to representatives of Global Election Systems when they first came to Iowa with the AccuTouch system have not been corrected in code that was available on Diebold's server half a decade later.

On reading the Hopkins paper, I immediately called for the decertification of Diebold's direct recording electronic voting system. I believe this is entirely justified by the magnitude of the security flaws identified in that paper, and completely independently, I believe it is justified by the fact that Diebold's predecessor, Global Election Systems, knew about that one flaw and did nothing to correct it over half a decade. Here is my call for decertification, in the form it was forwarded by Sandy Steinbach, Director of Elections for the Iowa Secretary of State's office. I have edited the E-mail addresses out of the mail header and replaced them with notes on affiliations of the recipients. The body of the E-mail is preserved with all my original typos.

From: "Sandy Steinbach"
Date: Wed Jul 23, 2003 04:47:04 PM US/Central
To: "Tom Wilkey" -- New York Elections office
  "Doug Lewis" -- The Election Center
  "Linda Lamone" -- Maryland Elections office
  "Brit Williams" -- Kennesaw State University
  "Douglas W Jones" -- Iowa Board of Examiners
  "Marilyn Jo Drake" -- Iowa Board of Examiners
  "Mike Mauro" -- Iowa Board of Examiners
Cc: "Chris Scase" -- Iowa Attorney General's Office
  "Tom Tully" -- Iowa Secretary of State's Office
  "Chris Ludlow" -- Iowa Secretary of State's Office
Subject: FYI Diebold Voting System

Folks:

Below is an excerpt from an email I received today from Dr. Douglas W. Jones, a professor of computer science at the University of Iowa and a member of the Iowa Board of Examiners for Voting Machines and Electronic Voting Equipment. I thought you would be interested in this.

Sandra J. Steinbach
Director of Elections
Office of the Iowa Secretary of State
515-281-5823

Excerpt from Dr. Jones' email:

Avi Rubin is publishing a paper tomorrow that will be discussed in the New York Times (I learned about it from a reporter for the Times). In this paper, he reports the results of his detailed audit of the source code for the Diebold (formerly Global) AccuTouch (or AccuVote DRE system). To my knowledge, this is the first time any code that has been certified to comply with the FEC/NASED voting system standards has come before any independent outside review.

This review is because the code was left, in openly accessible form, on Diebold's FTP site. See

http://www.cs.uiowa.edu/~jones/voting/dieboldftp.html
The Case of the Diebold FTP Site

for history of this strange story. As soon as I get a web link for Rubin's writeup (tomorrow, I assume), I will post it to that page as well.

Anyway, what has been revealed about the Diebold voting system is damning enough that I believe the system should be immediately decertified.

I did not call for decertification of the Diebold (previously Global) AccuVote optical mark-sense voting system. The work done by the Hopkins group calls into question the reliability of electronic reports from that system to the vote counting center, but with mark-sense voting machines, we have the actual paper ballots from the voters to recount, and (at least in Iowa), we require two paper copies of the precinct totals to be printed before any electronic transmission of the totals, one to be posted in public at the precinct, and the other to be hand carried to the vote counting center. This paper trail can be relied on even if the electronic transmission is corrupted or subverted.

In states that allow the official canvass of an election to be computed entirely from electronically transmitted totals, I believe it would be proper to decertify the Diebold's optical mark-sense system, or at least, to cease using the electronic communication features until such time as the vendor can demonstrate that they have eliminated the security flaws identified in the Hopkins paper.

Limitations of the Hopkins Paper

The Hopkins paper is not without its faults. Rebecca Mercuri posted a broadside to the web on July 24, 2003 that makes several important points. [See: Critique of "Analysis of an Electronic Voting System"]

I entirely agree with Mercuri that the biggest issue raised by the Hopkins paper deals not with Diebold but with the adequacy of the current FEC/NASED Voting System Standards. These standards are woefully inadequate when it comes to almost every aspect of security. Under the 1990 standards, the source code auditors who read the code for the I-Mark Electronic Ballot Station back in 1996 described it as the best voting system software they'd ever seen! This is despite flaws I found, without looking at the code, shortly after that, and it is despite the flaws that the Hopkins group identified that must have been present then. This brings into question not only Diebold's code, but the our entire current system for voting system certification.

In her critique, Mercuri notes, and I agree, that Diebold (and their predecessors Global and I-Mark) should not be criticized for their choice of C++ as an implementation language. In the first place, it takes years to develop a good voting system, and we should expect a mature system to use a language that looked like a good choice when development of that system began, without regard to languages that are considered, today, to be the best choice for new development.

In addition, it may actually be inappropriate to begin developing a voting system, or, for that matter, any software that is supposed to be subject to external audit, in a new language. The problem is, if you want your product to be auditable, you want to develop it in a language with a large user community that has had several years in which to develop mature coding standards. C++ remains an excellent choice when judged by this criterion, while Java has only recently grown in use to the point where it begins to qualify.

Mercuri also notes that the Hopkins group worked without clear knowledge of exactly the system on which the Diebold software runs. Indeed, they did not run it on an AccuTouch (or AccuVote Touchscreen) system, and they were unaware, apparently, that it was originally developed to run under Windows 95. At some point, I am unaware when, the product was moved to Windows CE (a sensible move, but see the next paragraph). The original I-Mark voting kiosk, on which this software was originally developed, was an off-the-shelf PC compatible system packaged in a kiosk housing and running Windows 95, and the first version of this system repackaged in a portable wedge-shaped enclosure still ran Windows 95.

On October 23, Joseph Holder, digging through archived Diebold internal E-mail, uncovered E-mail dated July 2, 2002 from Talbot Iredale at Diebold containing a dialogue with Rary Runyan about the installation of Windows CE version 3.00 release 20702. It is clear from this dialogue that Diebold considered it within their authority to install new releases of Windows CE to fix minor bugs in the voting system, even within a month of the use of that system in some election. It is also apparent from the discussion of application specific features discussed in the list of bug fixes that this version of Windows CE was very specific to the Diebold application. [See Re: WinCE 3.00 July 2, 2002 Release].

There is also the issue of election practices. Some of the criticism in the Hopkins paper is based on the assumption that the voting machine might be connected to a network. That is not the intent of the design, and the manuals for use of this system make it clear that all communication with the machine, prior to the time the modem is connected for reporting the results of an election, is done by hand carried PCMCIA cards.

I believe that these limitations do not seriously detract from the essential contribution of the Hopkins paper! The lack of evidence of any key management tools for the DES keys that are essential to the security of their PCMCIA cards and their modem-based communication of election results remains a fatal flaw, as does the complete lack of reasonable safeguards to secure the the smartcard interface.

The biggest issue Mercuri raises in her critique is that we have no evidence that the code that was found on the Diebold FTP site is actually the code running in any voting machines. This is true. We also have no evidence that it is not being used in any voting machines! The evidence we do have, however, is that code that was examined dates from around the years 2000 and 2002, while my stern warning to representatives of Global Election Systems about key management problems was delivered on Nov 6. 1997, not long after Global acquired I-Mark Systems, close to three years before the earliest version of the code examined by the Hopkins group. Whether or not this defect has been fixed today, the fact that it went unacknowledged for at least 3 and possibly 5 years is entirely unacceptable!

6. Rebuttals

Return to Table of Contents

On July 25, 2003, Diebold Corporation posted a rebuttal to the Hopkins Paper, posted to http://www.diebold.com/technical.htm and entitled Diebold - Technical Response To The Johns Hopkins Study On Voting Systems. On July 29, Bev Harris posted a response to this initial rebuttal to Scoop. [See Scoop, July 29, 2003] In her response, Harris shows how the version numbers from code found on Diebold's FTP site relate to the version numbers listed as having been approved on the NASED web site. This demonstrates that the versions tested by the Hopkins group were certainly closely related to production code. She points out that Diebold's claim that their software is constandly updated and improved suggests a development process that is far from what would be expected under a clean ISO 9000 development process, and she addressed several other points.

Diebold's first response was removed from the web and replaced with a collection of new material on July 29, all posted indexed under the "DIEBOLD IN THE NEWS" section of http://www2.diebold.com/default.htm.

These new postings included a rewrite of the original technical response [see Summary technical analysis of recent voting system report] and a press release [See Diebold Election Systems exposes flaws found in recent voting system report]. These preliminary responses were expanded on in the detailed technical response posted on July 30 [See Checks and balances in elections equipment and procedures prevent alleged fraud scenarios]. This latter document is a line by line examination of the allegations made in the Hopkins paper, far more thorough than Rebecca Mercuri's critique or anything I have posted above. It really cannot be read without a copy of the original Hopkins report in hand!

In summary, most of the Diebold rebuttal correctly identifies the weaknesses of the Hopkins report. Their detailed rebuttal is correctly named; it is indeed the case that procedures outside the software are central to defending against many of the attacks identified in the Hopkins paper. I have long held, voting systems cannot be properly evaluated out of context, and that the procedures and physical context in which they are used are as important as the mechanisms and machinery itself.

While most of the charges in the Hopkins paper are addressed effectively in this series of rebuttals, not all are, and the charges that remain are serious ones! The allegation numbers and responses quoted here are from Diebold's July 30 rebuttal:

Allegation #16 (p. 7):
"They may also be transmitted over Internet or dial-up connection."
Diebold Response
... in practice, the election data is not transferred over the Internet or dial-up connection. The election data (election.edb) is transferred to memory cards over disconnected local area networks at election central.
My Added Comment:
Security of PCMCIA cards requires the same level of care as security of netowrk transmission. Hand carried PCMCIA cards can be read and reprogrammed by pocket-sized computers! They are small enough for sleight-of-hand manipulation, and therefore, they are as vulnerable to attack as network packets -- true, the attacks are different, but strong cryptography is as justified for those hand carried PCMCIA cards as it is for any network communication!

Allegation #19 (p. 6)
"... we observed that the smartcards do not perform any cryptographic operations."
Diebold Response
Hypothetically, it would be possible to reverse engineer the password using the means described, but to describe the process as "easy" is an exaggeration.
My Added Comment:
This is an admission of weakness cloaked as a defense. The only question is, how hard should it be to crack a system. Does it need to stand up to a casual hacker, or should it also be defended well enough to fend off, say, a PhD student in computer security with no scruples and a strong desire to change the outcome of some election?

Allegation #21 (p. 9):
"Again, given the privacy of voting booths, an attacker using such a card reader would be unlikely to be noticed. ... an attacker could quickly gain enough insight to create homebrew voting cards ..."
Diebold Response
This is possible in theory ... Since the perpetrators would need to be at the polls, and sign in, this would seem to be a high personal risk for the few fraudulent votes that could be cast.
My Added Comment:
Again, they have admitted the technical point, while relying on polling place procedure. The vulnerability of actual polling places will be very low if there are only a few voters present, but the vulnerability goes up considerably if the crook shows up with the crowd and doesn't bother to sign in. Note that, in the old days of lever machines, the election workers primary job was to watch the machines and make sure that only authorized voters stepped into a machine and that each one cast only one vote. Nowadays, with modern security technology, poll workers will expect the smartcards or other enabling technology to assure this, and they may not be as vigilant as they once were. As Diebold points out, however, this entire approach to election fraud is only good for retail fraud, allowing a few extra votes to be cast by each participant. Retail fraud, however, is an old and widespread problem. That's one way that the classical dirty political machine remained in power, relying on the local ward boss to somehow stuff the ballot box as needed in each ward.

Allegation #22 (p. 10):
"More simply, instead of bringing multiple cards into the voting booth, the adversary could program a smartcard to ignore the voting terminal's deactivation command. Such an adversary could use one card to vote multiple times."
Diebold Response:
This is incorrect. We are not aware of a way to program the smartcard in such a way..."
My Added Comment:
I admit, I don't know my way around smartcards, but if I were trying to do this, I'd write an emulator for the smartcard in question that I could run on my PDA, and connect this through a short cable to a carefully built smartcard interface (it would look like a card, with contact pads in the right place and a cable coming out the edge of the card. This would be very similar to the tool an attacker would use to wiretap the dialog between the real smartcard and the machine in order to get the password. It wouldn't need to emulate the full card, just to carry out the expected dialog between smartcard and voting machine.

Allegation #26 (p. 10):
"Using a homebrew administrator card, ... if a malicious voter entered an administrator card ... the voter would be able to terminate the election ... an interesting denial of service attack.
Diebold Response:
While possible in theory ... the voter would have signed the roster to gain access to the voting machine, ... making this a high-risk attack.
My Added Comment:
Again, Diebold has admitted the weakness in their system and placed the burden on the poll workers. If an attacker manages to get to a voting machine without signing in, the risk to the attacker goes way down. See my comments on Allegation #21 for more on this.

Allegation #27 (p. 10):
"Even if the poll workers were later able to resurrect the systems, the attack might succeed in deterring a large number of potential voters ..."
Diebold Response:
Administratively "closing" or even "deleting" an election ... is an entirely reversible operation...
My Added Comment:
No it is not! Once a voter walks away from a polling place in disgust because the lines are long and the poll workers are busy untangling some kind of equipment snafu, whether caused by an attacke