Re: A Diebold network connection Question

From: Richard C. Johnson <dick_at_iwwco_dot_com>
Date: Thu Aug 18 2005 - 16:28:04 CDT

Ron missed my intent (perhaps because I was less than clear) as to securing paper ballots. Any voter validated paper ballot (including the standard paper ballot) must be subject to secure procedures, whether digital versions are hovering nearby in the ether or not. The real question for paper is provenance--how does it move in the sneaker-net of the human-powered voting system? Are more or fewer or different pieces of paper counted than in fact were legitimately cast by the voters? Perhaps a poll watcher can tell, perhaps not.
One can easily be upset by things not seen and not understood. All digital processing, such as done by insurance companies, governments, corporations, and authorities of every description involves unseen manipulation, corruption, theft, and cheating. Often, this upsets me a great deal.
We could fix that by going back to pure paper, but that would not mean the paper was any better than the digits once out of our sight. The problem with paper as well is that it leaves our immediate view and control--important things happen to it when it is out of our sight. the end, I am afraid, paper offers very little more true security than digital information, unless very deliberate and extensive security measures are applied. I recommend using both in separate data paths and cross checking them in an audit. I also recommend recounts in which validated paper ballots are used; if the paper ballots differed markedly, I would certainly want to check security on both of them. There are no panaceas, no magic formulas, and we will only get the best available through a lot of smarts and hard work.
-- Dick

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 listsSend 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