Expert column by Kirill Polyakov, Head of Distributed Registry Technology department at the IT Department of Moscow Government.

For the first time, remote electronic voting was conducted as an experiment during the elections of deputies to the Moscow City Duma on September 8, 2019 in three voting districts. The solution was created from scratch and tested by the IT Department of Moscow Government in less than one year. Most of the key participants and customers claim that the experience was successful, the system passed all the tests and proved its resistance to hacking. Thus, the experiment confirmed that the system can be used for other votes. You can read more about that experience on Habr.

Back then in 2019 a technical working group was created, and it continued to work on the subsequent projects (anyone can become part of the group, details will be further elaborated in the article). The group made critical comments and also motivated the developers to continuously improve the project. At the same time, we received a lot of useful feedback, including the comments from the international expert on cryptography and election law Pierrick Gaudry. We realized the importance of internal audit with the involvement of the best teams for reviewing the system - including the search for vulnerabilities, developing a threat model, analyzing the code and functionality. As a result, the  IT Department of Moscow Government became the first representative of the public sector in the world to present the open source code of the solution, particularly the back-end and key modules.

The main thing about that e-voting was that it was conducted as an experiment. We needed to understand whether such a solution was feasible. Therefore, the particular chosen technical solution was not the focus; it was the project itself that was important - how it would be perceived and how the system would work during the test voting.

The most useful thing during the first launch of an IT system is open testing. We conducted four of them. During the testing, we worked out various risks from the threat model: blackouts, Internet outages, DDoS attacks, etc. This experience was used in the next votings.

Differences in 2020

On June 25-July 1, 2020, the nationwide voting on amendments to the Constitution of the Russian Federation was held. In Moscow and in the Nizhniy Novgorod Region it was organized also in a remote electronic format using the blockchain  technology (which was especially important during the pandemic).

Having considered the available input data, we anticipated a load of 1 million voters. It was clear that Ethereum blockchain platform previously used in the electronic voting system would simply not be able to handle the load. We started to look for other options and chose Exonum, one of the fastest blockchains. It was also important for us that it was geared to solve problems as a private blockchain.

Another new challenge in 2020 was to provide an “everlasting” election ballot. It is a ballot with an unlimited validity throughout the entire voting period that will not disappear if the computer of the voter freezes, communication failure occurs, etc. The “everlasting” ballot was available on the same device in the same browser in which it was first opened, provided that the link to it was saved.

In addition to Moscow, the Nizhniy Novgorod Region participated in the e-voting on amendments to the Constitution of the Russian Federation, so we provided voters with the opportunity to log in not only via mos.ru (the official portal of Moscow Mayor and Moscow Government), but also via gosuslugi.ru federal portal (public services portal of the Russian Federation). Attempts to log in in both systems were automatically blocked (only the first application for participation was taken into account). We also took into account the critical comments concerning cryptography in the 2019 voting and implemented a more modern solution based on the Curve25519 elliptic curve, which is used as the default key exchange in OpenSSH, I2p, Tor, Tox and even IOS.

Another challenge was the growing load on all systems of the government of Moscow due to the self-isolation regime: residents started to actively use electronic services and the load on the channels increased significantly.

Architecture of the system

In order to increase the resiliency of the remote voting system we implemented a distributed architecture by using geographically dispersed data centers. This ensured fault tolerance - the system can continue to work even if there is a power outage in an entire district in ​​Moscow. We tested such a scenario before conducting the voting - we disabled one of the data centers and checked the stability of the operation of individual components and the whole system. We also used satellite platforms to fulfill the load requirements.

The blockchain was distributed into two nodes for each data center - six nodes in three data centers in total, plus an observer node (details outlined further). The system is peer-to-peer, so working in the mode when one data center is the master, and the second is backup is impossible.

The situation that occurred at the end of 2017 confirmed that Ethereum blockchain network cannot handle the high load. Then the transactions were not confirmed for several days, and sometimes they simply were not completed. It should be mentioned that at that time neither the high-tier application, which caused the excessive load, nor the main network was working, although the application accounted for only 10% of the total number of transactions. Obviously, such a point of failure is not suitable for the voting process, since it is strictly regulated by the timeline and transactions cannot be delayed even for a few minutes, let alone hours.

Bitcoin network has a throughput of about 10 transactions per second, so it is also not suitable. With such a load, only 860 thousand people can vote in a 24 hours period, provided that no other transactions are processed at that time, which is impossible. We understood that the only possible way was to use a private network that allows connecting external observers.

The observer node was implemented in such a way that it is possible to monitor the results in real time. The node was presented as a web interface that allows to view and download encrypted results in real time. The next step is to implement a full-fledged node, but it is necessary to foresee the risk of impacting the network through the observer node. The main advantage of electronic voting is the ease of monitoring the processes. But it is also important to find a balance between transparency and vulnerability. Therefore, our next step is anchoring to a public network (a mechanism for checking data from a private blockchain for immutability by publishing it to a bigger network with a large number of participants and blocks).

