🇧🇷🗳️ ¿Urna eletrônica ∋ voto 🔒 secreto?

Este post consiste de um resumo do artigo a seguir:

Vulnerabilidades no software da urna eletrônica brasileira – Diego F. Aranha, Marcelo Monte Karam, André de Miranda, Felipe Scarel
Universidade de Brasília – 2013

O artigo detalha as conclusões e experimentos feitos pelo grupo, que participou da 2ª edição de Testes Públicos de Segurança da urna eletrônica, evento organizado pelo TSE em 2012.

Durante o evento, foram detectadas vulnerabilidades no software que permitiram a recuperação em ordem dos votos computados. Apresentamos cenários onde as vulnerabilidades permitem a possibilidade de fraude eleitoral e sugestões para se restaurar a segurançaa dos mecanismos afetados.

Este post sobre o artigo foi feito depois o estudo ter sido mencionado em uma palestra do Diego Aranha na CryptoRave 2014, já publicada aqui; daí que fiquei sabendo da existência da publicação. Busquei assim poder pegar, e dar, mais informações sobre o que foi dito naquela ocasião.

Limitações do estudo

Os experimentos foram feitos apenas em software pois os autores do artigo não são especialistas em hardware; também, foram feitos testes apenas em uma pequena parte do código-fonte da urna (durante 5 horas), e excluindo qualquer sistema externo à urna em si (como o totalizador de votos, que soma os votos das urnas), devido a limitações nas regras do evento (até mesmo a formatação como competição), e na disponibilidade de tempo dos autores do artigo. Essas limitações acabaram por permitir que a equipe que publicou o artigo só pudesse testar a identificação do voto do eleitor, e não a possibilidade do voto dado poder ser fraudado (adulterado), como pretendiam.

Sem a possibilidade de se efetuar testes extensos e sem qualquer tipo de restrição, seguindo metodologia cientı́fica, não é possı́vel afirmar que o formato atual do evento colabora significativamente para o incremento da segurança da urna eletrônica. Permite apenas encontrar vulnerabilidades pontuais que permitam ataques de fácil execução, mas com efeitos limitados.

Seção "Resumo"

Já na seção "resumo" do artigo, apresenta-se aproximadamente isto:

• sigilo fraco do voto: é fácil quebrar o sigilo, ou seja, colocar os votos computados em ordem, permitindo então saber quem votou em quem. Basta ter o resultado público da votação e um acesso mínimo ao código-fonte da urna, aos quais os partidos têm acesso;
• criptografia sem grande utilidade: a chave criptográfica da urna está na própria urna, em uma parte sem criptografia, e a mesma chave criptográfica é usada para TODAS as urnas do país;
• hash obsoleto: o algoritmo que gera o hash criptográfico (SHA-1) não deveria ser usado há 6 anos (ou seja, desde 2006), pois já foi avisado que ele não tem segurança suficiente;
• vulnerável a atacantes internos: o modelo de segurança é focado em ataques externos, mas quem gera mais risco é quem está dentro do esquema de votação;
• processo de desenvolvimento mal-feito: falhas podem ser inseridas, acidentalmente ou propositalmente, devido a práticas inseguras no desenvolvimento;
• auto-verificação de integridade: a urna verifica a si mesma para saber se foi adulterada, sendo que, se foi adulterada, o próprio sistema de verificação estaria comprometido. Era necessário ter verificão externa! De qualquer forma, essa verificação só serve para dar certeza de que o programa veio do TSE, não que os milhões de linhas de código funcionam como deveria.

pode-se observar de antemão que vários dos recursos implementados no software da urna eletrônica não representam mecanismos de segurança, mas apenas de ofuscação, não resistindo a colaboradores internos ou atacantes persistentes. Como vários dos problemas encontrados resultam de falhas arquiteturais ou premissas inadequadas de projeto, é improvável que a intervenção pontual em algumas dessas questões resolva as causas fundamentais para a sua ocorrência.

O sigilo do voto

Os testes feitos pela equipe conseguiram pôr na ordem de votação os 950 votos (vereador e prefeito) de 475 eleitores fictícios usados no teste.

