Re: Diebold Global Election Management System (GEMS) Backdoor

In-Reply-To: <20040831203815.13871.qmail@www.securityfocus.com>

Diebold strongly refutes the existence of any "back doors" or "hidden codes" in its GEMS software. These inaccurate allegations appear to stem from those not familiar with the product, misunderstanding the purpose of legitimate structures in the database
. These structures are well documented and have been reviewed (including at a source code level) by independent testing authorities as required by federal election regulations.

In addition to the facts stated above, a paper and an electronic record of all cast ballots are retrieved from each individual voting machine following an election. The results from each individual machine are then tabulated, and thoroughly audited during
the standard election canvass process. Once the audit is complete, the official winners are announced. Any alleged changes to a vote count in the election management software would be immediately discovered during this audit process, as this total would
not match the true official total tabulated from each machine.


>Received: (qmail 16232 invoked from network); 31 Aug 2004 23:57:33 -0000
>Received: from outgoing.securityfocus.com (HELO outgoing3.securityfocus.com) (205.206.231.27)
> by mail.securityfocus.com with SMTP; 31 Aug 2004 23:57:33 -0000
>Received: from lists2.securityfocus.com (lists2.securityfocus.com [205.206.231.20])
> by outgoing3.securityfocus.com (Postfix) with QMQP
> id E09C823E6AA; Tue, 31 Aug 2004 14:57:44 -0600 (MDT)
>Mailing-List: contact bugtraq-help@securityfocus.com; run by ezmlm
>Precedence: bulk
>List-Id: <bugtraq.list-id.securityfocus.com>
>List-Post: <mailto:bugtraq@securityfocus.com>
>List-Help: <mailto:bugtraq-help@securityfocus.com>
>List-Unsubscribe: <mailto:bugtraq-unsubscribe@securityfocus.com>
>List-Subscribe: <mailto:bugtraq-subscribe@securityfocus.com>
>Delivered-To: mailing list bugtraq@securityfocus.com
>Delivered-To: moderator for bugtraq@securityfocus.com
>Received: (qmail 24082 invoked from network); 31 Aug 2004 14:29:26 -0000
>Date: 31 Aug 2004 20:38:15 -0000
>Message-ID: <20040831203815.13871.qmail@www.securityfocus.com>
>Content-Type: text/plain
>Content-Disposition: inline
>Content-Transfer-Encoding: binary
>MIME-Version: 1.0
>X-Mailer: MIME-tools 5.411 (Entity 5.404)
>From: "Jérôme" ATHIAS <jerome.athias@caramail.com>
>To: bugtraq@securityfocus.com
>Subject: Diebold Global Election Management System (GEMS) Backdoor Account
> Allows Authenticated Users to Modify Votes
>
>
>
>Date: Tue, 31 Aug 2004 00:38:05 -0400
>Subject: http://www.blackboxvoting.org/?q=node/view/78
>
>BlackBoxVoting.org reported a vulnerability in the Diebold GEMS central tabulator.
>
>A local authenticated user can enter a two-digit code in a certain "hidden" location
>to cause a second set of votes to be created on the system. This second set of votes
>can be modified by the local user and then read by the voting system as legitimate
>votes, the report said.
>
>GEMS 1.18.18, GEMS 1.18.19, and GEMS 1.18.23 are affected.
>
>The vendor was reportedly notified on July 8, 2003.
>
>
>Solution: No vendor solution was available at the time of this entry.
>
>Vendor URL: www.diebold.com/dieboldes/GEMS.htm (Links to External Site)
>
>

[Barry Fitzgerald]

I'll second that, with a strong emphasis on "Why should we trust a
company whose executives promise elections to the republicans?" or, for
that matter, the auditors selected by a government who has a vested
interest in election results?

-Barry



Polazzo Justin wrote:

>Can we get some source code to verify/disprove this? I notice there was
>no technical documentation/information from either side.
>
>Anyone else for coding Election Management Systems software under the
>Open Software License? :)
>
>Jp
>
>
>-----Original Message-----
>From: pressinfo@diebold.com [mailto:pressinfo@diebold.com]
>Sent: Tuesday, September 21, 2004 11:05 AM
>To: bugtraq@securityfocus.com
>
>
>
>
>

[Rainer Duffner]

Am Di, den 21.09.2004 schrieb pressinfo@diebold.com um 17:05:
> In-Reply-To: <20040831203815.13871.qmail@www.securityfocus.com>
>
> Diebold strongly refutes the existence of any "back doors" or "hidden codes"
> in its GEMS software. These inaccurate allegations appear to stem from those not
> familiar with the product, misunderstanding the purpose of legitimate structures
> in the database. These structures are well documented and have been reviewed
> (including at a source code level) by independent testing authorities as required
> by federal election regulations.

Last thing I remember is that these "reviews" resulted in a rather
devastating verdict for the product. Would you like to provide a link to
an updated, independant review ? Having the source-code opened would
help, too.
Also, IIRC, your company is now being sued at least by one US-state over
"false claims".



cheers,
Rainer
--
================================================== =
~ Rainer Duffner - rainer@ultra-secure.de ~
~ Freising - Munich - Germany ~
~ Unix - Linux - BSD - OpenSource - Security ~
~ http://www.ultra-secure.de/~rainer/pubkey.pgp ~
================================================== =

[Mike Ely]

Alright, I'll bite. After reading the blackboxvoting.org allegations,
and your response, I have a few more questions I'd like to see
answered. I'll take them point-for-point from your response:

> On Tue, 2004-09-21 at 08:05, pressinfo@diebold.com wrote:
In-Reply-To: <20040831203815.13871.qmail@www.securityfocus.com>
>
> Diebold strongly refutes the existence of any "back doors" or "hidden
codes" in its GEMS software.
Please explain the purpose of leaving in the apparent debug mode that
blackboxvoting has described. If the mechanism described is not a debug
mode, what does it do, and why would it be in production software?

>These inaccurate allegations appear to stem from those not familiar
with the product, misunderstanding the purpose of legitimate structures
in the database. These structures are well documented...
Can you please provide a link to this documentation, and perhaps an
explanation that offers more detail as to why you believe blackboxvoting
is wrong?

>and have been reviewed (including at a source code level) by
independent testing authorities as required by federal election
regulations.
Leaving aside the question of who paid these "independent testing
authorities," I would kindly suggest that if there is any mechanism
which the US public should be allowed to subject to a high degree of
scrutiny, it would be the mechanism by which we elect the people who
will be making decisions for us. There was no question as to how
punchcard machines worked - anybody with a screwdriver and some
mechanical aptitude could figure that out in a very short time. The
problem wasn't with how they worked; it was how well they worked that
led to grief. However, as a voter and a US citizen, I do feel that I'd
like to have the right to get my own second opinion on your software,
including any versions certified after the infamous GEMS code leak.
Please provide all GEMS sourcecode to the US public for further
examination.

