Halalan

Multiple Election Instances Halalan In The News

2 Comments (+add yours?)

1. Paul Nollen
   Mar 25, 2010 @ 18:30:13

   Hello,

   We are very interested is your voting program. We think it may be useful for us when we start with our “direct democracy” initiative here in Belgium (Europe) and we are reading as much as possible about your program in order to make a choice.

   I read on the developers page:
   Halalan 1.5.0-alpha Released
   voter page for viewing/printing/downloading of votes,

   This is a very important issue because voting fraud is one of the problems with computer voting systems.
   In another description of a voting program I found that they developed a sollution maybe comparable with what you propose. It is in German and I try to translate it (my native language is Dutch)

   http://liquidfeedback.org/

   Um zu verhindern, dass verschiedenen Teilnehmern unterschiedliche Datenbestände angezeigt werden können, sollten die Datenbestände den Teilnehmern auch als Download zugänglich gemacht werden. Durch eine weitergehende Aufbereitung und Veröffentlichung der Daten innerhalb der einsetzenden Organisation kann allen Teilnehmern die Möglichkeit gegeben werden, die Stimmenauszählung zu überprüfen, ohne dass hierbei den Administratoren des Systems vertraut werden muss.

   LiquidFeedback lässt sich so konfigurieren, dass angemeldeten Benutzern regelmäßig erstellte Archivdateien zum Download bereit stehen. Diese Archive enthalten alle abstimmungsrelevanten Daten incl. Namen bzw. Pseudonymen der Abstimmenden. Andere sensible Daten wie Passwörter oder E-Mail-Adressen sind jedoch ausgenommen. Auch das Feld “Realname” und die weiteren Inhalte der Benutzerseiten sowie gespeicherte Kontakte sind aus Datenschutzgründen nicht im Download enthalten.

   the possibility can be given to all participants to examine the counting of votes without the need to trust the administrators of the system. Liquid feedback can be configured in such a way that it regularly provide archive files to the users ready for the download.
   These archives contain all vote-relevant data inclusive. Name and/or aliases and co-ordinations. Other sensitive data such as passwords or email addresses are however excluded. Also the field “real name” and further contents of the user sides as well as stored contacts are not contained in the download.

   As far as I understand it, they provide on regular basis a list of aliases (or whatever characters the voter has registered) and the voting results. That way everyone can check his vote without revealing his identity and vote results can not be changed once they are published for download.
   I read that you also provide a personal “paper trail” of the vote but i don’t know what data it contains.

   Kind Regards

   Paul

