Re: A Diebold network connection Question

From: Ron Crane <voting_at_lastland_dot_net>
Date: Thu Aug 18 2005 - 11:54:07 CDT
I am well aware of the archives of this forum. I am also aware that some officers of OVC do not consider the threats posed by firmware-based malware loaders to be important, and do not advocate rigorous hardware inspections. "COTS" is the usual answer, and it is insufficient, since a vendor secretly can install whatever firmware it wishes in "COTS" hardware -- firmware that cannot be detected without rigorous hardware inspections, such as Nevada's Gaming Control Board enforces for electronic slots. Further, nothing in the "archives" satisfactorily addresses e-voting's transparency shortcomings, VVPB notwithstanding.


Charlie Strauss wrote:
Ron you would do well to browse the archives of this forum.  the topic of how to secure paper and use electronic technology in an appropriate way is what OVC  is all about.  many things that bother you and practical details of paper handling, desiderata for secure elections is all in there over the last couple years.  

the concerns you have are legitimate ones that OVC seeks to provide well thought out solutions to.

Without condescending, I'll note the reason you hear a lot of silence to your questions on this forum is many of them are ones the founding members here have politely and patiently  answered a dozen times

On Aug 18, 2005, at 8:37 AM, Ron Crane wrote:

I now suspect that "secure paper" (e-casting and -counting of paper ballots) is likely to be less secure than plain paper. And it is inarguably less transparent: most members of the public do not understand it and cannot effectively supervise it. How do they know that the vendor or elections officials have not compromised the firmware in the casting stations, if they even happen to know what firmware is? How do they know there aren't wireless devices in the casting stations, if they even understand why that matters? How do they know that only appropriate information (and not, say, cheating applications) are being transferred over the machines' ethernet / modem ports (if any)? How do they know that elections officials have loaded the correct application into the machines on election day? (Oh yeah, officials are going to take the "check the cryptographic checksum" procedure seriously, and are going to let members of the public do it, too?) For the general public, it all comes down to trusting the experts. But, while there are many areas in which this is a rational and appropriate approach (e.g., medicine), I don't think voting is one of them. I suspect the founders would be horrified by the idea that an ordinary member of the public without special training or intelligence cannot effectively supervise vote counting. Yet that's where we are.

And Boss Tweed would be overjoyed at the number of potential cheats in e-voting of any kind.


Richard C. Johnson wrote:
Charlie has some good points.  My thoughts are simply that there should be (1) no DRE without a voter verified paper ballot and (2) paper rules.  That gives you the best combination of security and the benefits (such as they are) of electronic voting machines, although it all comes down to paper if there is a discrepancy.
Boss Tweed could teach you a thing or two about the security of paper ballots, even though Boss Tweed was surrounded by the Common Man.  Think secure paper, not just paper.
-- Dick

Charlie Strauss <> wrote:
There are four problem worth separating.

1) are VPN's secure?
VPN traffic is encrypted and can in principle be done securely,
though cracks might exist. A better approach to cracking it is to
attack the end points. VPN's require an authentication step to
commence. This has all the usual and imperfectly solved problems of
how to distribute the authentication key and keep it secure on both
ends. It could be a password. It could be some hardcoded shared
secret which is just a password hidden under a layer of software..
It could be a "smart card" which again is really a password hidden
under a layer of hardware. or a combination of these. You could try
to do some sort of biometric password but then you have yet another
problem of protecting the link to the biometric device.

It all these cases one has the problem that some s! ort of low level
software attack can let the user authenticate and then become a man
in the middle. E.g. some sort of kernel exploit.

A possibly even better way is to hack the Cisco VPN itself. It may
be susceptible to some sort of computer hack. Recently it turned out
nearly all cisco routers are hackable. Cisco denyed this till it was
proven in public. The exploit is not published yet thank god. But
the point is the Cisco VPN might be directly hackable.

2) assuming a secure and authenticated connection now what?
What passes down the pipe could still be an attack from either end on
the other. This means that the entire system is no longer
independent. Also the attack could go in either direction.
If one of the systems malfunctions during the connection, will the
other detect it and recover in a safe state? (e.g. will the precint
machine falsely beleive it's data was transferred successfully?)

3) Will the data be transferred correctly?
seems like an obvious question but there's multiple examples of
bothced handshaking that lost actual votes. Sequoia's database
loading software stopped loading after 32,000 records, losing 12,000
in Bernalillo county NM. ES&S's ivotronic system had a couple bugs.
first it could not read the second "redundant" memory module
correctly and then the handshaking failed to notice that it had been
read incorrectly and failed silently.

It's much easier to validate an inactive object like say a paper
printout, bar code, or rom than it is an ephemeral electronic
transmission. It's also safe to load that cd-rom into any number of
third party devices to duplicate it, read it, and check it. With an
electronic connection you dare not let some third party on your
network to witness it.

4) It's not transparent and thus should not be used.
How do I know it is off during election day? (diebold alle! gedly left
there's on during election day in CA). I mean how do I, joe voter,
really know. It's not enough that the elderly precint judges are
satisfied. How do I witness the transfer. How do I know the tunnel
is securely encrypted. How do I know what goes on at the City hall
side. How does city hall know what goes on on the precint side.

On Aug 17, 2005, at 10:34 AM, Kathy Dopp wrote:

> A Question from Scott in MS
> (this may also apply in UT)
> The following is a term of the Diebold contract with
> the state of Mississippi. It is taken verbatim. This
> looks like an internet connection between Diebold and
> our (Mississippi's) election equipment and software.
> Please give your feedback on this:
> Contractor [Diebold] and MSOS [Mississippi Secretary
> of State] understand and agree that the! State of
> Mississippi's Enterprise Security Policy mandates that
> all remote access to and/or from the State network
> must be accomplished via a Virtual Private Network
> (VPN.) If the parties agree that remote access is
> required at any time during the life of this
> Agreement, Diebold and MSOS agree to
> implement/maintain a VPN for this connectivity. This
> required VPN must be IPSec-capable (ESP tunnel mode)
> and will terminate on a Cisco VPN-capable device (i.e.
> VPN concentrator, PIX firewall, etc.) on the State's
> premises. Diebold agrees that it must, at its own
> expense, implement/maintain a compatible
> hardware/software solution to terminate the specified
> VPN on Diebold's premises.
> The parties further understand and agree that the
> State protocol standard and architecture are based on
> industry-standard security protocols and manufacturer
> engaged ! at the time of contract execution. The State
> reserves the right to introduce a new protocol and
> architecture standard and require Diebold to comply
> with same, in the event the industry introduces a more
> secure, robust protocol to replace IPSec/ESP and/or
> there is a change in the manufacturer engaged.
> _______________________________________________
> OVC discuss mailing lists
> Send requests to subscribe or unsubscribe to

OVC discuss mailing lists
Send requests to subscribe or unsubscribe to

_______________________________________________ OVC discuss mailing lists Send requests to subscribe or unsubscribe to

OVC discuss mailing lists
Send requests to subscribe or unsubscribe to

_______________________________________________ OVC discuss mailing lists Send requests to subscribe or unsubscribe to

OVC discuss mailing lists
Send requests to subscribe or unsubscribe to
= The content of this message, with the exception of any external
= quotations under fair use, are released to the Public Domain
Received on Wed Aug 31 23:17:28 2005

This archive was generated by hypermail 2.1.8 : Thu Sep 15 2005 - 11:44:12 CDT