Get best of the week

Aulas de votação eletrônica na Duma da cidade de Moscou 2019

Continuamos a falar sobre as atividades do DIT Moscow (veja nossas postagens anteriores ), mas ao mesmo tempo passamos ao próximo tópico, que de repente se tornou relevante e ganhou impulso - o tópico da votação eletrônica.

Se no ano passado, a votação remota de cidadãos foi considerada mais uma curiosidade ou um experimento, cujas conclusões serão tiradas algum tempo depois, em 2020, todos de repente descobrimos que essa é uma realidade que enfrentaremos em breve e na íntegra. Em grande parte, as restrições de quarentena o levaram a isso - a condução das eleições foi posta em causa e a vida dos partidos políticos parou.

Em geral, a demanda atendeu à oferta - e as contas caíram. Os partidos foram autorizados a realizar primárias através de Gosuslugi / ESIA, as regiões relatam uma após a outra sobre o desejo de organizar o DEG (votação eletrônica remota) em setembro nas eleições locais.

Felizmente ou infelizmente, apenas a legislação não é suficiente - também precisamos de uma implementação técnica, o que não é tão simples. Alguém acredita que tudo já foi feito em Moscou no ano passado (havia até uma blockchain lá!), Alguém - que o DEG é geralmente impossível de implementar em um nível que não permita falsificações maciças e, portanto, é necessário abandonar o DEG em princípio.

Portanto, decidimos dedicar uma pequena série de artigos e reuniões à análise desses problemas:

  1. Alexey Scherbakov - “Lições da votação eletrônica na Duma da cidade de Moscou de 2019”
  2. Oleg Artamonov - “ Votação eletrônica remota: arquitetura de um sistema eleitoral confiável ”
  3. Mesa redonda “Pressionar o botão: teoria e prática do voto eletrônico”



Começaremos o primeiro artigo agora e suspenderemos o segundo e o anúncio da mesa redonda amanhã (e adicionaremos links aqui).

A rigor, este não é um artigo, mas um texto literalmente editado do discurso homônimo de Alexei Shcherbakov (alexeishch) em nossa conferência em 5 de março deste ano.

Alexey é um especialista convidado da equipe Roman Yuneman na preparação do relatório “ Votação eletrônica. Riscos e Vulnerabilidades ”, desenvolvedor líder de back-end da FoodPlex.

O relatório informa como exatamente a votação eletrônica remota foi tecnicamente organizada nas eleições para o MHD em 2019, quais foram as vantagens e desvantagens nas soluções técnicas e no trabalho com grupos de especialistas.

Além deste texto, você também pode ler mais dois artigos já publicados no Habré:


Se você preferir vídeo ou áudio, assista ao relatório completo no YouTube .

***


Olá, meu nome é Alexei Shcherbakov, fui especialista na equipe convidada de Roman Uneman na votação em Moscou. Bem, em geral, antes de falar sobre a própria votação, vale a pena dizer como isso geralmente aconteceu.



Tudo começou em março de 2019, quando o experimento foi anunciado, em maio, uma lei sobre votação foi adotada e a votação ocorreu em 8 de setembro em três distritos de Moscou. A votação ocorreu na Internet por 12 horas.

O próprio sistema foi construído com base no blockchain Ethereum da Parity. O esquema de criptografia de El Gamal também foi usado lá. O sistema de registro foi usado pelo Graylog e algum tipo de implementação do AMQP foi usado para transferir dados entre mensagens, presumimos que provavelmente seja o RabbitMQ, apenas como um padrão corporativo. O sistema em si era assim: a



maior parte do sistema ficava fora do Departamento de Tecnologia da Informação de Moscou (DIT) [ esse é um ponto muito importante, pois apenas o DIT Moscow se comunicava com especialistas externos - aprox. ed. ], mas a blockchain estava com eles. Eles trabalharam em conjunto com o portal do Serviço de Estado. Descrição de como este sistema foi criado, DIT de Moscou publicado em Habr. E eles já falaram lá em particular que tinham problemas, basicamente, apenas por uma hora, cerca de 400 pessoas foram afetadas por isso.



Realizamos a análise dos dados com base no download do blockchain, apresentado pela Medusa. E eles examinaram separadamente testemunhos de testemunhas, que já foram coletados diretamente pelos observadores nas mesas de voto. Era um site eletrônico, onde as leituras nas telas foram fotografadas, vou contar mais adiante.



Antes de falar sobre a análise que foi feita, vou contar como abordamos a tarefa. Se eu mesmo projetasse esse sistema, usaria certos padrões para projetar um sistema de alta disponibilidade. Em particular, as métricas seriam usadas para monitorar diretamente a integridade do sistema. Para entender que alguns problemas estão começando - e responder rapidamente a eles. E, além da equipe que deve fazer tudo isso, os próprios observadores devem vê-lo - isto é, os observadores devem, de alguma forma, entender que algo está errado. E a comissão eleitoral da delegacia, localizada nessa delegacia, também precisava entender o que estava acontecendo de errado se algo de repente desse errado.