Registrar os votos inseridos pelo eleitor de forma desordenada é um procedimento crı́tico para se proteger o sigilo do voto. Fica claro, portanto, que a metodologia da equipe permitiu derrotar o único mecanismo utilizado pela urna eletrônica para proteger o sigilo do voto.

Esse tipo de vulnerabilidade não deixa rastro ou vestígio ao ser abusada, pois não é preciso abrir a urna eletrônica e adulterá-la, basta usar os produtos públicos da votação... Mas não é dada a identidade dos eleitores diretamente, apenas a ordem do voto. As identidades de quem votou precisariam ser adquiridas externamente, para ser feita a correlação. Numa situação de voto de cabresto, em que um agente coloque as pessoas em uma ordem específica, por exemplo, dá pra verificar quem votou em quem.

O problema parte do Registro Digital de Voto (RDV), uma tabela com colunas para os cargos que armazena os números dos candidatos votados, mas fora da ordem de voto. Em 2002, foi instituída a impressão do voto, para permitir a verificação do voto em relação ao sistema eletrônico, mas em 2003 foi extinguido, e trocado pelo RDV. O RDV existe para permitir verificar que o Boletim de Urna (BU), que entrega o resultado parcial da urna, está certo, mas isso é inútil, pois é o mesmo software que gera tanto o BU quanto o RDV, e por isso a adulteração do programa alteraria ambos os "documentos". Além disso, se implementado errado, permite quebrar o sigilo do voto!

Com a adoção do voto impresso pela Índia, o Brasil permanece como o único paı́s no mundo a adotar sistema de votação sem verificação independente de resultados.

Números aleatórios

Um bom embaralhamento dos resultados, ou seja, um suficientemente aleatório, precisa de rigor criptográfico, e o desenvolvedor precisa de suficiente entendimento de Segurança Computacional para poder perceber isto e fazer certo. O que ocorre é que a urna usa números pseudo-aleatórios, e além disso foi decidido usar o geramento padrão da linguagem C: rand()/srand()! Esse processo de geração não tem qualidade criptográfica, aceita apenas sementes muito curtas, de até 32-bit. Além disso, a semente é simplesmente a combinação hora, minuto e segundo obtida pela função time(), que pega a representação Unix do calendário UTC.

O calendário UTC é um fuso horário que a Era Unix segue, e essa contagem da era é feita em segundos desde o seu começo, representados em um valor de 32-bit (exemplo: 1466404014).

Como o sistema de votação tem que ser ligado entre as 7AM e as 8AM, isso dá 3600s de variação máxima, então 3600 valores diferentes de semente (dia, mês, ano obviamente já são conhecidos por todos, se não, como as pessoas iriam até a urna votar?). Para completar, a semente é publicada no LOG (público para os partidos ao fim da eleição) e na zerésima (imediatamente pública), essa sendo a "comprovação" de que há zero votos na urna no começo da eleição.

Ou seja, qualquer um que pegue a zerésima (pública) saberá a hora, e portanto a semente de geração de números pseudo-aleatórios, e poderá assim determinar a ordem certa dos votos. Tanto o LOG quanto a zerésima são assinados digitalmente, e à mão pelos fiscais, então fica confirmado: 'os números são embaralhados seguindo essa semente!'. O padrão de posições vazias no RDV, mais o total (público) de eleitores que compareceram à votação, permite comparar o resultado da geração de números aleatórios, vendo se coincidem os espaços vazios, ou seja, se foi deduzido certo.

Solução

A forma mais segura para se efetuar a correção é substituir o gerador pseudo-aleatório atualmente utilizado por outro gerador pseudo-aleatório com propriedades estatı́sticas superiores. Exemplos de geradores assim são documentados em padrões e podem ser encontrados em bibliotecas criptográficas de uso geral.

Esse gerador pseudo-aleatório melhorado apenas precisaria de uma semente mais segura, i.e. não algo que está impresso e divulgado em todo lado. Para resultados realmente aleatórios, seria preciso um gerador em hardware, que depende de algum processo físico conhecido. Nada demais também, os modelos de urna fabricados de 2009 em diante já têm uma CPU AMD Geode que faz isto! Note-se que isso não extingue a necessidade de testes para essas soluções também...