Still in an early stage....
I'm using as a reminder, so... you may not like wasting your time reading it...
The OpenVote application is based on a contradictory principle,
- everybody has got to vote no more than once: you've got to check who actually voted
- everybody has to vote anounymously
Therefore we can imagine a system describing a vote procedure consisting of 3 actors, which are:
- the BPhone user
- an "electronic urn". It ensures people do not vote more than once.
- an "electronic vote counter". It
- the issuer generates a key pair (consisting of a public key, and a secret key)
- the issuer then actually polls to the BPhone user, publishing its public key with the polling message.
- the BPhone user encrypts his answer with the public key (he may have to fill missing bits with random data tp make encryption not vulnerable)
- he then transmits this encrypted answer to the electronic urn
- the electronic urn is then able to register this BPhone user as having voted. Not knowing the secret key, this urn is not able to watch what was the answer
- the electronuc urn then transmits the still-encrypted answer to the vote counter, not forwarding the identity of the voter.
This only works if the urn and the counter are two distinct entities. But they both have to know the list of phones able to vote.
issues. Apparently, this vote application is not intended for critical or electoral issues...
- there is no way of preventing someone from stealing a mobile phone, voting in the name of someone else. Biometry should be involved.
+ even if a message was to be intercepted, no one could translate it without knwowing about the secret key.
- separation between urn and counter has got to be clear. Will our users trust us? And they are to share informations: knowing about the voters, and submitting the vote content...
- both urn and counter operations should be logged. In a basic approach, in which the urn sends the vote content to the counter as it capitalized the voter, nothing virtually prevents the "voting system" from being checked, yet not preserving anonymity.
OpenVote Scenario
Thanks to Nils...
--------------------------------------+-----------------------------------+-------------------------------------------------------
| |
- mobile application | urn application | counter application
| |
--------------------------------------+-----------------------------------+-------------------------------------------------------
| |
- application launched | |
| |
- in "waiting" mode | |
| | - initialization:
| | - a list of voters
| | - the question to be submitted
| | - generating a public and a secret key
| |
| <------+---- transmits to the urn the list of voters
| - get the list of voters |
| | - polls every voter with the question
<---+-----------------------------------+---- transmission of the public key
- get the question | |
| |
- get the public key | |
| |
(notification bar) | |
--> onClick(): | |
--------------------------------------+-----------------------------------+------------------------------------------------------
VOTING TIME HAS BEGUN !!
--------------------------------------+-----------------------------------+------------------------------------------------------
- user input of his answer | |
| |
- message encryption using the | |
public key (possibly filling | |
a few bits) | |
| |
- post encrypted message ----------+----> |
| - got a response to this vote |
| |
| - mark the voter as having voted |
| |
| - send the encrypted answer, |
| not communicating the ID of the |
| voter ---------------------+--->
| | - using secret key to decode the vote content
| |
--------------------------------------+-----------------------------------+------------------------------------------------------
VOTING TIME IS OVER !!
--------------------------------------+-----------------------------------+------------------------------------------------------
| |
--------------------------------------+-----------------------------------+-----------------------------------------------------
For making it sure all votes are anonymous, maybe the urn should collect every answer before submitting all of them to the counter, as log traces of both urn and counter may allow to find out who voted and what he actually voted. (dis-synchronization)
This tool can't be intented to be used for official/legal elections as we cannot ensure that the actual submitter is actually the one owns the mobile. Furthermore, as this relies on the principle that urn and counter are two separate entities, we would have to be a trusted/certified center
mobile application prototype:
events:
-> (*) on_receive_voting_question
: notify
: insert question in DB
-> on_receive_vote_results
notifications:
-> (*) one (or more) questions to be answered
: click: show voting dialog displaying the effective question, what to answer
-> vote results availaible
screens:
-> write and submit a question
-> (*) display question, providing answers keys (type 1 for answer 1...)
: on_validate/on_submit
: basic checks (is_a_valid_answer)
: post/send message
: acknowldegement?
: update row related to this vote in DB
-> confirmation that vote is considered
-> results: voters, expressed votes, percentage
-> last votes (question+answer+result) summary
- display summary (list)
-> on_choose: open summary
first scenario : (*)
Comments (0)
You don't have permission to comment on this page.