Finalmente encontrei tempo para preparr uma sequência que mostra que os mecanismos de transparência do sistema eletrônico de votação ainda não são suficientes para auditoria plena, em resposta à sequência abaixo do @Sylvino20.
Para começar, lacre físico não garante que software é honesto, então não há porque misturar as duas coisas. A sequência demonstra que ainda é preciso confiar incondicionalmente na equipe de desenvolvimento do TSE para se ter eleições justas.
1. Sistema de controle de versão: há pontos do desenvolvimento que não são cobertos, como processo de compilação. Base de código é gigante e desenvolvedores não detectam vulnerabilidades acidentais clássicas, então qual a chance de detectarem falhas propositais?
2. Testes de software por TREs e TRE: testes funcionais não capturam tentativas maliciosas de ataque ao sistema, para isso são necessários testes de segurança (ver 4).
3. Seis meses de abertura do código-fonte: base de código é gigante, com 24 milhões de linhas, impossível de ser auditada. Participantes precisam assinar Termo de Sigilo, o que afasta muita gente. Não impediu vulnerabilidades graves descobertas rapidamente em testes de segurança.
4. Teste Público de Segurança: tem melhorado, mas é cheio de restrições, tempo de poucos dias, escopo que exclui partes importantes (biometria e infra), equipamentos (tem que usar ambiente do TSE), uso de papel, conflito de interesse que gera divulgação imprecisa dos resultados.
5. Cerimônia de Lacração e Assinatura Digital: em 2017, descobrimos módulos do software de votação sem assinatura. Mesmo que assinaturas funcionem, não garantem que software se comporta de maneira honesta durante as eleições, apenas sua origem.
6. Cerimônia de Geração de Mídias, Carga e Lacre das Urnas: foi exatamente a etapa do processo atacada com sucesso em 2017. Adulteração de um único cartão, demonstrada no evento, permitiria infectar até 50 urnas com software malicioso, gerando fator de escala par fraudador.
7. Tabela de correspondência: protege apenas contra clonagem de urnas, não garante que software se comporta de maneira honesta durante as eleições.
8. Cadeia de segurança em hardware: nem todas as urnas possuem o dispositivo (MSD). Mesmo nas que possuem, se houver vulnerabilidade na verificação do software, cadeia de confiança termina interrompida e software malicioso termina executado, conforme observado nos testes de 2017.
9. Processo de fabricação seguro: a contramedida implementada para mitigar o ataque apresentado em 2017 agora depende do conteúdo da BIOS ser confidencial, então tomara que fabricação seja segura mesmo e esse segredo nunca vaze do fabricante.
10. Projeto de hardware e software dedicados à eleição: a urna é um computador como outro qualquer, apenas executando software dedicado. Apesar de não haver conexão de rede, interage indiretamente com dispositivos conectados para instalar software e transmitir resultados.
11-12. Verificação de assinatura dos aplicativos e metadados: havendo vulnerabilidade na verificação, como observado em 2017, termina inócuo. Mesmo que funcione a contento, não garante que software se comporta de maneira honesta durante as eleições, apenas sua origem.
13. Criptografia da biometria do eleitor: identificação biométrica nunca entrou no escopo de testes de segurança, de forma que nenhum especialista independente pode atestar sua segurança e qualidade.
14. Criptografia da imagem do kernel do Linux: as chaves estavam armazenadas na própria mídia do equipamento e puderam ser extraídas por engenharia reserva, conforme demonstrado pela equipe da Polícia Federal. Podem ser vazadas por atacante interno com acesso privilegiado.
15-16. Criptografia do sistema de arquivos e chaves da urna: chaves de encriptação estavam inseridas diretamente no código-fonte e estavam visíveis nos testes de 2017. Podem ser vazadas por atacante interno. Na versão atual, dependem de segredo armazenado na BIOS (ver 9).
17. Criptografia do registro digital do voto: pode ser trivialmente contornada por software malicioso, como demonstrado nos testes de 2017. Módulo de software que implementa o mecanismo era um dos arquivos sem verificação de integridade que descobrimos nos testes de 2017.
18. Derivação de chaves na urna: É perfeitamente possível obter as chaves ao se conhecer o conteúdo da BIOS e função de derivação de chaves, ambos disponíveis para um fraudador interno. Ou simplesmente mandar a urna imprimir na tela, durante processo de desenvolvimento.
19. Embaralhamento dos votos no RDV: já atacado com sucesso nos testes de 2012. Como o RDV não permite recontagem (ver 30) para detectar software malicioso, arquivo termina apenas fragilizando sigilo do voto.
20. Boletim de urna impresso: útil apenas para verificar a transmissão/totalização dos resultados, que graças à publicação do BU eletrônico é a etapa mais transparente do processo eleitoral.
21. Assinatura de software dos arquivos de resultado: se chaves de autenticação de resultados vazarem (ver 15-16), é possível fabricar arquivos falsos que parecem legítimos para o totalizador.
22. Assinatura de hardware dos arquivos de resultado: a alegação de que cada urna possui chave diferente nunca foi demonstrada. Várias chaves de autenticação observadas em 2017 eram compartilhadas por múltiplas urnas. Além disso, nem todas as urnas possuem MSD.
23. Criptografia do boletim de urna: irrelevante, pois se trata de documento público. É importante apenas autenticar a versão eletrônica do Boletim de Urna, que espero esteja implementada corretamente, pois nunca testamos.
24. QR Code no boletim de urna: útil apenas para verificar a transmissão/totalização dos resultados, etapa mais transparente do processo eleitoral eletrônico. A bronca aqui é com o software de votação.
25. Código verificador do boletim de urna: implementado após pesquisador mostrar como usar o Sistema de Apuração para desviar votos nos Testes Públicos de Segurança em 2016.
26. Votação paralela: há formas simples para software saber se está na votação real ou simulada, como monitorar a biometria ou ativar comportamento malicioso apenas após um certo voto nulo ser registrado, algo que ainda poderia ser explorado em escala com eleitores coagidos.
27-28. Conferência de hash e assinatura digital: hashes e assinaturas são apresentados e verificados pelo próprio software no ambiente de urna, que já pode estar comprometido. Se modificado, pode fixar valores antigos e imprimi-los para fazer parecer que não houve alteração.
29. Log da urna: conforme demonstrado nos testes, pode ser adulterado por software malicioso para esconder registros de eventos específicos. Módulo de software que implementa o mecanismo era um dos arquivos sem verificação de integridade que descobrimos nos testes de 2017.
30. Entrega do RDV (Registro digital do voto): arquivo é produzido pelo mesmo software que conta votos, que obviamente produzirá registros compatíveis se funcionar de maneira maliciosa. Não permite recontagem nesse cenário, portanto (ver 17 e 19).
Isso tudo aí quer dizer que vai ter fraude? Claro que não, até porque os problemas *conhecidos* foram corrigidos e/ou mitigados, mas que o país precisa ter uma conversa adulta e informada por evidências técnico-científicas a respeito do tema, muito além da propaganda oficial.
Detalhes técnicos dos resultados dos testes de 2017 podem ser encontrados em urnaeletronica.info, onde também manifestamos nossas posições a respeito do tema.
