← Todos os artigos

E se o software mudar depois de ter sido testado?

O software de votação passou em todos os testes. Depois, alguém entrou num escritório de eleições, copiou todo o sistema para um disco rígido e saiu. O que acontece à "certificação" depois disso?

É a manhã de 7 de janeiro de 2021, e uma equipa de perícia informática está a entrar pela porta da frente do escritório de eleições do Condado de Coffee, Geórgia — deixada entrar por funcionários do condado que tinham todas as chaves. Não são investigadores. Não são auditores. Passam as próximas várias horas a copiar tudo: o servidor do Sistema de Gestão Eleitoral, os dispositivos de marcação de boletins, o scanner de alta velocidade, o software de votação Dominion de toda a Geórgia. O pacote completo. Saem com tudo em discos rígidos.

O sistema que copiaram tinha sido testado. Tinha sido certificado. Tinha executado uma eleição real.

Nada disso impediu o que aconteceu a seguir.

O que a "certificação" realmente certifica

Antes de qualquer sistema de votação tocar num boletim real, passa por um processo de certificação. Um laboratório de testes examina o hardware e o software. Verifica que a máquina faz o que a documentação diz. Emite um relatório. A jurisdição aceita o sistema.

Isto parece rigoroso. E para um momento no tempo, é.

Mas a certificação é uma fotografia, não uma câmara de vigilância. Captura o sistema tal como existia no dia em que o laboratório o examinou. O que acontece a esse sistema entre o laboratório e seu local de votação — e entre eleições — é uma questão completamente diferente, e é largamente não respondida pelo próprio processo de certificação.

O vazio crítico é este: ninguém rotineiramente prova, de uma forma que o público possa verificar independentemente, que o software a correr no Dia da Eleição é o mesmo software que passou no teste.

Este vazio tem um nome. Chamamos-lhe o problema da troca de software antes da eleição. Não é teórico.

Coffee County: quando as chaves vão para as pessoas erradas

O episódio de Coffee County, documentado em deposições no caso federal Curling v. Raffensperger e mais tarde numa acusação do Condado de Fulton, é a demonstração real mais clara de por que o sigilo é uma estratégia de segurança frágil para o software de eleições.

A integridade do sistema repousava, em parte, no pressuposto de que apenas pessoas autorizadas teriam acesso a ele. Esse pressuposto quebrou-se no momento em que um funcionário do condado deixou a equipa de perícia entrar. Várias pessoas ligadas à violação mais tarde pleitearam culpa. O escritório do Secretário de Estado da Geórgia descreveu-o como acesso não autorizado em violação da lei estadual.

Mas eis a questão que persiste após os pedidos de culpa: o que faz com um sistema de eleições cujo software foi copiado e agora está em algum lugar que não controla?

A resposta honesta, sob o modelo de certificação atual, é: não muito. Pode mudar palavras-passe. Pode corrigir os sistemas. Pode afirmar, como fizeram os funcionários, que a violação não afetou a integridade das eleições subsequentes. Mas não pode prová-lo a ninguém que já não esteja inclinado a confiar em si — porque o sistema nunca foi desenhado para ser independentemente verificável em primeiro lugar.

Como documentado no caso Curling, o depoimento de peritos perante o tribunal incluiu conclusões de que um ataque cibernético poderia plausivelmente trocar ou eliminar votos e comprometer o sistema. O tribunal descobriu que o sistema de tabulação baseado em código QR "não fornece um registo de boletim verificável e auditável porque depende do código QR para tabulação de votos e esse código em si não pode ser lido e verificado pelo eleitor." Um documento impresso não é um registo verificável pelo eleitor se o documento codifica o voto real num código de barras que ninguém consegue ler.

A segurança pela opacidade falhou em Coffee County porque a opacidade sempre falha eventualmente. Alguém sempre tem as chaves.

O problema mais profundo: o que acontece entre a certificação e o Dia da Eleição?

Coffee County é a versão dramática de um problema mundano.

Os sistemas de eleições recebem correções, alterações de configuração e atualizações de software ao longo de sua vida operacional. Os fornecedores enviam correções. Os condados aplicam atualizações. Os cartões de memória são reprogramados entre eleições. Esta é manutenção de software normal e razoável — e acontece quase inteiramente fora da vista pública.