No nosso caso, a métrica de tempo para calcular os blocos de blockchain era assim. Ele mostra vários problemas separadamente, os primeiros problemas associados à interrupção do blockchain, essas são as três primeiras zonas. E outra zona é um problema desconhecido que não vemos especificamente nessa métrica. E no final, vemos uma degradação suave que ocorreu até o final da votação.



Se considerarmos a segunda métrica - o número de transações por bloco -, então, por elas, vemos o problema com mais detalhes. Primeiramente, vemos que nas áreas de fechamento, nenhuma transação foi registrada. Em nossa zona suspeita, vemos muito poucas transações e, em seguida, vemos um momento interessante em que a natureza da gravação dos dados da blockchain muda. Qual é a razão para isto? Inicialmente, quando os dados foram gravados, eles foram gravados em um determinado intervalo; isso foi feito para que fosse impossível determinar exatamente qual pessoa votou no momento da votação. Os dados foram acumulados e despejados no blockchain. No entanto, depois de algum tipo de reconfiguração da blockchain, os dados começaram a ser registrados aleatoriamente. Ou seja, alguma operação foi executada, mas não podemos dizer com precisão, com base nessa métrica, o que exatamente o DIT fez. Mas podemos dizerque, neste caso, o DIT interferiu de alguma forma no sistema.



Com base nessas métricas, podemos calcular o tempo durante o qual o blockchain foi interrompido. Em áreas de operação estável, o tempo de bloqueio foi de cerca de 4 segundos. Dessa forma, podemos calcular nas zonas de parada quantos blocos cabem por 4 segundos e quanto tempo de bloqueio restante foi interrompido. E com base nisso, obtemos um limite mais baixo por um tempo de parada de 2 horas. Este é o momento em que o blockchain não funcionou completamente .



Além disso, ainda temos outra zona em que os dados não atingiram o blockchain. No total, todas essas zonas de falha levam 4 horas. A zona de degradação leva cerca de 6 horas, começou após o almoço e continuou até o final da votação. Devido ao fato de que eles não monitoraram o blockchain de forma alguma, eles nem suspeitaram que havia algum problema. Além disso, as pessoas presentes na própria assembleia de voto, parte da comissão eleitoral, disseram que tudo o que podiam fazer era sentar no sofá e assistir ao que estava acontecendo na tela. Ou seja, eles não entenderam o que estava acontecendo e aprenderam sobre alguns problemas exclusivamente da mídia. Eles não tinham ferramentas para observar o problema .

Além disso, havia um ponto interessante: os observadores tinham que ter acesso ao próprio blockchain. Ou seja, eles foram prometidos que terão um nó de observação especial e poderão acessar diretamente o blockchain, executar operações nele e observar o que acontece. Mas essa oportunidade foi tirada deles! Por quê? Não está claro. E as estatísticas foram simplesmente exibidas na tela.



É assim que as telas eram, existem apenas quatro posições: o “funil de vendas” clássico, quando temos o número de pessoas que acessaram a página de votação, entraram, receberam uma cédula e votaram, e ela diminui a cada passo.

Há um ponto muito importante aqui - a vida do boletim. Se o eleitor não tiver tempo para preencher a cédula em 15 minutos, ele será considerado cancelado. E as próprias estatísticas também foram feitas em intervalos de 15 minutos. Ou seja, se nosso eleitor não passou por uma seção do funil em 15 minutos, podemos dizer com confiança que, no próximo estágio das estatísticas, ele não foi levado em consideração. E em cada estágio temos uma quantidade menor. Graças a isso, foi possível rastrear anomalias interessantes de estatísticas.



Esse funil é mostrado aqui, as cores indicam os tempos de mau funcionamento do blockchain. Há anomalias interessantes aqui, por exemplo, quando a linha vermelha passa pelo amarelo - esse número de cédulas emitidas se tornou mais do que o número de pessoas que efetuaram login digitando o código do SMS. É fisicamente impossível, simplesmente, para receber um boletim, é necessário inserir um código. E isso aconteceu na área de duas horas.



Esta é uma comparação de estatísticas obtidas de observadores e estatísticas obtidas do descarregamento do blockchain. Como você pode ver, eles praticamente coincidem, mas há uma pequena diferença quando, aparentemente, houve pequenos problemas nas estatísticas no front-end. Isso nos dá a oportunidade de dizer que as estatísticas obtidas por observadores independentes e as estatísticas obtidas do blockchain com base no upload são quase as mesmas, exceto no estágio em que tivemos alguns problemas.