2. Paul Nollen
   Apr 11, 2010 @ 20:35:07

   Hi,

   the Helios “open audit” voting system may be of interest to you

   Kind regards

   Paul

   Electing a University President using Open-Audit Voting:

   Analysis of real-world use of Helios

   http://ben.adida.net/research/ucl-helios.pdf

   Voting over the Internet.

   Many voting security experts believe that voting over the Internet is the most troubling of all proposed voting system evolutions [16]. Even if one sets aside the risk of coercion (as UCL did, given the lowcoercion setting), there remains the problem of the end user’s computer and the relatively widespread compromise of consumer operating systems, e.g. the numerous and well documented botnets [1]. Helios 2.0, like its predecessor, does little to specifically counter the threat of client-side operating-system or web-browser compromise; a specifically targeted virus could surreptitiously change a user’s vote and mask all of the verifications performed via the same computer to cover its tracks. In this deployment, UCL believed that the likelihood of such an advanced attack against the UCL election was extremely unlikely. UCL also made available a set of secured client machines for voters who wished to use an official voting machine. It should be noted, however, that UCL and the authors do not endorse the use of Helios 2.0 for large, high-stakes, governmental elections where the threat of a targeted virus would be far more realistic.

   ……..

   Tallying and Election Verification in the Browser. In order to make the simplest use case as easy as possible, Helios 2.0 includes a web-based election tallying program and election verification program, using the same Javascript & HTML technology as the ballot verification program. This approach does not scale well to more than a few dozen votes, given browser limitations, so UCL implemented its own, high-speed, offline tallier and verifier (See Section 3).

   ………..

   2.3 Machine Interface for Modular Authentication

   By default, Helios authenticates users by email address and an election-specific password. This password is generated by Helios upon voter registration and sent by email to each participant. For UCL and other large institutions which already have an institution-wide authentication infrastructure, a better approach would be to plug into the pre-existing authentication infrastructure. To enable this approach in a modular fashion, Helios 2.0 enables a separate, trusted server to submit ballots on behalf of voters. Thus, this trusted server can perform voter authentication however it sees fit, then submit the results of this authentication action to Helios 2.0 at ballot submission time. We use the standard oAuth protocol [19] (in so-called “2-legged mode”) to authenticate a call from the UCL authentication system to the Helios backend server. The use of oAuth effectively sends an HMAC [15] of the request using a shared secret between the two servers (See Figure 1.)

   It occurred to the team that a better long-term design will likely be the separation of the ballot preparation server from the ballot submission server, so that preparing the ballot is independent of the eventual authentication required at submission time. We did not have time to implement this modular architecture for the UCL election, but we intend to do so with Helios 3.0.

   ………

   Substantiation of Complaints Helios 1.0 provided an unauthenticated web bulletin board, which might open the path for unsubtantiated complaints by voters who either did not correctly record their vote receipt, or would like to raise suspicions about the validity of the bulletin board content. Therefore, we decided to provide voters with a document digitally signed by the voting server for each important stage of the election: at registration time, and before the web bulletin board audit phase. These documents would provide each voter a way to prove to the election commission, if it is ever needed, that she actually register for the election, but that this registration was lost by the registration server, or that a vote that was verified during the web bulletin board phase was modified in the tallying phase. While these signed documents allow each voter to substantiate potential complaints, they also allow the election commission to require the voter to provide these documents and to decide accordingly the credit that needs to be given to such complaints. Providing the voters with signed documents raised the question of the verification of these signatures. The verification of signed pdf documents appeared to be the most usable procedure in the UCL IT environment.

   …………

   Use of voter aliases. The registration phase was also used to provide anonymous aliases to the registering voters, which simply were made of the letters “ER” followed by six digits. The purpose of those aliases was twofold:

   1. The UCL election bylaws require the mere fact of voting to be confidential. Even though keeping the voter names secret can be seen as an obstacle to election verification (voters have no way to check whether all the votes printed on the bulletin board correspond to real voters, they can only check their own vote and the global verification is delegated to the election commission), the use of aliases simplifies some privacy issues too: the voting server, which was hosted outside UCL, did not contain any meaningful list of election participants.

   2. Printing aliases on the bulletin board instead of voter names provides a second layer of confidentiality: someone who would eventually manage to decrypt the votes that are published during the election audit (by cryptanalysis for instance) would still not be able to know who people voted for, as this decryption would only reveal who a person with a given alias voted for, the link between the voter and her alias remaining confidential.

   ………….

   3.6 Universal Verification

   All the data needed to audit the election have been made publicly available, together with complete specifications describing the operations needed to audit the election. An independent company wrote a second instance of the audit code (in Python) on behalf of the election commission and successfully verified the election, even though the Python ballot verification procedure showed to be 100 times slower than the C/GMP implementation. The use of two independently produced election tally and verification codes, written in two different programming languages, relying on different arithmetic libraries, provided strong evidence of the correctness of the decryption process.

   ……….

   4.3 Open-audit and the right to complain

   Open-audit election empowers the voter to complain. Often seen as a risk of potential denial of service attacks, it turned out not to be the case. We believe this is due to the two following reasons:

   (i) Complaints can be traced: server logs could be extracted and analyzed;

   (ii) By giving each voter access to signed receipts for any interaction she has with the voting system, we give her the possibility – and therefore the obligation – to present proofs and arguments for her complain. While allowing for legitimate complaints, this largely mitigates the risk of fake complaints.

   Of the few complaints we did receive, the baseless complaints were easily countered by viewing the logs and noticing that the voter’s claims were, in fact, excuses for having missed either the registration or voting period.

   ……….

   4.4 Trustees and Cryptographic Expertise

   We found one particularly difficult issue: the key generation and partial decryption by the trustees. In an ideal world, each trustee would consult their own cryptography expert and develop their own source code for key generation and partial decryption. In fact, it is likely more important for trustees to develop their own key generation code than their own verification code, since verification can be performed many times, while safe key generation and partial decryption must be done right the first time around. Unfortunately, in practice, it is very difficult to expect this much expertise from multiple trustees who are selected to be as independent from each other as possible (and can therefore not be selected from the same or related CS labs). As described earlier, our approach was to distribute the key-generation and decryption code trust among a few members of the election commission. We can imagine other models once the Helios system is further standardized: a long-standing, published open-source key generation and partial decryption package might be available for all trustees to download and install on their own computer systems. Even in this case, however, trustees need notable technical savvy. We believe finding ways to ensure a more direct line of trust for trustees is an important next step in open-audit election operations.
   …….