E-voting at EPFL

Jul 1, 2018  

Contributed by Jeff R. Allen

This spring, for the first time ever, EPFL used a modern electronic voting system to manage the election for the School Assembly. 3900 staff, instructors and students voted using the system over the course of 15 days.

DEDIS created the system using its Cothority blockchain technology, in close collaboration with EPFL’s Vice Presidency for Information Systems under the umbrella of EPFL’s new Center for Digital Trust (C4DT).

Today, we are pleased to share some of the behind-the-scenes information on how it works.

Modern security, and a modern design

Previously, EPFL used an aging online survey system, repurposed to take votes. It was implemented with a typical web application architecture: a form dumped data into a database, and reports were generated after the election.

The new user interface, created using Vuetify, is fresh and modern, and responsive to the capabilities of different devices.

And we didn’t stop at modernizing the UI: the design of the system follows the state-of-the-art in cryptographically verifiable voting systems like Helios. In order to reduce the risks inherent in centralized systems, our system uses the DEDIS blockchain to enhance the transparency of the process of recording, shuffling, and counting encrypted votes.

From theory to practice

The user interface was extensively tested, including a formal round of user testing with both students and staff. Their feedback improved the voting workflow. The voting turnout was a bit higher this year than usual. It is impossible to say for sure, but it seems that the modern, usable design encouraged more people to vote.

The backend was tested using Go unit tests and load tests. During this process, we found and fixed fundamental problems in the system, both the e-voting application, and the underlying Cothority technology.

Applying research code to real-world problems flushes out real-world bugs!

What’s special about electronic voting?

Running an election seems simple, doesn’t it? Get some paper ballots, mark them, put them into a ballot box, and then count them.

Running an electronic election seems simple as well: make electronic ballots, put them in an electronic ballot box and count them, right?

But for voters to have confidence in the outcome of an election, they need to be able to see what’s going on. That’s why in modern democratic elections there are specific protocols for how ballot papers are handled, how ballot boxes are opened, and who is present when they are counted.

If we want voters using an e-voting system to have the same confidence they have in physical voting systems, we need to solve those same problems:

  1. Providing transparency that the votes were recorded and counted correctly
  2. Protecting the privacy and anonymity of the voter
  3. Distribute the responsibility for correctly opening and counting the ballots

Transparency and distributed trust

In a traditional voting system implemented with a simple database in a central server, the first problem we see is that voters send their votes in to the voting system and hope that the right answer comes out. Since the database table is held by the voting system in a “black box”, they have no way to audit the system.

A solution to this is that the voting system can make each transaction it receives public, and do so in a way that proves that the transactions that have already been made public were not falsified later. In this system, non-falsifiable, durable transparent logging is implemented with a Cothority, a cooperative authority of nodes who work together to maintain a skipchain. (Decentralizing authorities into scalable strongest-link cothorities, and How do you know it’s on the blockchain? With a skipchain.)

During the vote, the events added to the skipchain were collectively witnessed by seven servers, each independently operated by seven departments of the university.

Protecting privacy: Shuffling the ballots

Voters need to be identified to the system, so that each voter gets one vote. They can change their vote by voting again, but the system will only count the last one. But if the system (and, as a result of the transparency log, the public) knows the names of the voters, should we also see the votes themselves? No!

Voters encrypt their votes via public key encryption before they send them in to the voting system. But the voting system must be able to unlock the votes later, in order to count them. And once the votes are unlocked, the privacy would be lost if the unlocked ballot was connected to the proof that a certain voter cast it.

What is needed is to separate the votes from who cast them, so that the votes can be unlocked without losing privacy. In this system, privacy is assured using ideas from Andrew Neff, and from the Helios voting system.

Distributing secret key material

No single node can hold the keys for decryption alone, or else that node could violate voter’s privacy or even falsify the votes. A Distributed Key Generation algorithm is used to ensure that each election has a public key to use to encrypt the ballots, but the private key to unlock them later is not available in any one single server.

That’s great, now show me the code!


The target of this voting system was the internal election for the EPFL School Assembly. It is not intended for public-at-large governmental elections. While the verification of the correct operation of the election is decentralised across multiple departments of the university, there are still parts of the system that are single points of failure.

One key failure of the system to uphold the voter’s confidence could be their web browser or mobile phone, which the voter must fully trust as it gathers the user’s input, encrypts the ballot locally, and sends it over the network. The security of the device making the vote is a serious concern, because a compromised browser or smartphone might change the ballot before it is cast. See the CHvote specification for an approach to solving this “cast as intended” problem, which is currently being implemented by the Canton of Geneva.

We are also dependent on the EPFL single-sign-on system to authenticate users and a single pair of web servers that send down the static HTML/JS content.

The design and implementation has not yet received a full independent security audit, and thus is recommended for use only in well-protected organizational network environments for elections that are not expected to be extremely high-stakes.

While not perfect, to our knowledge the e-voting system is robust and usable, and we have far more confidence in it than the system that was previously in use for EPFL’s elections. Addressing the above limitations is part of our ongoing work.

E-voting in Switzerland

The federal government of Switzerland is nearing the end of a long process of learning from academia, civil society and industry what is necessary to safely integrate e-voting into a democratic system. The Federal Chancellery and the legislature have put in place requirements for how to use e-voting in federal elections. Our system meets some of the requirements, and exceeds others (the federal standards do not require decentralisation to the extent that we propose, for example).

Along with the Canton of Geneva, the Swiss Post is also active in e-voting. Their blog explains the issues involved in scaling up e-voting in a democracy like Switzerland.

We support the efforts of Geneva Canton and Swiss Post in their conscientious work to bring open, secure, transparent, and usable e-voting technology to the public at large.

Future work

Our experience with putting decentralised trust technologies to work in the service of real applications has been challenging and educational. We’ve solved tough bugs that only rear their heads when software leaves the safety of the lab and goes out into the real world. We are looking forward to finding partners who are interested in using these technologies to run other elections, and to explore other problem domains that can be approached via decentralised trusted systems.