← Todos os artigos

Votação de código aberto: necessidade, não modismo

O software que conta o seu voto é um segredo — e os funcionários que lhe pedem para confiar nele não têm forma de provar que está a fazer aquilo que dizem.

No dia 7 de janeiro de 2021 — na manhã depois do Capitólio ter sido invadido — uma equipa de peritos em informática forense entrou no gabinete de eleições do Condado de Coffee, na Geórgia, e saiu com uma cópia de tudo. O Sistema de Gestão de Eleições. Os dispositivos de marcação de boletins. O software Dominion em toda a região. Tudo, gravado em drives e levado para fora.

O sistema de votação no Condado de Coffee tinha sido tratado como um segredo digno de ser protegido. Esconder o código, proteger as máquinas, confiar nos funcionários. Essa estratégia desabou no momento em que alguém com uma chave decidiu que as regras não se aplicavam a ele.

Sigilo não é segurança. O Condado de Coffee provou-o. Mas existe uma lição mais profunda escondida por debaixo da manchete — e é uma que se aplica quer alguém invada ou não.

O problema com código secreto é que ninguém pode verificá-lo

Quando uma máquina de votação executa software proprietário, as únicas pessoas que podem ler esse código são o fornecedor e, às vezes, uma pequena equipa de testadores aprovados pelo governo que assinam acordos de não divulgação. Você não pode lê-lo. O seu presidente da câmara não pode lê-lo. O Secretário de Estado que o certifica provavelmente não pode lê-lo.

O que toda a gente recebe é uma promessa: testámos, está tudo bem, confiem em nós.

Isso não é um modelo de segurança. Isso é um acordo comercial.

Os investigadores de Princeton que desmontaram uma máquina Diebold AccuVote-TS em 2006 — o mesmo tipo de ecrã tátil implementado em milhões de eleitores americanos — descobriram que o software podia ser subvertido em cerca de um minuto com um cartão de memória. Não apenas adulterado: subvertido de forma a reescrever cada registo e contador para permanecer internamente consistente, deixando sem rasto detetável. O código podia mesmo espalhar-se para outras máquinas durante as transferências normais da noite de eleições. Os investigadores publicaram isso porque tinham a máquina. Podiam ler o software. A maioria das pessoas nunca tem essa oportunidade.

A AccuVote-TS não era um caso isolado. Era uma janela — brevemente aberta — para sistemas que normalmente estão selados.

E aqui está a pergunta incómoda: se foi isso que uma análise independente encontrou numa semana, o que poderá persistir despercebido em sistemas que nunca foram examinados publicamente? Não temos forma de saber. Esse é o problema todo.

"Auditámos" é uma afirmação, não uma conclusão

Os funcionários gostam de dizer que as auditorias pós-eleitorais confirmam os resultados. Às vezes é verdade. Muitas vezes é mais complicado.

No Condado de Antrim, Michigan, em novembro de 2020, foram publicados resultados não-oficiais incorretos. Não marginalmente errados — milhares de votos na coluna errada. O erro foi descoberto, mas não por nenhuma salvaguarda interna. Foi descoberto porque o resultado era absurdamente implausível para um condado que todos sabiam inclinar-se fortemente para o Republicano. Um erro mais subtil, num condado mais competitivo, poderia ter passado despercebido.

Depois, em dezembro, os funcionários realizaram uma contagem manual completa de todos os boletins presidenciais para verificar a contagem de máquinas corrigida. A contagem manual voltou com uma discrepância de doze votos em relação ao total da máquina de aproximadamente 15.700 boletins votados. Doze votos.

Numa eleição desproporcionada, doze votos é um erro de arredondamento. Mas aqui está o problema: numa eleição genuinamente competitiva — decidida por cinquenta votos, ou vinte, ou cinco — uma recontagem manual que em si mesma está desviada por uma dúzia de votos não pode resolver nada. Não pode. Não matematicamente. A auditoria manual de "padrão ouro" tem o seu próprio erro humano irredutível: marcas ambíguas, cansaço às 2 da manhã, decisões de adjudicação contestadas feitas de forma diferente por diferentes pares de mãos.

Quando o Departamento de Estado de Michigan disse que a auditoria "confirmou a precisão", isso foi uma garantia. Não era prova. A discrepância de doze votos não desaparece porque um funcionário chama uma conferência de imprensa.

O argumento real aqui não é que alguém trapaceou. O argumento é que "o Secretário de Estado diz que está tudo bem" e "uma contagem manual confirmou-o" são substitutos para a verificabilidade independente — e substitutos não são a coisa real.

O que código aberto realmente significa para um sistema de votação

