If last year, remote voting of citizens was considered more like a curiosity or an experiment, conclusions from which will be drawn sometime later, then in 2020 we all suddenly found out that this is a reality that we will face soon and in full. To a large extent, quarantine restrictions prompted this – the conduct of elections was called into question, and the life of political parties paused.
In general, demand met with the offer – and bills fell. The parties were allowed to carry out primaries through Gosuslugi / ESIA, the regions report one after another about the desire to organize DEG (remote electronic voting) in September at the local elections.
Fortunately or unfortunately, lawmaking alone is not enough – we also need a technical implementation, which is not so simple. Someone believes that everything was already done in Moscow last year (there was even a blockchain there!), Someone – that DEG is generally impossible to implement at a level that does not allow massive falsifications, and therefore it is necessary to abandon DEG in principle.
Therefore, we decided to devote a small series of articles and meetings to the analysis of these issues:
- Alexey Shcherbakov – “Lessons from electronic voting in the Moscow City Duma 2019”
- Oleg Artamonov – “Remote electronic voting: building a trusted system”
- Round table “Press the button: theory and practice of electronic voting”
We’ll start the first article right now, and we’ll hang the second and the announcement of the round table tomorrow (and add links here).
Strictly speaking, this is not an article, but a slightly literary edited text performance of the same name Alexey Shcherbakov (alexeishch) at our conference on March 5 this year.
Alexey is a invited expert of the Roman Yuneman team on the preparation of the report “Electronic voting. Risks and Vulnerabilities», Lead backend developer of FoodPlex.
The report tells how exactly the remote electronic voting was technically arranged in the elections to the MHD 2019, what were the advantages and disadvantages in both technical solutions and working with expert groups.
In addition to this text, you can also read two more articles already published on Habré:
- Analysis of 2019 blockchain voting data in the Moscow City Duma, also by alexeishch
- Parallel audit during Oksana CryptoTyan authorship electronic voting
If you prefer video or audio, full report recording can watch on youtube.
Hello, my name is Alexei Shcherbakov, I was an expert on the invited team of Roman Uneman at the Moscow vote. Well, in general, before talking about the vote itself, it is worth saying how this generally happened.
It all started in March 2019, when the experiment was announced, then in May a law on voting was adopted, and the vote itself took place on September 8 in three districts of Moscow. Voting took place over the Internet for 12 hours.
The system itself was built on the basis of the Ethereum blockchain by Parity. El Gamal’s encryption scheme was also used there. The logging system was used by Graylog and some kind of AMQP implementation was used to transfer data between messages, we assume that most likely it was RabbitMQ, just as an enterprise standard. The system itself looked like this:
Most of the system was outside the Moscow Department of Information Technology (DIT) [[this is a very important point, since only DIT of Moscow communicated with external experts – approx. ed.], but the blockchain was with them. They worked together with the State Service portal. The description of how this system was created was published by the Moscow Institute of Information Technologies on Habré. And they already spoke there in particular that they had problems, basically, only for one hour, about 400 people were affected by this.
We performed data analysis based on the download from the blockchain, which was presented by Medusa. And they separately examined witness testimonies, which were already collected directly by observers at the polling stations. It was an electronic site, where the readings on the screens were photographed, I will tell you more in more detail.
Before speaking about the analysis that was done, I will tell you how we approached the task. If I designed this system myself, I would use certain standards to design a high-availability system. In particular, metrics would be used to monitor directly the health of the system. In order to understand that some problems are beginning – and to respond quickly to them. And besides the team that should do all this, the observers themselves must see it – that is, the observers must somehow understand that something is going wrong. And the precinct election commission, which was located on this precinct, also had to understand what was going wrong if something suddenly goes wrong.
In our case, the time metric for calculating blockchain blocks looked like this. It shows several problems separately, the first problems associated with stopping the blockchain, these are the first three zones. And another zone is an unknown problem that we do not see specifically on this metric. And at the end we see a smooth degradation that occurred until the very end of the vote.
If we consider the second metric – the number of transactions per block – then by them we see the problem in more detail. Firstly, we see that in the shutdown areas, no transactions were recorded. In our suspicious zone, we see very few transactions, and then we see an interesting moment when the nature of the recording of blockchain data changes. What is the reason for this? Initially, when the data was written, they were written at a certain interval, this was done so that it was impossible to determine exactly which person voted by the time of the vote. Data was accumulated and dumped into the blockchain. However, then after some kind of blockchain reconfiguration, the data began to be recorded randomly. That is, some operation was performed, but we can not accurately say on the basis of this metric what exactly DIT did. But we can say that in this case, DIT somehow interfered with the system.
Based on these metrics, we can calculate the time for which the blockchain was stopped. In areas of stable operation, the block time was about 4 seconds. Accordingly, we can calculate in the stop zones how many blocks fit for 4 seconds and how much the remaining block time was stopped. And based on this, we get a lower bound for a stop time of 2 hours. This is the time when the blockchain did not work completely.
In addition, we still have another zone in which the data did not reach the blockchain. In total, all these fault zones take 4 hours. The degradation zone takes about 6 hours, it began after lunch and went on until the end of the vote. Due to the fact that they did not monitor the blockchain in any way, they did not even suspect that there were any problems. Moreover, the people who were present at the polling station itself, part of the election commission, said that all they could do was sit on the sofa and watch what was happening on the screen. That is, they did not understand what was happening, and learned about some problems exclusively from the media. They had no tools at all to observe the problem..
In addition, there was an interesting point: observers had to have access to the blockchain itself. That is, they were promised that they will have a special observation node and they will be able to directly access the blockchain, perform operations on it and watch what happens. But this opportunity was taken away from them! Why? Unclear. And the statistics were simply displayed on the screen.
This is how the screens looked, there are just four positions: the classic “sales funnel”, when we have the number of people who went to the voting page, logged in, received a ballot and voted, and it decreases with every step.
There is a very important point here – the life of the newsletter. If the voter did not have time to fill out the ballot in 15 minutes, then he was considered canceled. And the statistics themselves also went at intervals of 15 minutes. That is, if our voter didn’t go through some section of the funnel in 15 minutes, then we can confidently say that at the next stage of statistics he was not taken into account. And at each stage we got a smaller amount. Thanks to this, it was possible to track interesting anomalies of statistics.
This funnel is shown here, the colors indicate the blockchain malfunction times. There are interesting anomalies here, for example, when the red line crosses over yellow – this number of issued ballots has become more than the number of people who have logged in by entering the code from SMS. It is physically impossible simply, in order to receive a newsletter, you need to enter a code. And this happened in the area of two hours.
This is a comparison of statistics obtained from observers and statistics obtained from unloading from the blockchain. As you can see, they practically coincide, but there is a slight difference when, apparently, there were small problems in the statistics on the front-end. This gives us the opportunity to say that the statistics obtained by independent observers and the statistics obtained from the blockchain based on the upload are almost the same, except for the stage when we had some problems.
In addition to statistics, we have interesting audio recording – the time is about 17 hours, about 2,000 people voted, one of the representatives of the Moscow Information Administration says what interventions they performed on a working system. In particular, he says that about 900 people repeatedly received SMS for authorization.
This tells us, firstly, that thanks to the logging system they used, DIT Moscow could violate the secrecy of the vote. They could compare the voting time, the status of the ballot and the phone number, which is very important! They identified people who had problems, identified their phone numbers and sent out repeated SMS. The number of these people is about 40% of all voters in this polling station. The difference between the two candidates, the first and second, amounted to only 84 people, while for 900 people we can’t even tell what their result was. Because some action was taken on them. We can’t say that these votes were rigged, but we can say that 900 people had problems, we can’t say who they voted for and whether they voted at all. That is, the number of people who encountered problems is ten times more than the number of people who separated one candidate from victory.
Data repository and code used for analysis, can be found at this link.
We also analyzed the code that was used for the vote itself. We expected that most operations would take place directly on the blockchain itself and that the code should be published. We received smart contracts, a form code and a code responsible for sending the message. But there were parts that remained unknown, because they were carried out on the side of another Department – the portal mos.ru already.
What was interestingly found in the code? It turned out that he did not limit the ability of one person to vote in different districts. This is an interesting point, it was at the mercy of the backend, which was located somewhere else and whose source code we could not see. It is not clear why the system used blockchain – since it still did not control everything, it could be replaced with a regular database. Well, the magic code was added to the form code just a day before the vote, which made it possible to include an additional script in the form using one variable on the backend side, which is very interesting! Why did they do this? In fact, this is the ability to execute arbitrary code at the time of voting on the user’s device.
Cryptography was also an interesting point. Initially, they chose 256-bit encryption, although back in 1999 it was proposed to use 768 bits for this scheme, and 10 years ago 1024 bits were offered. And if you now open the recommendations of the European Union, then there will be a requirement of “at least 1024 bits”, but if protection is required before the year 2030, it is recommended to use 3072 bits. There is also an interesting point in how they calculate entropy. It is clear that people have not fully figured out why they need all this.
What can I say about this system?
Firstly, DIT Moscow was not able to provide at least 90% performance. It is generally believed that a high-availability system, it should have at least 90% of the time. That is, we cannot even say that she was working.
Secondly, operations were performed on the production system that no one controlled in any way, no one could understand what was happening. If you look at the court session[[to appeal the election results – approx. ed.], it turns out that neither people, nor observers, nor the commission itself understood what was happening. Still, it was necessary to somehow prepare them for the procedure itself, which was taking place.
Instead of a conclusion
We do not want to say that electronic elections are necessarily a mess, constant problems, strange technical solutions and a misunderstanding of what is happening at the moment.
Nevertheless, as we see from this material, the question of trust in the voting results was essentially a question of trust in its organizers – the interaction with which turned out to be very ambiguous. It seems to us that this answers the very topical question of whether the Moscow Information and Information System has enough experience to scale it to the whole of Moscow, and even more so to the whole country, and to the question of whether it is possible to simply take some kind of “voting ballot” with blockchain ”, launch it on the server and start conducting elections.
About the same, is it possible to build a digital voting system in general, the credibility of which is ensured by its architecture itself, and not by the honesty of its authors – we will talk in the next article.