Re: A Diebold network connection Question

From: Richard C. Johnson <dick_at_iwwco_dot_com>
Date: Thu Aug 18 2005 - 07:59:57 CDT

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.
 
Cheers!
 
-- Dick

Charlie Strauss <cems@earthlink.net> 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 sort 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 allegedly 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 scottatyner@yahoo.com
> (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:
>
> Article 41 NETWORK SECURITY
>
> 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
> arthur@openvotingconsortium.org
>

_______________________________________________
OVC discuss mailing lists
Send requests to subscribe or unsubscribe to arthur@openvotingconsortium.org

_______________________________________________
OVC discuss mailing lists
Send requests to subscribe or unsubscribe to arthur@openvotingconsortium.org
==================================================================
= 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:27 2005

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