 |
HOME
PLAN A PROTEST
Email Congress
DONATE & LINKS
THE PROTEST STORE
Contact Us



|
|  |
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.
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
|
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.
ContentsReturn to Top
- Background
- What We Already Knew
- What Can We Learn from the Diebold FTP Site
- A Warning
- Some Disturbing Answers
- Rebuttals
- Retractions and Reactions
- Conflicts of Interest
- The SAIC (and other) Risk Assessments
- Consequences
For a summary of this story, as of Aug. 6, 2003,
see .
The Diebold AccuVote TS Should be Decertified.
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.
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!
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.
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:
- 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.
- 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?
- 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).
- 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?
- 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.
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.
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!
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
| |