Re: A Diebold network connection Question

From: Edmund R. Kennedy <ekennedyx_at_yahoo_dot_com>
Date: Thu Aug 18 2005 - 11:07:14 CDT

Now now children. Let's play nice.

Thanks, Ed Kennedy

--- Charlie Strauss <cems@earthlink.net> 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.
> >
> > -R
> >
> > 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.
> >>
> >> 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
> 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
> 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
> >
> > _______________________________________________
> > 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

-- 
10777 Bendigo Cove
San Diego, CA 92126-2510
858-578-8842
Work for the common good.
My profile:  <http://geocities.com/ekennedyx/>
I blog now and then at:  <http://ekennedyx.blogspot.com/>
_______________________________________________
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:28 2005

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