A revisão de cima para baixo da Califórnia em 2007, na qual cientistas informáticos da Universidade da Califórnia examinaram o código-fonte de sistemas de votação certificados, encontrou vulnerabilidades graves em todos os sistemas que estudaram — incluindo riscos de software malicioso que poderia propagar-se entre máquinas. A revisão EVEREST do Ohio no mesmo ano, que estudou sistemas certificados de três fornecedores principais, concluiu que todos eles "possuem falhas de segurança críticas" e notou que os registos de auditoria eram comumente falsificáveis ou apagáveis pelas pessoas que deveriam monitorizar. Estes eram sistemas certificados, em uso ativo, examinados por peritos independentes que receberam o código-fonte.

A lição da Califórnia e Ohio é a mesma que a lição de Coffee County: "foi certificado" é o início da questão, não o fim dela.

O Gabinete de Responsabilidade do Governo dos EUA fez essencialmente este ponto em 2005 — num relatório emitido há mais de duas décadas — constatando que os esforços federais para melhorar a segurança dos sistemas de votação estavam em andamento mas "as atividades-chave permaneciam incompletas," incluindo o estabelecimento de repositórios seguros de software e a partilha de informações sobre vulnerabilidades. Alguns desses vazios estreitaram-se desde então. O problema estrutural não.

A experiência de Princeton, e por que ainda importa

Em 2006, os investigadores de Princeton Ariel Feldman, J. Alex Halderman e Edward Felten obtiveram uma verdadeira máquina Diebold AccuVote-TS — do tipo utilizado em todos os Estados Unidos — e tiveram cerca de um minuto com acesso físico a ela. O que construíram foi um vírus que rouba votos que se poderia instalar através do cartão de memória, alterar contagens mantendo todos os registos internos consistentes, e propagar-se de máquina para máquina durante operações normais do dia da eleição.

A máquina foi certificada. O software tinha passado nos testes.

O artigo de Princeton tem agora quase vinte anos, e os sistemas de votação evoluíram. Mas a lição estrutural não: se não conseguir verificar independentemente que o software a correr no Dia da Eleição é o software que inspeccionou, então a inspeção não estabelece muito.

Um sistema certificado-depois-atualizado, certificado-depois-corrigido, ou certificado-depois-copiado não é necessariamente o sistema que o laboratório testou. E sob a maioria dos atuais marcos de certificação, não há mecanismo rotineiro, independente e público para verificar.

Construções reproduzíveis: a solução técnica que muda a questão

Existe um conceito de engenharia de software que aborda isto diretamente. Chama-se uma construção reproduzível.

Eis a ideia em linguagem simples. Quando o software é compilado — quando o código legível por humanos é convertido no binário que realmente corre numa máquina — o processo normalmente produz saída ligeiramente diferente cada vez, dependendo de marcas de tempo, definições do compilador e outras variáveis. Isto significa que mesmo se publicar seu código-fonte, uma parte independente que o compile a si mesma obterá um binário que não corresponde exatamente ao binário a correr na máquina implantada. Não pode verificar, bit a bit, que o código a correr corresponde ao código publicado.

Uma construção reproduzível muda isto. Quando uma construção é reproduzível, qualquer pessoa que tome o código-fonte publicado e siga o processo de construção documentado obtém o exato mesmo binário, byte por byte. Pode depois comparar um hash criptográfico do binário na máquina implantada com o hash do binário compilado independentemente. Se corresponderem, sabe que código está a correr. Se não corresponderem, algo mudou — e pode descobrir o quê.

Isto não é ficção científica. O projeto Debian Linux tem perseguido construções reproduzíveis desde 2013. O Tor Browser as consegue. Bitcoin Core as consegue. Estes são sistemas reais e implantados onde partes independentes podem confirmar que o binário corresponde ao código-fonte publicado.

Para software de votação, construções reproduzíveis significariam isto: após qualquer atualização ou alteração de configuração, a jurisdição publica o hash binário. Qualquer pessoa — um jornalista, um investigador, uma campanha, um grupo de defesa de eleitores — pode compilar independentemente o código-fonte e verificar se o hash corresponde. Se não corresponder, esse é um facto público e falsável.

Isto é o que significa substituir "confie em nós" por "verifique por si mesmo." Não uma auditoria por funcionários a verificarem seus próprios sistemas. Não uma fotografia de certificação. Uma cadeia contínua, independente e publicamente verificável do código-fonte para a máquina a correr. Leia mais sobre este vazio e como fica um verdadeiro reparo.

Por que código aberto é necessário mas não suficiente

O sistema VSAP do Condado de Los Angeles, certificado em 2018 como o primeiro sistema de tabulação de votação de código aberto certificado da Califórnia, é um desenvolvimento genuinamente positivo. A propriedade pública do software de votação e o código de código aberto significam que o processo de contagem pode ser inspeccionado por peritos independentes em vez de ser escondido como segredo comercial do fornecedor.

