Anexo técnico · A segurança de sistemas é uma ciência
"Auditamos o código-fonte." Isso não garante o que roda na urna.
A (in)segurança de sistemas é uma ciência estabelecida — com ataques catalogados e defesas comprovadas. Não é questão de fé, nem de suspeita: é engenharia.
"O único sistema verdadeiramente seguro é aquele que está desligado, envolto em um bloco de concreto e selado numa sala forrada de chumbo com guardas armados — e mesmo assim eu tenho minhas dúvidas."Gene Spafford · cientista da computação (Purdue University) — Scientific American, 1989
Ler o código-fonte é necessário — mas não suficiente. Abaixo, dez classes reais de como um sistema pode passar limpo na auditoria e ainda assim contar diferente. O ponto não é acusar: é mostrar que a segurança não pode depender de confiar que o que foi lido é o que executa. Depois, a matemática que fecha a porta: por que conferir uma amostra do papel basta.
NOTA: as técnicas abaixo são categorias conhecidas na ciência de segurança e servem para justificar a verificação por evidência independente. São ilustrativas e genéricas — não descrevem o software real da urna nem afirmam que qualquer fraude ocorreu. O objetivo é fortalecer o sistema, não atacá-lo.
A
Dez formas de passar na auditoria com o código alterado
Cada cartão é interativo. A pergunta em todos é a mesma: um revisor humano, lendo o fonte, perceberia?
Técnica 01 · Opacidade semântica
Candidatos por hash em vez de número legível
Código que faz contagem[13]++ é auditável: o humano sabe que é o candidato 13. Código que faz contagem[«9f2c…e91»]++ esconde a intenção — o revisor não consegue dizer de quem é aquele voto só lendo. Duas hashes de aparência distinta podem apontar para o mesmo candidato.
(Em miúdos: é como contar votos chamando cada candidato por um apelido secreto em vez do nome. O fiscal lê "mais um voto para o apelido X" e não tem como saber a quem o apelido pertence — e dois apelidos diferentes podem, no fim, ser a mesma pessoa.)
O que o auditor lê
funçãocontabilizar(voto):
contagem[voto.id_hash] += 1// qual candidato é esse? impossível saber lendo
?
Três identificadores opacos. Todos parecem candidatos distintos. Nada a objetar.
Identificador no código
Resolve para
9f2c1a7b…4de91
Candidato A
c40b8e2f…7a1d0
Candidato A ⟵ duplicado
a3f7c92e…1f8ac
Candidato B
Dois identificadores diferentes resolvem para A. Parte do que deveria ir para B nunca teve como ser auditada por leitura — a semântica vive fora do código lido.
Técnica 02 · Camuflagem por nome
A lógica mora numa função de nome inócuo
Auditores triam por relevância. Funções com nomes "chatos" de utilidade — sincronização, log, buffer — recebem menos atenção. O desvio se esconde exatamente onde ninguém olha com lupa.
(Em miúdos: é esconder um bilhete comprometedor dentro da gaveta rotulada "guardanapos". Ninguém revista a gaveta dos guardanapos — o nome sem graça é justamente o esconderijo.)
Qual dessas funções você auditaria com atenção redobrada?
sincronizarRelogio()utilidade
validarIntegridade()utilidade
normalizarBuffer()utilidade
registrarLog()utilidade
compactarRDV()utilidade
✗
Estava em normalizarBuffer() — o nome sugere formatação de dados; o corpo redireciona votos. O nome fez o trabalho de esconder.
Técnica 03 · Gatilho dormente
Comporta-se certo no teste, diferente na eleição
O desvio fica atrás de uma condição que só é verdadeira em produção — data da eleição, volume real, ambiente real. No Teste Público de Segurança a condição é falsa, então o código roda impecável. No dia, acorda.
(Em miúdos: é o funcionário que trabalha certinho enquanto o chefe está olhando e só faz a trapaça quando ninguém vê. No teste, impecável; no dia da eleição, muda de comportamento.)
A guarda
se ambiente == PRODUCAOe data == DIA_ELEICAOe volume > LIMIAR:
aplicarDesvio()// dorme sob qualquer condição de testesenão:
registrarNormal()
Guarda avaliada
falsa
Comportamento observado
registro normal
Técnica 04 · Desvio dentro do ruído
Pequeno o bastante para escapar da amostra fixa
A votação paralela testa poucas urnas sorteadas. Um desvio calibrado baixo pode ficar dentro do ruído esperado de uma amostra pequena — e ainda assim, aplicado a milhões de votos, inverter uma eleição apertada. É o ponto exato onde uma amostra de tamanho fixo falha.
(Em miúdos: é o caixa que desvia um centavo de cada cliente. Ninguém sente falta de um centavo — mas, somados milhões de clientes, vira uma fortuna. Pequeno demais para a conferência de poucas urnas notar, grande o bastante para virar uma eleição apertada.)
Detecção por amostra fixa (≈30 urnas, votação paralela)
provavelmente não detectado
Efeito numa eleição apertada (margem 1 pt · 100 mi votos)
inverte o resultado
Uma amostra de tamanho fixo tem um ponto cego fixo. A auditoria de risco limitado não: ela dimensiona a amostra pela margem — quanto mais apertado, mais confere. É disso que trata a Seção B.
Técnica 05 · Trusting Trust
O fonte está limpo. O compilador injeta.
O caso-limite (Ken Thompson, 1984): o código-fonte é genuinamente correto e passa em qualquer auditoria — mas a ferramenta que o compila insere o desvio no binário. Auditar o fonte aqui é fundamentalmente insuficiente, porque o problema não está no fonte.
(Em miúdos: é conferir a receita do bolo — que está impecável — sem saber que o forno foi adulterado para assar outra coisa. Ler a receita nunca revela o problema, porque ele não está na receita.)
O binário gerado não corresponde ao que o fonte descreve — a injeção veio da cadeia de build, não do código. A revisão do fonte não tem como ver: ela lê o texto certo, mas outra coisa executa. Só evidência fora do software (o papel) revela a diferença.
Técnica 06 · Cadeia de suprimentos
O desvio mora numa biblioteca importada, não no seu código
A aplicação auditada apenas importa uma biblioteca "confiável" e a usa. O código malicioso vive dentro dessa dependência de terceiros — que quase nunca é reauditada linha a linha. Casos reais: SolarWinds (2020) e o backdoor no xz/liblzma (2024).
(Em miúdos: você confere o bolo que fez, mas um dos ingredientes já veio adulterado da fábrica. Sua receita está certa — o problema entrou embalado, de fora.)
Código da aplicação (auditado)
importar contagemSegura// biblioteca externa "confiável"contagemSegura.registrar(voto) // o app parece impecável
✗
Dentro de contagemSegura, numa versão publicada meses antes — uma dependência que a auditoria do aplicativo nunca abriu. O código do app estava perfeito; o desvio entrou pela porta dos fundos da cadeia de suprimentos.
Técnica 07 · Abaixo do software
Firmware ou hardware comprometido
O desvio não está em nenhuma linha de código auditável — vive no firmware, num microcontrolador ou num implante físico. A auditoria de código-fonte é cega para essa camada por completo.
(Em miúdos: é fiscalizar o cardápio e a cozinha sem saber que o fogão foi trocado por um que cozinha outra coisa. Nunca se acha o problema lendo a receita.)
Aplicação (código-fonte)auditada ✓
Sistema operacionalauditável
↑ até aqui a auditoria de fonte enxerga
Firmwareponto cego
Hardware / implante físicoponto cego
✗
Abaixo da linha, a auditoria de código não vê nada. O desvio pode morar exatamente ali — e nenhuma revisão de fonte, TPS ou hash do software o alcança.
Técnica 08 · Camada de interface
Voto exibido ≠ voto registrado
A tela confirma o Candidato A ao eleitor; o sistema grava B. Nenhuma lógica de contagem "óbvia" foi mexida — a manipulação está na ponte entre o que o eleitor vê e o que é gravado. Só a conferência do eleitor sobre um registro físico expõe isso.
(Em miúdos: é o caixa que mostra "R$ 10" na telinha e cobra "R$ 100" do seu cartão. Sem o comprovante impresso na mão, você não tem como provar.)
Candidato Aexibido na tela e confirmado
✓
É por isso que o registro precisa ser conferido pelo eleitor no papel: se a tela diz A mas o papel diz B, a divergência aparece. Sem conferência física, o eleitor confia na tela — e a tela mentiu.
Técnica 09 · Camada central
Fraude na totalização ou na transmissão
Todas as urnas podem estar honestas — a manipulação ocorre na agregação nacional ou no caminho da transmissão. Reconferir urna por urna não acusa; foi o total que mudou. O RLA pega porque compara o resultado anunciado com as cédulas físicas, não importa onde o erro entrou.
(Em miúdos: cada seção contou certo e enviou o número certo — mas alguém alterou a planilha final que soma tudo.)
Urnas honestas ✓
→
Totalização + desvio
→
Resultado alterado
✗
O elo comprometido está depois das urnas. As checagens internas urna a urna passam — mas o número que o país vê foi mexido na soma. Só cotejar o total anunciado contra o papel físico (RLA) revela.
Técnica 10 · Meta-nível
As próprias ferramentas de auditoria comprometidas
Se o software que confere o RDV ou conduz a verificação for adulterado, ele carimba "tudo certo" por construção. Auditar com uma ferramenta comprometida é pedir ao réu que assine o próprio atestado de inocência.
(Em miúdos: é escalar como fiscal da prova exatamente quem colou.)
Ferramenta de auditoria: ✓ TUDO CERTO
✗
Então o "tudo certo" não vale nada. O antídoto é a auditoria de risco limitado feita de forma pública e conferível à mão — sorteio por cerimônia aberta, cédulas de papel contadas por pessoas. Uma verificação que não depende de nenhum software, inclusive o de auditoria.
→
O que todas as dez têm em comum
Nenhuma é pega lendo o código-fonte. Todas são pegas comparando o resultado eletrônico com o papel conferido pelo eleitor.
Técnica
Escapa das auditorias internas?
Papel + RLA detecta?
01 Candidatos por hash
provável
sim
02 Nome de função inócuo
possível
sim
03 Gatilho dormente
provável
sim
04 Desvio dentro do ruído
provável
sim
05 Trusting Trust (compilador)
provável
sim
06 Cadeia de suprimentos
provável
sim
07 Firmware / hardware
provável
sim
08 Voto exibido ≠ registrado
possível
sim
09 Totalização / transmissão
provável
sim
10 Ferramentas de auditoria
provável
sim*
A coluna do meio mostra por que "confiem, auditamos o código" não encerra a questão: em quase todas as portas, o desvio tem chance real de escapar das auditorias internas. A coluna da direita é a solução — a mesma resposta ("sim") em todas as linhas, porque o papel + RLA não depende de qual porta foi usada.
* Técnica 10: detectada desde que a própria auditoria (RLA) seja conduzida de forma pública e conferível à mão — independente de qualquer software.
A conta que importa
Muitas portas de entrada, uma única tranca que fecha todas
As dez técnicas não precisam acontecer juntas — basta o atacante escolher uma. E cada porta a mais só aumenta as opções dele, nunca as reduz. Uma ilustração (com números assumidos, não medidos):
P(ao menos uma escapa) = 1 − (1 − p)ⁿ
com p = 20% por porta e n = 10 portas → 1 − 0,8¹⁰ ≈ 89%
Só com auditorias internas
≈ 65–97%
de chance de que alguma manipulação escape — mesmo supondo cada porta improvável (10–30%). O risco cresce com o número de portas e não tem teto.
Com papel conferido + RLA
≤ α (ex.: 5%)
de risco residual — uniforme, não importa qual porta. O RLA compara o resultado anunciado com as cédulas físicas, então o número de portas deixa de importar.
Honestidade metodológicaAs probabilidades por porta são juízos qualitativos, não medições — servem para mostrar a forma do problema, não para cravar um número. O ponto robusto independe do valor exato: somar portas faz o risco interno subir; o papel + RLA o mantém abaixo do limite de risco escolhido, seja qual for o caminho.
B
A conta da auditoria por amostragem
A pergunta natural: "conferir o papel não é recontar tudo, o que anula a urna?" Não. Como um exame de sangue não precisa de todo o sangue, a auditoria confere uma amostra sorteada — e a margem decide o tamanho.
▸ Quantas cédulas preciso conferir?
diferença entre 1º e 2º colocado, em pontos percentuais
chance máxima de a auditoria deixar passar um vencedor errado
600
cédulas a conferir
0,06% do eleitorado
Conferindo 600 cédulas sorteadas do papel, você tem 95% de confiança de que o vencedor anunciado realmente venceu — sem recontar as outras.
·
A lei de escala que muda tudo
Cortar a margem pela metade multiplica a amostra por ≈4. Por isso o goleada custa quase nada e o empate técnico vira recontagem — exatamente onde a recontagem faz sentido. Valores para o α e o eleitorado escolhidos acima:
Cenário
Margem
Cédulas a conferir
Honestidade metodológica
Os números são um modelo simplificado para intuição (amostragem com a escala 1/margem²). Auditorias reais usam testes sequenciais mais refinados — BRAVO/SPRT para amostragem de cédulas, ou comparação de cédulas — que muitas vezes exigem menos conferências para a mesma confiança. A lei de escala e a ordem de grandeza, porém, são fiéis: margem larga → amostra minúscula; margem apertada → recontagem.