As pessoas ouvem "votação de código aberto" e imaginam piratas informáticos a serem convidados a quebrar a eleição. Essa é a imagem errada.

Código aberto significa que o código-fonte do software — cada instrução que a máquina executa — é publicado onde qualquer pessoa pode lê-lo. Investigadores de segurança. Académicos. O seu sobrinho que assistiu a duas aulas de programação. Outros fornecedores. Jornalistas. Grupos de vigilância independentes. Qualquer um.

Isso importa por uma razão que soa quase demasiado simples: não pode esconder uma porta secreta em código que toda a gente pode ler. Ou melhor, pode tentar, mas a probabilidade de detecção desaba à medida que o número de leitores independentes cresce.

A pesquisa moderna de votação criptográfica vai mais longe. O código aberto é a fundação, mas a estrutura construída em cima é o que transforma "pode lê-lo" em "pode prová-lo."

Eis como as peças encaixam:

Código-fonte público significa que qualquer pessoa pode inspecionar o que o software deveria fazer. Esse é o passo um, mas apenas o passo um — porque o código que compila e o código realmente em execução numa máquina podem ser coisas diferentes.

Compilações reproduzíveis fecham essa lacuna. Se o processo de compilação de um sistema de votação for reproduzível, significa que qualquer pessoa que pegue no código-fonte publicado e siga os passos publicados chegará a um binário — o ficheiro executável real da máquina — que é bit a bit idêntico ao binário em máquinas certificadas. Pode verificar o hash. Se corresponder, a máquina está a executar aquilo que diz estar a executar. Se não corresponder, sabe-o imediatamente, sem confiar na palavra de ninguém.

Uma camada de integridade criptográfica vai ainda mais longe. Técnicas como votação verificável ponta-a-ponta (E2E-V) permitem que cada eleitor receba um recibo que lhe permite — e a qualquer outra pessoa — confirmar que o seu boletim foi votado conforme pretendido, registado conforme votado, e contado conforme registado, sem revelar em quem votou. A matemática é pública. A verificação é pública. O resultado não requer confiar em nenhum funcionário, fornecedor ou auditor.

Juntas, estas três camadas movem a pergunta de "confia no fornecedor?" para "consegue verificar a matemática sozinho?"

Essa mudança é tudo.

Por que o Condado de Coffee prova que o sigilo é a estratégia errada

Voltemos ao Condado de Coffee por um momento, porque a lição não é bem a que a maioria da cobertura sugeriu.

A violação foi tratada principalmente como uma história de segurança de custódia: pessoas não autorizadas acederam a um sistema a que não deviam aceder. Verdade. Mas por debaixo dessa história existe um pressuposto estrutural que tornou a violação tão consequente em primeiro lugar.

O modelo de segurança do sistema dependia de o software permanecer secreto.

Se o software tivesse sido de código aberto, "eles conseguiram uma cópia do código" seria significativamente menos alarmante — porque qualquer pessoa já podia ter uma cópia do código. A integridade da eleição não descansaria em manter o código escondido. Descansaria na matemática: compromissos criptográficos, registos de auditoria pública, registos verificáveis que qualquer pessoa podia verificar e ninguém podia alterar silenciosamente.

O que as pessoas que entraram nesse gabinete levaram era proprietário. O seu valor como prémio dependia inteiramente de ser um segredo. Um sistema construído para transparência e prova de adulteração não lhes teria dado quase tanto.

A reconstrução de Lawfare do episódio do Condado de Coffee vale a pena ler na íntegra. O relatório do Atlanta Journal-Constitution acrescenta detalhes adicionais sobre o que foi copiado e como se espalhou. Em conjunto, ilustram um princípio que profissionais de segurança entendem há décadas: sistemas que dependem de obscuridade são frágeis exatamente das formas que mais importam.

O problema das compilações reproduzíveis não é teórico

"Compilações reproduzíveis" soa como um problema de manutenção do desenvolvimento de software. Não é.

Aqui está o problema concreto que resolve. Imagine que um fornecedor de máquinas de votação publica o seu código-fonte. Jornalistas e investigadores lêem-no. Parece bem. O laboratório certificador testa-o. Passa. O Secretário de Estado certifica-o.

Agora imagine que quando o fornecedor compila esse código no binário que realmente funciona nas máquinas, faz uma pequena mudança. Não no código-fonte publicado — no passo de compilação. Uma única instrução diferente. O binário em cada máquina implementada difere do binário que qualquer pessoa auditou, de forma que nenhuma verificação de papel pós-eleição vai detetar, de forma que uma auditoria com limitação de risco não vai detetar, de forma que mesmo uma contagem manual completa não vai detetar a menos que o próprio registo de papel tenha sido comprometido.