Mas código aberto resolve apenas a primeira parte do problema: pode qualquer pessoa ver o código-fonte? Não responde por si só à segunda parte: o código na máquina é o mesmo código que está no repositório?

A Suíça descobriu esta fronteira em 2019. A Swiss Post publicou o código-fonte completo do seu sistema de votação pela internet para escrutínio público — um ato notável de transparência. Investigadores independentes Sarah Jamie Lewis, Olivier Pereira e Vanessa Teague leram-no. O que encontraram foi uma porta de trás criptográfica: uma autoridade que conhecia os valores secretos poderia gerar uma prova de permutação que passaria na verificação matemática enquanto na verdade tinha alterado votos. O defeito era invisível numa caixa negra certificada. Tornou-se detectável no momento em que o código foi publicado e criptógrafos independentes olharam.

A publicação permitiu a deteção. Mas a deteção aconteceu porque alguém examinou de perto as provas criptográficas em si — e descobriu que a prova poderia mentir.

A lição: código aberto é um pré-requisito, não uma garantia. Construções reproduzíveis adicionam a segunda camada — provando que o código que leu é o código que correu. E auditorias criptográficas independentes adicionam a terceira — provando que mesmo se o código correu corretamente, seu design não permite manipulação oculta.

Os três são necessários. A maioria dos sistemas de eleições não tem nenhum deles.

O que não consegue verificar agora, e o que o tornaria verificável

Eis o estado das coisas, dito claramente.

Quando uma eleição termina e os funcionários anunciam o resultado, está numa posição de verificar algumas coisas: pode verificar se os totais dos boletins de papel da contagem manual correspondem aos totais da máquina (como a contagem manual de todo o estado da Geórgia em 2020 demonstrou, dentro de cerca de um décimo de por cento). Pode examinar registos de cadeia de custódia para os boletins de papel. Pode observar a contagem.

O que não consegue verificar — na maioria das jurisdições, por qualquer mecanismo atualmente disponível ao público — é se o software que tabulou esses boletins era o software que o laboratório de testes examinou, ou se foi modificado em qualquer ponto entre a certificação e o Dia da Eleição.

Está a confiar numa cadeia que não consegue ver.

O reparo não é misterioso. Requer:

  1. Construções reproduzíveis, para que o binário em cada máquina possa ser verificado independentemente contra o código-fonte publicado.
  2. Valores de hash publicados, assinados e com marca de tempo, sempre que o software ou configuração é atualizado — antes de qualquer eleição que esse software tocará.
  3. Auditorias de compilação independentes, nas quais partes fora do fornecedor e fora da autoridade eleitoral compilam o código a si mesmas e verificam se os hashes correspondem.
  4. Boletins de papel que o eleitor consegue ler, para que qualquer coisa que o software faça ou não faça, existe um artefacto independente — marcado pelo eleitor, legível por um humano, contável à mão — que pode resolver a questão.

Esse último ponto importa mais quando os três primeiros falham. A contagem manual da Geórgia em 2020 confirmou o resultado da máquina dentro de um décimo de por cento precisamente porque boletins de papel existiam que foram marcados por eleitores e legíveis sem software. A preocupação do tribunal Curling com o sistema de código QR da Geórgia era exatamente que o documento impresso codifica o voto tabulado numa forma que ninguém consegue ler sem uma máquina — o que significa uma "contagem manual" desses boletins é na verdade uma re-varredura, confiando novamente na mesma cadeia de software.

O papel não é suficiente se o papel não conseguir ser lido. O software não é suficiente se não conseguir ser verificado. O único sistema que é resiliente contra uma troca de software é aquele onde o registo marcado pelo eleitor, legível por humanos, é tanto o entrada para a contagem como a verificação independente do software que o conta.

Nenhuma garantia do Secretário de Estado muda isto. Nenhuma declaração de imprensa "a auditoria confirmou os resultados" aborda isto. A questão é se alguém fora do sistema consegue verificar independentemente o que correu. Agora, na maioria dos lugares, a resposta é não.

A verdade partilhável

A certificação diz-lhe que o software passou num teste uma vez. Não lhe diz que o software que correu no Dia da Eleição é o software que foi testado. Esse vazio não é uma conspiração — é um problema de engenharia com uma solução conhecida. Jurisdições que constroem para verificabilidade não precisam que confie nelas. Esse é o ponto.

Explore o vazio de troca de software em detalhe | Veja como são comuns os vazios de integridade em todo o mundo | A versão de dois minutos

Fontes

Ver todos os artigosExplorar as lacunas