> In addition to the facts stated above, a paper and an electronic
record of all cast ballots are retrieved from each individual voting
machine following an election.
The key problem here is that this paper record is created >after< the
election, leaving voters at the whim of any compromise that may occur to
a given machine >during< the election. In a paper ballot situation, the
ballot box sits in plain sight during the entire election, and is
physically locked at the close of the election. In the case of your
system, each voting booth takes the place of the ballot box for the
duration of the election, and is hidden behind a curtain or partition
with many anonymous people during this process. For the voter, there is
no guarantee that what is being stored to computer memory has anything
to do with the selections he or she just made, and no paper trail is
created until often hours after a voter has left the polling area.
Without an immediate paper trail being generated, the voter is at the
whim of whatever software happens to be loaded onto the touchscreen
computer in front of him or her.

> The results from each individual machine are then tabulated, and
thoroughly audited during the standard election canvass process. Once
the audit is complete, the official winners are announced. Any alleged
changes to a vote count in the election management software would be
immediately discovered during this audit process, as this total would
not match the true official total tabulated from each machine.
Again, this makes the assumption that the totals printed out of the
machine after all the voters have left would correctly reflect the
intent and belief of the voters who used it.

Unfortunately, without a voter-verifiable paper trail, it is possible
for a successful attack to occur. Without the minimal safeguards
mentioned above, this attack could go undetected. Regardless of how
many votes are compromised, any stolen vote is too many. Please take
the neccessary steps to ensure the complete integrety of the US election
process.


> >From: "Jrme" ATHIAS <jerome.athias@caramail.com>
> >To: bugtraq@securityfocus.com
> >Subject: Diebold Global Election Management System (GEMS) Backdoor
Account
> > Allows Authenticated Users to Modify Votes
> >
> >
> >
> >Date: Tue, 31 Aug 2004 00:38:05 -0400
> >Subject: http://www.blackboxvoting.org/?q=node/view/78
> >
> >BlackBoxVoting.org reported a vulnerability in the Diebold GEMS
central tabulator.
> >
> >A local authenticated user can enter a two-digit code in a certain
"hidden" location
> >to cause a second set of votes to be created on the system. This
second set of votes
> >can be modified by the local user and then read by the voting system
as legitimate
> >votes, the report said.
> >
> >GEMS 1.18.18, GEMS 1.18.19, and GEMS 1.18.23 are affected.
> >
> >The vendor was reportedly notified on July 8, 2003.
> >
> >
> >Solution: No vendor solution was available at the time of this
entry.
> >
> >Vendor URL: www.diebold.com/dieboldes/GEMS.htm (Links to External
Site)
> >
> >

[Marvin Bellamy]

pressinfo@diebold.com wrote:

>In-Reply-To: <20040831203815.13871.qmail@www.securityfocus.com>
>
>Diebold strongly refutes the existence of any "back doors" or "hidden codes" in its GEMS software. These inaccurate allegations appear to stem from those not familiar with the product, misunderstanding the purpose of legitimate structures in the databas
e. These structures are well documented and have been reviewed (including at a source code level) by independent testing authorities as required by federal election regulations.
>
>In addition to the facts stated above, a paper and an electronic record of all cast ballots are retrieved from each individual voting machine following an election. The results from each individual machine are then tabulated, and thoroughly audited durin
g the standard election canvass process. Once the audit is complete, the official winners are announced. Any alleged changes to a vote count in the election management software would be immediately discovered during this audit process, as this total woul
d not match the true official total tabulated from each machine.
>
>
>
You might have a little credibility if the back door hadn't been
demonstrated already on "Topic A With Tina Brown" (Howard Dean as guest
host). Maybe in your mind being able to rig a vote count qualifies as
"legitimate structures"? From your CEO:

"...[I am] committed to helping Ohio deliver its electoral votes to the
president."

But, I guess I'm just a paranoid, tin foil hat wearing conspiracy
theorist...

--
Marvin Keith Bellamy
Software Engineer
Innovision Corporation
913.438.3200

[Jacob Appelbaum]

On Wed, 2004-09-22 at 09:19, Jay Hennigan wrote:
> On Tue, 21 Sep 2004 pressinfo@diebold.com wrote:
>
> > In-Reply-To: <20040831203815.13871.qmail@www.securityfocus.com>
> >
> > Diebold strongly refutes the existence of any "back doors" or "hidden codes" in its GEMS software. These inaccurate allegations appear to stem from those not familiar with the product, misunderstanding the purpose of legitimate structures in the data
base. These structures are well documented and have been reviewed (including at a source code level) by independent testing authorities as required by federal election regulations.
>
> > >Vendor URL: www.diebold.com/dieboldes/GEMS.htm (Links to External Site)
>
> Heh. If the above URL indicates the competence level of Diebold, be
> very afraid. Note the prominent photo of a Sun server with the text
> touting Microsoft Windows.

What scares me is that the people at black box voting demonstrated using
a monkey to hack the election. An actual honest to go monkey as part of
their five (!) different methods to hack the vote.

For those that missed it five POC attacks on Die Bold:
http://www.blackboxvoting.org/?q=node/view/114&PHPSESSID=de909c061d97a933df77534fe04dc883

Five different methods to hack the vote, one of which uses a zoo animal.
It's so easy that it can almost be done accidentally. But it's important
to note, it's by *design* that it can be tampered with. The system was
designed without any regard to security.

If you or someone you know is interested in stopping things like this
from actually affecting the next election, you should call your
representatives *NOW*. Even if you aren't entirely interested in the
issue, you should ask them why they are buying products that are
demonstrably flawed. Ask them to change their systems before the next
election. People need to be held accountable for this. If the response
you are given is that it's not possible to implement it in time before
the election, simply ask for a paper ballot. A voter verified paper
trail makes voting accountable. It makes recounts possible, it means we
as a country make the choice, not Die Bold as a company.

Verified Voting Foundation (www.verifiedvoting.org) is also going to
provide an Election Incident Reporting System (EIRS) for the day of the
election. If you see something fishy, someone hacking the vote, someone
turning away voters, someone tampering, report it!

--
Jacob Appelbaum <jacob@verifiedvoting.org>

[Jose Rey]

At the The Electronic Voting Machine Project there is a Voting Machine
Project build from comodity and OSS

http://evm2003.sourceforge.net/

JR