Não pode detetar isto sem compilações reproduzíveis. Com elas, pode: compilar o código-fonte você mesmo, comparar o hash, e saber. Instantaneamente. Sem confiar em ninguém.

Este não é um cenário hipotético construído para efeito retórico. O ataque à cadeia de fornecimento contra SolarWinds — que nada tinha a ver com eleições mas tudo a ver com o princípio — mostrou que atores sofisticados podem modificar software no passo de compilação, deixando código-fonte que parece limpo enquanto implementam binários que não são. A mesma superfície de ataque existe em software de votação sempre que compilações não são independentemente reproduzíveis.

Nenhum sistema de votação dos EUA atualmente implementado em escala oferece compilações independentemente reproduzíveis que qualquer membro do público possa verificar. Essa lacuna é real. É mensurável. E não é fechada por nenhum funcionário lhe dizer que o sistema foi testado.

Veja como esta lacuna se compara em jurisdições em todo o mundo →

O que "verificável" realmente significa — e o que ainda não significa

Vale a pena ser preciso aqui, porque "verificável" é usado loosely.

Uma auditoria com limitação de risco, como a que o Colorado iniciou em 2017 ou que a Geórgia implementou em escala estadual em 2020, é uma melhoria genuína sobre verificações de spot de percentagem fixa. Examinar manualmente boletins de papel dá confiança estatística de que a contagem de máquina está correta — se o papel for confiável e se a amostragem for genuinamente aleatória.

Esses são "ses" reais. Mas mesmo uma RLA perfeita apenas verifica que o papel e as máquinas concordaram. Não lhe diz se o software que funcionou essas máquinas era o que pretendia ser. Não verifica o passo de compilação. Não deixa um eleitor confirmar que o seu boletim específico foi incluído e contado. Confirma a contagem contra o papel; não torna o software em si verificável.

Um sistema de código aberto, compilação reproduzível e verificabilidade ponta-a-ponta não substitui auditorias. Dá às auditorias algo sólido em que se apoiar.

A hierarquia fica assim:

  • Software fechado e proprietário: confie no fornecedor inteiramente
  • Apenas código aberto: confie que ninguém inseriu algo malicioso na compilação
  • Código aberto + compilações reproduzíveis: confie que o código publicado e o binário em execução combinam, independentemente confirmável
  • Código aberto + compilações reproduzíveis + verificabilidade E2E: confie na matemática, não nas pessoas

Cada camada remove uma coisa mais que tem de aceitar por fé. O objetivo não é perfeição. O objetivo é tornar a pergunta "isto funcionou corretamente?" respondível por qualquer pessoa com um computador e tempo para verificar — não apenas por funcionários com interesse em dizer sim.

A verdade partilhável

Aqui está a linha que vale a pena fazer screenshot:

"Sempre que um funcionário de eleições diz 'confiem em nós, auditámos', está a pedir-vos que confiem nos auditores. O ponto da votação verificável é que não deveriam ter de confiar."

Os casos neste artigo — o código que não podia ser verificado, os resultados que estavam errados até serem obviamente errados, o software copiado fora de um gabinete de condado numa unidade de disco rígido — não são argumentos de que as eleições são manipuladas. São argumentos de que o modelo atual pede um nível de confiança que a arquitetura não pode justificar.

Registos de papel ajudam. Auditorias ajudam. Mas não são suficientes se o software que gera os resultados for uma caixa preta, se os binários em execução nas máquinas não puderem ser verificados independentemente contra código-fonte público, e se os eleitores não têm forma matemática de confirmar que o seu boletim foi contado.

O que tornaria isto verificável por qualquer pessoa? Três coisas, agora não resolvidas na maioria das jurisdições dos EUA:

  1. Código-fonte público completo para cada sistema de votação — não código-disponível-sob-NDA, mas genuinamente público
  2. Compilações reproduzíveis com hashes publicados que qualquer pessoa possa verificar
  3. Recibos criptográficos ponta-a-ponta para que eleitores individuais possam auditar a inclusão do seu próprio boletim

Até que essas três coisas existam, "a auditoria confirmou-o" é uma afirmação sobre o que os funcionários encontraram quando olharam. Não é uma afirmação que qualquer pessoa fora da sala pode verificar independentemente.

Isso não é uma teoria da conspiração. É um requisito de engenharia.

Leia a versão de 2 minutos destas lacunas → Veja quais sistemas e jurisdições têm lacunas de código secreto hoje → Explore falhas de compilação reproduzível no atlas de lacunas →

Fontes

Ver todos os artigosExplorar as lacunas