Re: [election-services] Random key tokens and voting security

["David Webber \(XML\)" <david@drrw.info>]

Simon,

Just summarizing here what we discussed today between us
on being able to manage remote internet voting in a trusted
way.

There's two ways to go on this - one is using a human operator,
the other is having an electronic mediator.  Either work - I think
I'd prefer the human operator just for touchy-feely reasons and
also to have separation between machine process and the
number issuing - given that a human fraud runs at a much slower
rate (#'s that can be given out per hour!) than machine.  Also
humans can be observed, machines require automated
inspection.

Here's what I see the two looking like - they both follow
the same basic approach

1)  Absentee Voters are sent a mailing that includes
     internet access information and an access code.

2) They use the access code once polling starts to
    obtain a new private vote authentication code.
    (that private code is saved in a special separate
    list - independently - that will be used to
   authenticate votes during counting).

3) They use that second code online to gain access
    to cast a ballot.  Their vote is marked with the
    private code.

OK - here's the supplemental notes between the
human process v machine.

a) the voter telephones call-in center and
    reaches human operator who verifies them
    and their access code from the electoral roll.
    Operator then accesses a completely separate
    system that generates the special private vote
    code - and gives that to caller.  The separate
    system then saves that in the independent list.

b) all online method - voter accesses internet
    system that requests access code and
    random additional info - such as DOB,
    maiden name, place of birth, etc to authenticate.
    System then issues the private vote code, and
    as before - this is separate system - so saved
    to independent list.  Firewall can detect
    unusual IP address activity or other potential
    attacks.

Things to like about b) - no human involvement.
Less organizational overhead.

Things to not like about b) - trust - machine could
store private code against access code without
human knowing.  Collusion could result in thousands
of private codes being added to the approved to
vote list, that are then used for ballot stuffing.
Votes could be 'sold' more easily.

Things to like about a) human involvement (
volunteers get community service hours) and
trust of speaking to someone direct.  Observers
can watch operation.  Can guarantee separation
of verification system and voter access code system.
Harder to call in and spoof.

Things to not like about a) human could call a
friend and give out codes.  Difficult for deaf/dumb
person - they would need a proxy to help them
obtain the code.

Anyway - this is not a decision we need make - since
we can support either approach.

DW


----- Original Message ----- 
From: "Simon Bain" <sibain@tendotzero.com>
To: "David Webber (XML)" <david@drrw.info>
Cc: <election-services@lists.oasis-open.org>
Sent: Sunday, February 20, 2005 3:07 AM
Subject: Re: [election-services] Random key tokens and voting security


> Hi.
>
> To much open to abuse.
> Any system should be completely anonymous. It should enable the voter to
> log in to the system. There public credentials (login info, name etc)
> should then be dropped and the system should have in place already a
> completely seperate set of identifiers which it and only it knows. In this
> way there is very little chance that interference can take place on the
> system or by officials.
>
> If a hacker gets on to the system they cannot change an individuals vote,
> for a number of reasons the main one however being that the vote and the
> id is encrypted to an algorythm that the system has put into place, and as
> such is unknown. They can delete votes (This should be noticed by the date
> checks of data input) add information this again will be noticed and the
> info will not decrypt to a recognisable ballot.
>
> The first priority of any system must be security. If people believe that
> there is even a small chance of it being compromised they will not use it.
>
> Simon
> -- 
> Simon Bain
> TENdotZERO
> ----------
> Tel:    0845 056 3377
>         44 1234 359090
> Mobile: 44 (0)7793 769 846
>
> <quote who="David Webber \(XML\)">
> > I've realized another lynch-pin here is random key assignment
> > and access.
> >
> > In the polling station - random physical tokens are handed
> > to voters to enable a voting session on a DRM - after
> > their electoral roll entry is verified.
> >
> > For remote voters - a similar process may work.  Eg a
> > call-center where callers verify their credentials (they have
> > pre-registered and received an entitlement letter in the
> > mail with an activation code).  Then the call-center can
> > issue another code.  Such codes would have to be
> > one-time-use to prevent their sharing.   In an open
> > source environment there would need to be a
> > configuration value that seeds the code generator,
> > but that would remain secret along with the algorithm.
> > That would prevent people generating their own codes.
> >
> > The ballot counting software could then check for
> > valid codes by comparing to the list of those issued
> > by the call-centers.  As with the polling station - there
> > would be no indexing of codes to voters.  Of course
> > this is not quite as guaranteed to be anonymous, as the
> > call-center staff could record codes without the
> > caller knowing.  That's a trade-off between
> > remote voting and privacy and security compared to
> > the polling station.
> >
> > It's always the boundary conditions in systems
> > that are the most problematic - and somewhere
> > there has to be some level of trust.
> >
> > Another idea I like here is that call-centers can
> > be regional - so that minimizes chances for vote
> > selling.  You could tie callers to their own phoneID
> > numbers too for more physical verification much
> > as the credit card companies do already.
> >
> > DW
> >
> >
> >
> >
> >
> > To unsubscribe from this mailing list (and be removed from the roster of
> > the OASIS TC), go to
> >
http://www.oasis-open.org/apps/org/workgroup/election-services/members/leave_workgroup.php.
> >
>
>
> To unsubscribe from this mailing list (and be removed from the roster of
the OASIS TC), go to
http://www.oasis-open.org/apps/org/workgroup/election-services/members/leave_workgroup.php.
>
>
>