Polazzo Justin wrote:
> Can we get some source code to verify/disprove this? I notice there was
> no technical documentation/information from either side.
>
> Anyone else for coding Election Management Systems software under the
> Open Software License? :)
>
> Jp

[Jeremy Epstein]

As someone who's been involved in the electronic voting controversy, I'd
like to add a few points:

(1) I agree that source code should be inspected by someone truly
independent and competent, and that the standards for approving voting
machines should be stronger. However, that's NOT the same as open source.
And I'd strongly discourage folks from calling for open source, as it plays
directly into the hands of folks like Diebold, who claim that the people
(like me) who want Voter Verified Paper Audit Trails (VVPATs) are really
trying to kill free enterprise. [Yes, I know all the examples of businesses
based on open source, but that's not what this is about.] As an example,
Harris Miller, the president of ITAA (www.itaa.org), a politically
influential consortium of technology vendors, is on record as having equated
the VVPAT groups with the open source community. So rather than putting
your energy into trying to get Diebold et al to move to open source, it
would be far more productive to put your energy into VVPATs. Towards that
end, I'll encourage everyone participating in this discussion to look at
www.verifiedvoting.org. VVPATs can give us the assurance we need of
accurate elections, without delving into the political morass of open source
and related topics.

(2) WRT the web page showing a "Sun server when discussing Windows", I hope
people realize that web pages for companies are made up by marketing people
who don't understand the difference. Don't hold that against them... There
are plenty of real reasons to oppose Diebold.

(3) WRT requiring that the technology protect itself in case the users
don't, that's simply unrealistic. In *any* real computer system, there are
expectations about the environment (e.g., the administrators aren't hostile
to the functioning of the system). It's important to state what those
expectations are, but there will ALWAYS be some that rely on non-technical
means. The important part about election systems is that they be explicitly
stated, and they be enforceable using non-technical means (e.g., by having
locks on doors). The problem today is that some of the assumptions (e.g.,
the vendor provided software doesn't have any bugs) are clearly unrealistic.

(4) WRT getting one set of software approved, and then installing another...
that's an old problem in any environment. The way it's supposed to work in
election systems is that a particular version is approved, and it's illegal
for the vendor to install something different. If there are teeth in the
law, and the vendor can be fined for installing illegal software, then it's
a reasonable non-technical measure. Of course, one could also use things
like cryptographic checksums to verify that what's installed is what was
approved. That still requires non-technical elements, such as that the
people who ran the checksums weren't deliberately trying to cover up a
change, the checksums were protected from tampering, the software that
calculated the checksums wasn't subverted, etc. [For those of us old enough
to remember, vendors were required to address this as part of "Orange Book"
evaluations, and are now required to address it as part of Common Criteria
evaluations.]

Bottom line, election systems are no different than any other systems in
that the security of the whole system is based on risk management. While we
should have higher expectations of election software than office automation
software, let's recognize what it is. IMHO, VVPATs are the only real way to
go.

--Jeremy

[Atom 'Smasher']

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

On Tue, 21 Sep 2004 pressinfo@diebold.com wrote:

> Diebold strongly refutes the existence of any "back doors" or "hidden codes" in its GEMS software. These inaccurate allegations appear to stem from those not familiar with the product, misunderstanding the purpose of legitimate structures in the databa
se. These structures are well documented and have been reviewed (including at a source code level) by independent testing authorities as required by federal election regulations.
>
> In addition to the facts stated above, a paper and an electronic record of all cast ballots are retrieved from each individual voting machine following an election. The results from each individual machine are then tabulated, and thoroughly audited duri
ng the standard election canvass process. Once the audit is complete, the official winners are announced. Any alleged changes to a vote count in the election management software would be immediately discovered during this audit process, as this total wou
ld not match the true official total tabulated from each machine.
==================

oops, looks like no one told you that this is a forum of computer security
professionals who understand the difference between a insecure machine and
a press release. you can "strongly refute" all you want: until the code is
available for public scrutiny it will remain suspect. but if it's written
as poorly as is rumored, exposing it to public scrutiny would only confirm
that it's insecure either through carelessness or intent.


...atom

_________________________________________
PGP key - http://atom.smasher.org/pgp.txt
762A 3B98 A3C3 96C9 C6B7 582A B88D 52E4 D9F5 7808
-------------------------------------------------

"I am committed to helping Ohio deliver its electoral
votes to the president [Bush] next year"
-- Walden O'Dell, CEO of Diebold
August 2003
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.3.6 (FreeBSD)
Comment: What is this gibberish?
Comment: http://atom.smasher.org/links/#digital_signatures

iQEcBAEBCAAGBQJBUS0VAAoJEAx/d+cTpVcippgIAI8Ska514i55Gc2qUp5ohOlD
AB98+5njJg6dEkNiCw3B6jQSm3WHSWxX45KMlvJypa+na1wNal oNZ6IsrMpqwwRq
O64blBv6s54uexIHw0oZcPqf/LTyg3CV4BtClZl+DZ7VjC/lWRl8PMTGj5tUTfD+
oXB8h7UdrycqsWubrG8UJ0JJeFWbVy98cvw3rjdTFSZXykai5P C8hFkwEHcqc848
7i93d4Qya3DdAAOFqaLWQt2wyegCDv8+r/qJa9VzDq9m7WNVshPyPfSiedh87gwo
81YzVqglhEdjE+gfjKFYXQub5TM3CppV99bsyd1oTLK3l86Jdt bz7ks/Uyn0Vs0=
=Dfkb
-----END PGP SIGNATURE-----

[Paul Wouters]

On Thu, 23 Sep 2004, Jeremy Epstein wrote:

> (1) I agree that source code should be inspected by someone truly
> independent and competent, and that the standards for approving voting
> machines should be stronger. However, that's NOT the same as open source.
> And I'd strongly discourage folks from calling for open source, as it plays
> directly into the hands of folks like Diebold, who claim that the people
> (like me) who want Voter Verified Paper Audit Trails (VVPATs) are really
> trying to kill free enterprise.

Free enterprise is not the issue here. Audit trails are. If it means that
somewhere someone cannot make a profit, then so be it. Unless you declare
democracy dead, and instate the Corporate Republic. The 'free market'
should not be a main consideration in voting security. If you cannot relay
that message to your government, then either you or your government is not
the right one for its task.

> the VVPAT groups with the open source community. So rather than putting
> your energy into trying to get Diebold et al to move to open source, it

Diebold has proven to not earn the trust of the public. It deserves to lose
money, or even go bankrupt. That's capitalism. You screw up and your product
no longer sells and you go do something else. Perhaps Diebold can go into
the playing cards business.

> (3) WRT requiring that the technology protect itself in case the users
> don't, that's simply unrealistic. In *any* real computer system, there are
> expectations about the environment (e.g., the administrators aren't hostile
> to the functioning of the system). It's important to state what those
> expectations are, but there will ALWAYS be some that rely on non-technical
> means. The important part about election systems is that they be explicitly
> stated, and they be enforceable using non-technical means (e.g., by having
> locks on doors). The problem today is that some of the assumptions (e.g.,
> the vendor provided software doesn't have any bugs) are clearly unrealistic.

We are talking about voting machines here, not general purpose operating
systems! They should be able to restrict and properly (and provably!) secure
a reasonably simple dedicated single purpose voting computer.

> (4) WRT getting one set of software approved, and then installing another...
> that's an old problem in any environment. The way it's supposed to work in
> election systems is that a particular version is approved, and it's illegal
> for the vendor to install something different. If there are teeth in the
> law, and the vendor can be fined for installing illegal software, then it's

A fine? No. They just be blacklisted from ever supplying voting machines to
the government again. Screwing up elections is not like hitting a red light
when there is nobody around.

> Bottom line, election systems are no different than any other systems in
> that the security of the whole system is based on risk management.

But I guess no one trusts the US government itself anymore if even Europe
is sending officials to watch over the elections:

http://news.bbc.co.uk/2/hi/americas/3666898.stm

And to counter your arguments, the Netherlands has open sourced its voting
system. You can download and verify it at http://www.ososs.nl/

Paul
--
"Non cogitamus, ergo nihil sumus"

[gandalf@digital.net]

Greetings and Salutations:

From: David Brodbeck
> You're missing the social dynamics around it. There are
> several parties
> involved:
<snip>
> - The public. They don't understand these issues either, and
> they have a short attention span.

Let me add one more social dynamic. The public will want to see instantaneous vote results, so eventually these computers will be networked to send the results back to a central voting computer ... And we are all familiar with how easily networked comput
er can be compromised if they aren't locked down. Now we are also discussing Man In The Middle attacks, etc.

(Which to me adds yet another social dynamic, if people see one person is winning that might change or sway their vote)

The OSes had *better* be locked down and secure. The only way to verify that is to either blindly attacked the box or have a open box that is inspected by real independent observers.

Ken
------------------------------------------------------------------
Do not meddle in the affairs of wizards for they are subtle and
quick to anger.
Ken Hollis - Gandalf The White - gandalf@digital.net - O- TINLC
WWW Page - http://gandalf.home.digital.net/
Trace E-Mail forgery - http://gandalf.home.digital.net/spamfaq.html
Trolls crossposts - http://gandalf.home.digital.net/trollfaq.html

[Tracy Bost]

I've been following this thread and bit and can't hold back my 2 cents .

Running voting machines on OSS software seems obvious its the only way
to do it correctly, since its true noone trusts each other.

Each polictical party can have their own team of hired geeks to make
sure the code stays clean and fair.
Otherwise, it become a finger pointing and guessing game.





Mike Healan wrote:

>> And I'd strongly discourage folks from calling for open source, as it
>> plays
>> directly into the hands of folks like Diebold, who claim that the people
>> (like me) who want Voter Verified Paper Audit Trails (VVPATs) are really
>> trying to kill free enterprise.
>
>
> I understand your point but I disagree with it entirely.
>
> Yes, I'm sure they'll grasp at any FUD they can to head off what they
> do not want. IMHO that shouldn't stop the call for open source
> software (OSS) to run those voting machines. Killing off free
> enterprise is clearly not the reason why people want OSS as, as you
> say, it is a different issue entirely.
>
> Australia's voting machines are electronic and the software running
> them is OSS. They don't seem to be having any problems with it. It
> must be nice to be able to fully trust that the vote just cast was
> recorded properly. That's a feeling I don't have here at home.
>
> Personally, I want a voting machine running code that any suspicious
> geek can double (triple, quadruple, etc) check and that verifies to
> me, on paper, that it recorded exactly which votes I cast. Considering
> that the future of the world's only global superpower depends on the
> outcome, I don't think that's too much to ask.
>
> Points 2 and 3 I'll agree with.
>
>> (4) WRT getting one set of software approved, and then installing
>> another...
>> that's an old problem in any environment.
>
>
> If I recall correctly, this is exactly what Diebold has been accused
> of doing in at least two states (Georgia, which concerns me directly,
> and California), has been sued for it and has even had their software
> decertified for it.
>
> Maybe OSS should be used and maybe it shouldn't. Given Diebold's
> record to date, I believe they should be barred from making *any* of
> these machines. I don't trust them and I sincerely hope I don't see
> their name stamped on the voting machine I use in 5 weeks.
>
>
>
> Regards,
>
> Mike Healan
> Editor
> www.spywareinfo.com
>
>
> Jeremy Epstein wrote:
>
>> As someone who's been involved in the electronic voting controversy, I'd
>> like to add a few points:
>>
>> (1) I agree that source code should be inspected by someone truly
>> independent and competent, and that the standards for approving voting
>> machines should be stronger. However, that's NOT the same as open
>> source.
>> And I'd strongly discourage folks from calling for open source, as it
>> plays
>> directly into the hands of folks like Diebold, who claim that the people
>> (like me) who want Voter Verified Paper Audit Trails (VVPATs) are really
>> trying to kill free enterprise. [Yes, I know all the examples of
>> businesses
>> based on open source, but that's not what this is about.] As an
>> example,
>> Harris Miller, the president of ITAA (www.itaa.org), a politically
>> influential consortium of technology vendors, is on record as having
>> equated
>> the VVPAT groups with the open source community. So rather than putting
>> your energy into trying to get Diebold et al to move to open source, it
>> would be far more productive to put your energy into VVPATs. Towards
>> that
>> end, I'll encourage everyone participating in this discussion to look at
>> www.verifiedvoting.org. VVPATs can give us the assurance we need of
>> accurate elections, without delving into the political morass of open
>> source
>> and related topics.
>>
>> (2) WRT the web page showing a "Sun server when discussing Windows",
>> I hope
>> people realize that web pages for companies are made up by marketing
>> people
>> who don't understand the difference. Don't hold that against them...
>> There
>> are plenty of real reasons to oppose Diebold.
>>
>> (3) WRT requiring that the technology protect itself in case the users
>> don't, that's simply unrealistic. In *any* real computer system,
>> there are
>> expectations about the environment (e.g., the administrators aren't
>> hostile
>> to the functioning of the system). It's important to state what those
>> expectations are, but there will ALWAYS be some that rely on
>> non-technical
>> means. The important part about election systems is that they be
>> explicitly
>> stated, and they be enforceable using non-technical means (e.g., by
>> having
>> locks on doors). The problem today is that some of the assumptions
>> (e.g.,
>> the vendor provided software doesn't have any bugs) are clearly
>> unrealistic.
>>
>> (4) WRT getting one set of software approved, and then installing
>> another...
>> that's an old problem in any environment. The way it's supposed to
>> work in
>> election systems is that a particular version is approved, and it's
>> illegal
>> for the vendor to install something different. If there are teeth in
>> the
>> law, and the vendor can be fined for installing illegal software,
>> then it's
>> a reasonable non-technical measure. Of course, one could also use
>> things
>> like cryptographic checksums to verify that what's installed is what was
>> approved. That still requires non-technical elements, such as that the
>> people who ran the checksums weren't deliberately trying to cover up a
>> change, the checksums were protected from tampering, the software that
>> calculated the checksums wasn't subverted, etc. [For those of us old
>> enough
>> to remember, vendors were required to address this as part of "Orange
>> Book"
>> evaluations, and are now required to address it as part of Common
>> Criteria
>> evaluations.]
>>
>> Bottom line, election systems are no different than any other systems in
>> that the security of the whole system is based on risk management.
>> While we
>> should have higher expectations of election software than office
>> automation
>> software, let's recognize what it is. IMHO, VVPATs are the only real
>> way to
>> go.
>>
>> --Jeremy
>>
>>
>
>

[Enrique A. Chaparro]

--Signature=_Tue__28_Sep_2004_01_33_05_+0000_+4GxbzI zsQM1G.XL
Content-Type: text/plain; charset=US-ASCII
Content-Disposition: inline
Content-Transfer-Encoding: 7bit

On Fri, 24 Sep 2004 10:01:59 -0400
Claudius Li <aprentic@sectae.net> wrote:


CL>
CL> So my question is, given that this seems to be a solved problem why is
CL> there so much debate on finding the solution? Surely I am missing
CL> something obvious.
CL>

Might seem to be, but it is _not_ a solved problem. Despite some
computationally secure protocols exist (some of them more recent
and slightly less cumbersome than those explained in Bruce's book),
the _practical_ implementation of such protocols is still extremely
complex, if even possible for large scale elections.

First objection is:
(a) if you're going to vote `remotely' (e.g., thru Internet) you have
no assurance at all that the `voting station' (i.e., voter's computer)
has not been tampered with. A well crafted worm, even if it exploits
well known vulnerabilities (users do not apply security patches very
often), may completely change the electio's result.
(b) if you are going to vote `locally' (i.e., using an `official'
voting station under election officials physical control), you still
have the same `blackbox' problems with the software _and_ all the
burden associated with cryptographic keys generation and distribution.

Second objection is:
Even if you were able to overcome the first objection (wich, in case
"b" above, will solve the issue for simpler methods), a secure system
requires _huge_ amounts of computing power (if you're thinking of large
scale elections, i.e. elections involving millions of voters)

Regards,

Enrique

--
``Izena duen guzia omen da.''

--Signature=_Tue__28_Sep_2004_01_33_05_+0000_+4GxbzI zsQM1G.XL
Content-Type: application/pgp-signature

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (GNU/Linux)

iEYEARECAAYFAkFYv1gACgkQjhuyRoeKKlwBhwCfZZLwgEflk/8x1bLkeJXYkXoe
W5QAoJjhrmYLG/u2nmzK5QBxmvxOfxnP
=71zU
-----END PGP SIGNATURE-----

--Signature=_Tue__28_Sep_2004_01_33_05_+0000_+4GxbzI zsQM1G.XL--

[Crispin Cowan]

If a vendor did a proper job of constructing a machine that conformed to
the VVAT spec, then open source would not be required *at all*. The
voter gets to verify the paper ballot before it is deposted in the
ballot box, and external oververs can physically inspect the ballot box
and the discard box to ensure that the right number of ballots are
deposited into each box.

OTOH, if the machine does *not* conform to the VVAT spec, then open
source is no where near sufficient to assure fair balloting, because the
vendor could supply source code all over the place, and then just
install trojan code at the last moment.

And that is the fundamental problem with all-electronic (no paper trail)
voting: a human observer on the outside cannot tell what is going on in
the chips and disks. You can get all the tripwire/opensource/checksum
report crap you want, but if a bad guy got access to the machine and
installed a trojan, then your reports are all a pack of lies, and no
amout of election observing by anyone will help.

That is why the VVAT isn the one and only answer to fair digital voting.
Open source is a distraction.

Crispin

Paul Wouters wrote:

> Free enterprise is not the issue here. Audit trails are. If it means that
> somewhere someone cannot make a profit, then so be it. Unless you declare
> democracy dead, and instate the Corporate Republic. The 'free market'
> should not be a main consideration in voting security. If you cannot
> relay
> that message to your government, then either you or your government is
> not
> the right one for its task.
>
>> the VVPAT groups with the open source community. So rather than putting
>> your energy into trying to get Diebold et al to move to open source, it
>
>
> Diebold has proven to not earn the trust of the public. It deserves to
> lose
> money, or even go bankrupt. That's capitalism. You screw up and your
> product
> no longer sells and you go do something else. Perhaps Diebold can go into
> the playing cards business.
>
>> (3) WRT requiring that the technology protect itself in case the users
>> don't, that's simply unrealistic. In *any* real computer system,
>> there are
>> expectations about the environment (e.g., the administrators aren't
>> hostile
>> to the functioning of the system). It's important to state what those
>> expectations are, but there will ALWAYS be some that rely on
>> non-technical
>> means. The important part about election systems is that they be
>> explicitly
>> stated, and they be enforceable using non-technical means (e.g., by
>> having
>> locks on doors). The problem today is that some of the assumptions
>> (e.g.,
>> the vendor provided software doesn't have any bugs) are clearly
>> unrealistic.
>
>
> We are talking about voting machines here, not general purpose
> operating systems! They should be able to restrict and properly (and
> provably!) secure a reasonably simple dedicated single purpose voting
> computer.
>
>> (4) WRT getting one set of software approved, and then installing
>> another...
>> that's an old problem in any environment. The way it's supposed to
>> work in
>> election systems is that a particular version is approved, and it's
>> illegal
>> for the vendor to install something different. If there are teeth in
>> the
>> law, and the vendor can be fined for installing illegal software,
>> then it's
>
>
> A fine? No. They just be blacklisted from ever supplying voting
> machines to
> the government again. Screwing up elections is not like hitting a red
> light
> when there is nobody around.
>
>> Bottom line, election systems are no different than any other systems in
>> that the security of the whole system is based on risk management.
>
>
> But I guess no one trusts the US government itself anymore if even Europe
> is sending officials to watch over the elections:
>
> http://news.bbc.co.uk/2/hi/americas/3666898.stm
>
> And to counter your arguments, the Netherlands has open sourced its
> voting
> system. You can download and verify it at http://www.ososs.nl/
>
> Paul


--
Crispin Cowan, Ph.D. http://immunix.com/~crispin/
CTO, Immunix http://immunix.com

[Coleman]

Here in Cincinnati, we've been using the punchcard system like the
infamous one in Florida for years. One thing that was not brought up in
this thread (or perhaps I missed it) is that the punchcard system can
pretty much be considered a low-tech "Open-Source" solution. The concept
of the system is quite simple, you use a pin to push out chads in a
punch card, and so everyone can understand it. In addition, after voting
any voter may (and should be) inspecting their cards to make sure the
punched holes are completely punched and there are no half-punches. You
should also count the number of punches you make to verify that they
match the punches on the card when you remove it. You should also have
checked your punchcard before using it to ensure that none of the chads
are pre-punched out. If you ever punch wrong, change your mind, don't
like the punchcard you got, or feel like hanging out at the booth
longer, you may go up and ask for a brand new card, you don't need a
legitimate excuse to do so.

This system inherently has a good deal of voter-based auditing built
into it. Any voter who goes up and discriminating voters can be pretty
confident that their card is operating correctly by inspecting it
themselves. The way Diebold's system is built, such auditing is
impossible.

Also to address the "Free Enterprise" claim. Free enterprise works well
for me buying what coffee I want, buying clothes, or which airline I
want to fly out to Chicago. The election system is not something to be
left up to "Free Enterprise", it should be scrutinized, regulated, and
IMHO be placed into the hands of an independent NPO funded by the public
to design such a system, openly. We have public forums on public works
projects, and even large development projects managed by community
planning departments. We fund public studies of transportation projects
5 years in advance of any groundbreaking in order to do an impact study.
Similar measures should be used in moving to a new voter registration
system.

On Sun, 2004-09-26 at 13:31, Mike Healan wrote:
> > And I'd strongly discourage folks from calling for open source, as it plays
> > directly into the hands of folks like Diebold, who claim that the people
> > (like me) who want Voter Verified Paper Audit Trails (VVPATs) are really
> > trying to kill free enterprise.
>
> I understand your point but I disagree with it entirely.
>
> Yes, I'm sure they'll grasp at any FUD they can to head off what they do
> not want. IMHO that shouldn't stop the call for open source software
> (OSS) to run those voting machines. Killing off free enterprise is
> clearly not the reason why people want OSS as, as you say, it is a
> different issue entirely.
>
> Australia's voting machines are electronic and the software running them
> is OSS. They don't seem to be having any problems with it. It must be
> nice to be able to fully trust that the vote just cast was recorded
> properly. That's a feeling I don't have here at home.
>
> Personally, I want a voting machine running code that any suspicious
> geek can double (triple, quadruple, etc) check and that verifies to me,
> on paper, that it recorded exactly which votes I cast. Considering that
> the future of the world's only global superpower depends on the outcome,
> I don't think that's too much to ask.
>
> Points 2 and 3 I'll agree with.
>
> > (4) WRT getting one set of software approved, and then installing another...
> > that's an old problem in any environment.
>
> If I recall correctly, this is exactly what Diebold has been accused of
> doing in at least two states (Georgia, which concerns me directly, and
> California), has been sued for it and has even had their software
> decertified for it.
>
> Maybe OSS should be used and maybe it shouldn't. Given Diebold's record
> to date, I believe they should be barred from making *any* of these
> machines. I don't trust them and I sincerely hope I don't see their name
> stamped on the voting machine I use in 5 weeks.
>
>
>
> Regards,
>
> Mike Healan
> Editor
> www.spywareinfo.com
>
>
> Jeremy Epstein wrote:
> > As someone who's been involved in the electronic voting controversy, I'd
> > like to add a few points:
> >
> > (1) I agree that source code should be inspected by someone truly
> > independent and competent, and that the standards for approving voting
> > machines should be stronger. However, that's NOT the same as open source.
> > And I'd strongly discourage folks from calling for open source, as it plays
> > directly into the hands of folks like Diebold, who claim that the people
> > (like me) who want Voter Verified Paper Audit Trails (VVPATs) are really
> > trying to kill free enterprise. [Yes, I know all the examples of businesses
> > based on open source, but that's not what this is about.] As an example,
> > Harris Miller, the president of ITAA (www.itaa.org), a politically
> > influential consortium of technology vendors, is on record as having equated
> > the VVPAT groups with the open source community. So rather than putting
> > your energy into trying to get Diebold et al to move to open source, it
> > would be far more productive to put your energy into VVPATs. Towards that
> > end, I'll encourage everyone participating in this discussion to look at
> > www.verifiedvoting.org. VVPATs can give us the assurance we need of
> > accurate elections, without delving into the political morass of open source
> > and related topics.
> >
> > (2) WRT the web page showing a "Sun server when discussing Windows", I hope
> > people realize that web pages for companies are made up by marketing people
> > who don't understand the difference. Don't hold that against them... There
> > are plenty of real reasons to oppose Diebold.
> >
> > (3) WRT requiring that the technology protect itself in case the users
> > don't, that's simply unrealistic. In *any* real computer system, there are
> > expectations about the environment (e.g., the administrators aren't hostile
> > to the functioning of the system). It's important to state what those
> > expectations are, but there will ALWAYS be some that rely on non-technical
> > means. The important part about election systems is that they be explicitly
> > stated, and they be enforceable using non-technical means (e.g., by having
> > locks on doors). The problem today is that some of the assumptions (e.g.,
> > the vendor provided software doesn't have any bugs) are clearly unrealistic.
> >
> > (4) WRT getting one set of software approved, and then installing another...
> > that's an old problem in any environment. The way it's supposed to work in
> > election systems is that a particular version is approved, and it's illegal
> > for the vendor to install something different. If there are teeth in the
> > law, and the vendor can be fined for installing illegal software, then it's
> > a reasonable non-technical measure. Of course, one could also use things
> > like cryptographic checksums to verify that what's installed is what was
> > approved. That still requires non-technical elements, such as that the
> > people who ran the checksums weren't deliberately trying to cover up a
> > change, the checksums were protected from tampering, the software that
> > calculated the checksums wasn't subverted, etc. [For those of us old enough
> > to remember, vendors were required to address this as part of "Orange Book"
> > evaluations, and are now required to address it as part of Common Criteria
> > evaluations.]
> >
> > Bottom line, election systems are no different than any other systems in
> > that the security of the whole system is based on risk management. While we
> > should have higher expectations of election software than office automation
> > software, let's recognize what it is. IMHO, VVPATs are the only real way to
> > go.
> >
> > --Jeremy
> >
> >

[Matthew Keller]

On Sun, 2004-09-26 at 13:16, Nicholas Knight wrote:
> Unrealistic? It is a *voting system*! It does exactly *one* *very*
> *simple* thing! If it cannot do it bug-free, its developers are
> incompetent and should not be allowed anywhere near a compiler, much
> less the key to democracy.

Thank you. This is the most rational post I've seen.

if(VoteForBush) { bush++; }
elseif(VoteForKerry) { kerry++; }
elseif(VoteForNader) { nader++; }

Is not tough. Diebold's refusal to allow the world to see that is highly
suspicious. I suppose I'll get sued under the DMCA for posting their
intellectual property now... Or maybe I have to change line 2 to:
elseif(VoteForKerry) { bush++; } first... There, let the lawsuits rain
in.

[Gareth Humphries]

>
>
>>>> Simon <lists@sime.org.uk> 29/09/2004 08:20:09 >>>
>Marco S Hyman wrote:
> >
> > All I demand from a voting system is that votes can be voter
verified.
> > That's not true of ANY voting machine regardless of who writes the
code
> > unless there is a hard copy audit trail. If there is a hard copy
audit
> > trail then it doesn't make any difference who wrote the code.
>
>How do you know that the software generating the audit trail is
playing
>fair if it's closed source?
>
>Sometimes, IMHO, there's just no alternative to pen and paper. Surely

>the manual method of ticking a box and having multiple human vote
>counters checking ballots is the best option going, even if it is more

>expensive. (I confess I've no idea what costs are involved either
way.)

But how can you trust the _COUNTERS_?

The problem is - there is always a weak link. There's always some part
of the process we cannot trust, what we have to decide is how much
mistrust we can tolerate, and where.
In the pen and paper system, it's sufficiently minimised through
accountability (if the boss catches you counting a 'Bob' paper, and
marking it down for 'Hank' - he'll fire you on the spot. He SAW YOU do
it), and dispersal (if there a 100,000 counters, and one is corrupt,
it's only 0.001% of the total votes at risk).

Walk into the booth, push the button for your candidate. The machine
prints a receipt which is visible behind a glass window. You look at
the receipt, and touch the 'Yes - thats correct' button. It then dumps
the receipt in a big box marked 'Audit' (or 'Plan "B"'), and you leave
the booth feeling happy. No garuntees about the software, but if a
recount based on paper eventuates - it's trustworthy.

In terms of the software though - how does this sound: Have the
machines run a cut down OS that distributes pre-compiled binary files of
open source packages (Ie RPM) - include on the system the python binary,
and associated libraries. Write all the code in python. You can now
pull the ACTUAL source code off of a voting machine after the election,
and audit it. You know its the software that was used, because, well,
you just used it. :-)
You can then run a checksum on the binaries used, to ensure they are
the same as the pre-compiled binaries distributed around the globe.
This only leaves the hardware still corruptable (and the BIOS, esp) -
perhaps have every booth supply an old 486+ touchscreen to install the
software on...



Gareth Humphries
IT Specialist
IBM New Zealand Ltd

__________________________________________________ __________________________________________________ __

This message contains information, which is confidential and may be subject to legal privilege.
If you are not the intended recipient, you must not peruse, use, disseminate, distribute or copy this message.
If you have received this message in error, please notify us immediately (Phone 0800 665 463 or info@linz.govt.nz) and destroy the original message.
LINZ accepts no responsibility for changes to this email, or for any attachments, after its transmission from LINZ.

Thank you.

__________________________________________________ __________________________________________________ __

[Adam Shostack]

On Mon, Sep 27, 2004 at 01:25:33PM +0200, Paul Wouters wrote:
| Diebold has proven to not earn the trust of the public. It deserves to lose
| money, or even go bankrupt. That's capitalism. You screw up and your product
| no longer sells and you go do something else. Perhaps Diebold can go into
| the playing cards business.

That's unlikely. The Nevada Gaming Commission is quite strict about
how it checks machinery, and Diebold would doubtless fail.

[Bruce Barnett]

> Let me add one more social dynamic. The public will want to see
> instantaneous vote results, so eventually these computers will be
> networked to send the results back to a central voting computer ... And
> we are all familiar with how easily networked computer can be
> compromised if they aren't locked down. Now we are also discussing Man
> In The Middle attacks, etc.

While the public would like this, the public would probably be denied
this option.

> (Which to me adds yet another social dynamic, if people see one person
> is winning that might change or sway their vote)

Exactly. This has happened. Districts in the Eastern Time Zone reported
the results, the people in the west coast would see the "preliminary
results", and decide not to vote because it "didn't make a difference."
In some cases, victory was declared because it was mathematically
impossible for a candidate to win without even counting the districts
in the Western time zones.

Now, the districts in the Eastern TIme Zone do not report the results
until those in the west coast CLOSE the polls.


I think having the voting machines disconnected from the network, until
reporting the results, is a requirement. A firewall can make sure only
outgoing connections are allowed, over a encrypted and verified
connection, AFTER the results are taken. This also makes sure that
every machine is given a fresh copy of the OS before the vote, and is
NEVER connected to any network (expect perhaps an isolated LAN in the
building) until the results are reported.

This would prevent DoS attacks during the day. Also - it would
be harder for a hacker to replicate the identity of a voting system
because the name and ID should not be determinable from the unconnected
system.

[Reed, Phillip C.]

Well there you go. Money is evidently more important than votes.

> -----Original Message-----
>
> Why can't this all be done the same way Nevada handles modern
> slot machines?
> For example if you are playing a slot in Nevada and feel it's
> not behaving
> there is a 24 hour toll free number you can call and the
> Nevada Gaming
> Commission and they will send someone out to tear the machine
> apart and
> verify (among other things) that the software image in the machine
> corresponds to an approved one that is on file with the Nevada Gaming
> Commission. Slot machines undergo a torture test that
> involves 20,000 volt
> tasers to the outer case, lights (to try and confuse the pay
> out mechanism)
> and so on. The source code is reviewed and approved, kept on
> file with
> approved binary images, etc.
>
> Seriously folks, if it can be done right for a nickel slot
> machine you think
> it could be done right for an electronic voting machine.
>
>
>

...phil

[Mike Healan]

> And I'd strongly discourage folks from calling for open source, as it plays
> directly into the hands of folks like Diebold, who claim that the people
> (like me) who want Voter Verified Paper Audit Trails (VVPATs) are really
> trying to kill free enterprise.

I understand your point but I disagree with it entirely.

Yes, I'm sure they'll grasp at any FUD they can to head off what they do
not want. IMHO that shouldn't stop the call for open source software
(OSS) to run those voting machines. Killing off free enterprise is
clearly not the reason why people want OSS as, as you say, it is a
different issue entirely.

Australia's voting machines are electronic and the software running them
is OSS. They don't seem to be having any problems with it. It must be
nice to be able to fully trust that the vote just cast was recorded
properly. That's a feeling I don't have here at home.

Personally, I want a voting machine running code that any suspicious
geek can double (triple, quadruple, etc) check and that verifies to me,
on paper, that it recorded exactly which votes I cast. Considering that
the future of the world's only global superpower depends on the outcome,
I don't think that's too much to ask.

Points 2 and 3 I'll agree with.

> (4) WRT getting one set of software approved, and then installing another...
> that's an old problem in any environment.

If I recall correctly, this is exactly what Diebold has been accused of
doing in at least two states (Georgia, which concerns me directly, and
California), has been sued for it and has even had their software
decertified for it.

Maybe OSS should be used and maybe it shouldn't. Given Diebold's record
to date, I believe they should be barred from making *any* of these
machines. I don't trust them and I sincerely hope I don't see their name
stamped on the voting machine I use in 5 weeks.



Regards,

Mike Healan
Editor
www.spywareinfo.com


Jeremy Epstein wrote:
> As someone who's been involved in the electronic voting controversy, I'd
> like to add a few points:
>
> (1) I agree that source code should be inspected by someone truly
> independent and competent, and that the standards for approving voting
> machines should be stronger. However, that's NOT the same as open source.
> And I'd strongly discourage folks from calling for open source, as it plays
> directly into the hands of folks like Diebold, who claim that the people
> (like me) who want Voter Verified Paper Audit Trails (VVPATs) are really
> trying to kill free enterprise. [Yes, I know all the examples of businesses
> based on open source, but that's not what this is about.] As an example,
> Harris Miller, the president of ITAA (www.itaa.org), a politically
> influential consortium of technology vendors, is on record as having equated
> the VVPAT groups with the open source community. So rather than putting
> your energy into trying to get Diebold et al to move to open source, it
> would be far more productive to put your energy into VVPATs. Towards that
> end, I'll encourage everyone participating in this discussion to look at
> www.verifiedvoting.org. VVPATs can give us the assurance we need of
> accurate elections, without delving into the political morass of open source
> and related topics.
>
> (2) WRT the web page showing a "Sun server when discussing Windows", I hope
> people realize that web pages for companies are made up by marketing people
> who don't understand the difference. Don't hold that against them... There
> are plenty of real reasons to oppose Diebold.
>
> (3) WRT requiring that the technology protect itself in case the users
> don't, that's simply unrealistic. In *any* real computer system, there are
> expectations about the environment (e.g., the administrators aren't hostile
> to the functioning of the system). It's important to state what those
> expectations are, but there will ALWAYS be some that rely on non-technical
> means. The important part about election systems is that they be explicitly
> stated, and they be enforceable using non-technical means (e.g., by having
> locks on doors). The problem today is that some of the assumptions (e.g.,
> the vendor provided software doesn't have any bugs) are clearly unrealistic.
>
> (4) WRT getting one set of software approved, and then installing another...
> that's an old problem in any environment. The way it's supposed to work in
> election systems is that a particular version is approved, and it's illegal
> for the vendor to install something different. If there are teeth in the
> law, and the vendor can be fined for installing illegal software, then it's
> a reasonable non-technical measure. Of course, one could also use things
> like cryptographic checksums to verify that what's installed is what was
> approved. That still requires non-technical elements, such as that the
> people who ran the checksums weren't deliberately trying to cover up a
> change, the checksums were protected from tampering, the software that
> calculated the checksums wasn't subverted, etc. [For those of us old enough
> to remember, vendors were required to address this as part of "Orange Book"
> evaluations, and are now required to address it as part of Common Criteria
> evaluations.]
>
> Bottom line, election systems are no different than any other systems in
> that the security of the whole system is based on risk management. While we
> should have higher expectations of election software than office automation
> software, let's recognize what it is. IMHO, VVPATs are the only real way to
> go.
>
> --Jeremy
>
>

[David Schwartz]

> If a vendor did a proper job of constructing a machine that conformed to
> the VVAT spec, then open source would not be required *at all*. The
> voter gets to verify the paper ballot before it is deposted in the
> ballot box, and external oververs can physically inspect the ballot box
> and the discard box to ensure that the right number of ballots are
> deposited into each box.

But surely a paper trail is inferior to a cryptographically secure voting
system? It's easier to verify millions of crptographic signatures than
millions of pieces of paper.

> OTOH, if the machine does *not* conform to the VVAT spec, then open
> source is no where near sufficient to assure fair balloting, because the
> vendor could supply source code all over the place, and then just
> install trojan code at the last moment.

So long as the mathematical scheme by which the votes were entered and
counted was itself secure, it matters not what the machine does. It will
either produce valid results or obviously invalid results. All you have to
do is devise the scheme so that it is computationally infeasible to produce
invalid, but valid looking, results. This is not a difficult mathematical
problem.

> And that is the fundamental problem with all-electronic (no paper trail)
> voting: a human observer on the outside cannot tell what is going on in
> the chips and disks.

Doesn't matter. You can't tell what's going on in the chips and disks when
you connect to 'https://www.amazon.com', but you can tell whether you
reached the Amazon server or not (assuming you trust the certificate
issuers). Similary, one can develop voting schemes (it isn't even difficult)
where it is not possible for the chips and disks to produce invalid results
that would pass automated inspections that anyone could do.

> You can get all the tripwire/opensource/checksum
> report crap you want, but if a bad guy got access to the machine and
> installed a trojan, then your reports are all a pack of lies, and no
> amout of election observing by anyone will help.

Exactly.

> That is why the VVAT isn the one and only answer to fair digital voting.
> Open source is a distraction.

I think the solution is mathematical. Devise schemes such that it's not
possible for a machine to produce valid-looking, but not valid, results.
This is not only not difficult, but already done. Even apparently
contradictory requirements are not really contradictory. For example, there
are schemes in which a person cannot prove how they voted, yet can prove
that their vote was not counted for the correct candidate if it in fact was
not.

DS