Likes Likes:  0
Resultaten 16 tot 22 van de 22
Pagina 2 van de 2 Eerste 1 2
Geen
  1. #16
    Matthew Keller
    Re: Diebold Global Election Management System (GEMS) Backdoor
    Gast
    n/a Berichten
    Berichten zijn liked



    Thread Starter

    Re: Diebold Global Election Management System (GEMS) Backdoor

    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.



  2. #17
    Gareth Humphries
    Re: Diebold Global Election Management System (GEMS) Backdoor
    Gast
    n/a Berichten
    Berichten zijn liked



    Thread Starter

    Re: Diebold Global Election Management System (GEMS) Backdoor

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

    __________________________________________________ __________________________________________________ __

  3. #18
    Adam Shostack
    Re: Diebold Global Election Management System (GEMS) Backdoor
    Gast
    n/a Berichten
    Berichten zijn liked



    Thread Starter

    Re: Diebold Global Election Management System (GEMS) Backdoor

    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.


  4. #19
    Bruce Barnett
    Re: Diebold Global Election Management System (GEMS) Backdoor
    Gast
    n/a Berichten
    Berichten zijn liked



    Thread Starter

    RE: Diebold Global Election Management System (GEMS) Backdoor


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

  5. #20
    Reed, Phillip C.
    Re: Diebold Global Election Management System (GEMS) Backdoor
    Gast
    n/a Berichten
    Berichten zijn liked



    Thread Starter

    RE: Diebold Global Election Management System (GEMS) Backdoor

    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

  6. #21
    Mike Healan
    Re: Diebold Global Election Management System (GEMS) Backdoor
    Gast
    n/a Berichten
    Berichten zijn liked



    Thread Starter

    Re: Diebold Global Election Management System (GEMS) Backdoor

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


  7. #22
    David Schwartz
    Re: Diebold Global Election Management System (GEMS) Backdoor
    Gast
    n/a Berichten
    Berichten zijn liked



    Thread Starter

    RE: Diebold Global Election Management System (GEMS) Backdoor


    > 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



Pagina 2 van de 2 Eerste 1 2

Webhostingtalk.nl

Contact

  • Rokin 113-115
  • 1012 KP, Amsterdam
  • Nederland
  • Contact
© Copyright 2001-2026 Webhostingtalk.nl.
Web Statistics