In the future the electronic voting system will be available on mobile devices - we will try to enable synchronization with the node, provide processor power to  ensure control and arrange an additional channel for calculating the result. The plans also include the development of the web interface’s functionality. We anticipate the development of greater opportunities for collaboration and verifying of the result at the observer level.

Special features of the electronic ballot

The most secure component of the remote electronic voting system was the ballot. Participation in the remote electronic voting was confirmed by entering SMS verification code and getting access to the electronic ballot.We envisaged a set of measures in case something goes wrong for the user. For example, the received link to the ballot could be opened in the same browser and on the same device at any time before the end of the electronic voting (20:00 on June 30th), provided that the device was not turned off, restarted, and that its memory was not cleared. If the Internet connection is lost or the device experienced any other disruptions in operation, the user just had to refresh the page with the ballot after the Internet connection was restored - this returned the ballot one step back to the “preview” mode and allowed to continue voting.

The “vote” button appeared immediately after choosing an answer option in the ballot. After pressing the button, the ballot was encrypted on the voter’s device and sent to the blockchain. If the Internet connection was interrupted at the time of sending, the encrypted ballot was sent immediately after the connection was restored.

Anonymization and mixing

When designing the system, two fundamental mechanisms - anonymizer and mixer - were implemented to preserve the secrecy of the vote and the anonymity of the voter.

The anonymizer made it impossible to track or identify the user, since the page is not connected with the identification data about the user and does not contain any artifacts and information about the person.

And the mixer put voices into groups and randomly mixed the votes before sending them to the blockchain. This excluded the possibility of comparing the cast votes by the time they was received.

Non-obvious requirements

Our remote electronic voting system had several functions and elements which seem strange and unnecessary at first glance, however, they are required by current legislation. A striking example is the transmission of voting results to the state automated system “Vybory” (“Elections”). This process was not automated on purpose and was carried out manually by an operator from the Moscow City Election Commission on a special secure computer in the premises of the Territorial Election Commission for Remote Electronic Voting.

Another example is the use of the so-called blockchain printers, which “left a  paper trace” online - they printed encrypted key transactions online: providing access to the ballot, recording encrypted voice in the blockchain. These printers make it possible to count ballots manually if requested. It is also one of the mandatory requirements.

Testing of the system

To check the fault tolerance of the system, we conducted load tests (a set of measures to check all network components using the load that is close to or exceeding the expected one) every day until the day of the voting. The public test of the system (a real voting for Moscow residents and the residents of the Nizhniy Novgorod Region) was carried out for two days in order to practice emergency scenarios. In the meantime, the applications for the main voting were already being accepted, and this process did not stop even during the test voting period.

As in 2019, we announced a 2 million rubles prize (equivalent to $26.4 thousand) for hacking the system (during the testing, not on the voting days). But nobody managed to do it again.

Voting and interpretation of results

Then the remote electronic online voting was completed on June 30 at 20:00 Moscow time, the data on voters who registered for electronic voting, but did not vote in electronic form, were transferred to the “Vybory” state automated system. They were added to the voter lists at district election committees at their place of registration, and were provided with an opportunity to vote offline on voting day, July 1. All this time, before the decryption started, the system had been closed for accepting ballots, but all monitoring tools were operating, so it was possible to make sure that there were no manipulations, and the blockchain generated zero transaction blocks.

Participation of experts

From our experience in 2019 we knew that such projects require the involvement of a lot of industry professionals. Positive Technologies and Kaspersky Lab, as one of the most competent and influential players in the Russian information security market, were engaged to audit the system.

The technical working group included critical IT professionals, with the new members who became part of the group in 2020. For example, representatives of the Party Of Direct Democracy, which is a competitor, since its agenda includes the development of its own electronic voting. However, this is the case when joint participation in such projects strengthens and enriches each of the parties.

Due to the pandemic, almost all meetings were held online, and the broadcast of the meetings was recorded. To ensure quick communication between the members of the technical working group, a Telegram chat was created. It includes representatives of the IT Department of  Moscow Government from different areas who answer questions. By the way, they are still doing it, even after the project is completed, and the chat is constantly active.

As for Pierrick Gaudry, who in 2019 provided valuable comments regarding the mechanism for encrypting votes and the operation of the system, this time he refused to participate in the audit of the system due to the lack of documentation for the system in English.

The decryption of the votes was launched after the end of the voting (after 20:00 Moscow time, July 1). It took about 10 minutes. The results of electronic voting in two constituent entities of the Russian Federation - Moscow and the Nizhniy Novgorod Region - were publicly presented upon completion of the decryption, and were also transferred to the “Vybory” state automated system for summing up the voting results in the country.

The work will be continued

Habr can become a platform for working out the organizational and technical aspects of the project, and if you have questions about the code and suggestions for improving the system, we suggest using GitHub.

To become part of the technical working group, please send us your full name and contact information by e-mail (support-vybory@mos.ru), and also briefly describe your competencies and why you are interested in joining the group.

Other blockchain-related materials on ICT.Moscow:

News on blockchain on ICT.Moscow

Column on the main trends in blockchain in 2020

Blockchain cards on ICT.Moscow