Além das estatísticas, temos uma interessante gravação de áudio - o tempo é de aproximadamente 17 horas, cerca de 2.000 pessoas votaram, um dos representantes da Administração de Informações de Moscou diz quais intervenções foram realizadas em um sistema de trabalho. Em particular, ele diz que cerca de 900 pessoas receberam repetidamente SMS para autorização.



Isso nos diz, em primeiro lugar, que, devido ao sistema de registro que eles usaram, o DIT de Moscou poderia violar o sigilo da votação . Eles poderiam comparar o tempo de votação, o status da votação e o número de telefone, o que é muito importante! Eles identificaram pessoas com problemas, identificaram seus números de telefone e enviaram SMS repetidas. O número dessas pessoas é de cerca de 40% de todos os eleitores nesta assembleia de voto. A diferença entre os dois candidatos, o primeiro e o segundo, era de apenas 84 pessoas, enquanto para 900 pessoas não podemos nem dizer qual foi o resultado. Porque alguma ação foi tomada neles.Não podemos dizer que esses votos foram fraudados, mas podemos dizer que 900 pessoas tiveram problemas, não podemos dizer em quem eles votaram e se votaram. Ou seja, o número de pessoas que encontraram problemas é dez vezes maior que o número de pessoas que separaram um candidato da vitória.

O repositório de dados e o código usado para análise podem ser encontrados neste link .

Também analisamos o código usado para a própria votação. Esperávamos que a maioria das operações ocorresse diretamente no próprio blockchain e que o código fosse publicado. Recebemos contratos inteligentes, um código de formulário e um código responsável pelo envio da mensagem. Mas havia partes que permaneceram desconhecidas, porque foram realizadas ao lado de outro departamento - o portal mos.ru já.



O que foi interessante encontrado no código? Descobriu-se que ele não limitava a capacidade de uma pessoa votar em diferentes distritos. Este é um ponto interessante, estava à mercê do back-end, localizado em outro lugar e cujo código-fonte não pudemos ver.Não está claro por que o sistema usou blockchain - como ainda não controlava tudo, poderia ser substituído por um banco de dados regular . Bem, o código mágico foi adicionado ao código do formulário apenas um dia antes da votação, o que tornou possível incluir um script adicional no formulário usando uma variável no lado de back-end, o que é muito interessante! Por que eles fizeram isso? De fato, essa é a capacidade de executar código arbitrário no momento da votação no dispositivo do usuário .



A criptografia também foi um ponto interessante. Inicialmente, eles escolheram criptografia de 256 bits, embora em 1999 tenha sido proposto o uso de 768 bits para esse esquema, e há 10 anos 1024 bits eram oferecidos.. E se você agora abrir as recomendações da União Europeia, haverá um requisito de "pelo menos 1024 bits", mas se for necessária proteção antes do ano 2030, é recomendável usar 3072 bits. Há também um ponto interessante em como eles calculam a entropia. É claro que as pessoas não entendiam completamente por que precisavam de tudo isso .

O que posso dizer sobre esse sistema?

Em primeiro lugar, o DIT de Moscou não foi capaz de fornecer pelo menos 90% de desempenho . Geralmente, acredita-se que um sistema de alta disponibilidade, ele deve ter pelo menos 90% do tempo. Ou seja, não podemos nem dizer que ela estava trabalhando.

Em segundo lugar, foram realizadas operações no sistema de produção que ninguém controlava de forma alguma, ninguém conseguia entender o que estava acontecendo. Se você olhar para a audiência [apelar dos resultados das eleições - aprox. ed. ], verifica-se que nem as pessoas, nem os observadores, nem a própria comissão entendiam o que estava acontecendo . Ainda assim, era necessário prepará-los de alguma forma para o procedimento em si, que estava ocorrendo.

Em vez de uma conclusão


Não queremos dizer que as eleições eletrônicas são necessariamente uma bagunça, problemas constantes, soluções técnicas estranhas e um mal-entendido do que está acontecendo no momento.

No entanto, como vemos neste material, a questão da confiança nos resultados da votação era essencialmente uma questão de confiança em seus organizadores - a interação com a qual se mostrou muito ambígua. Isso, em nossa opinião, responde à questão muito atual de saber se o Sistema de Informação e Informação de Moscou tem experiência suficiente para escalá-lo para todo o território de Moscou, e mais ainda para todo o país, e para a questão de se é possível simplesmente obter algum tipo de “voto”. com blockchain ", inicie-o no servidor e comece a realizar eleições.

Da mesma forma, é possível construir um sistema de votação digital em geral, cuja credibilidade é garantida por sua própria arquitetura, e não pela honestidade de seus autores - falaremos no próximo artigo.

More articles:


All Articles