Segurança da urna eletrônica: Linux, criptografia e auditoria

Uma urna eletrônica não é segura só porque fica desconectada da internet, nem é vulnerável só porque parece um computador antigo. O que importa é a combinação entre hardware, software, procedimentos de auditoria e operação. Esse é o ponto de engenharia que vale observar — e que também se aplica a sistemas críticos que desenvolvemos no dia a dia.

Segundo o Olhar Digital, a urna brasileira completa 30 anos em 2026. A reportagem destaca um sistema operacional customizado baseado em Linux e chips criptográficos dedicados nos periféricos. Esses detalhes ajudam a entender por que o equipamento é bem diferente de um computador de uso geral com um aplicativo de votação instalado.

A urna eletrônica é um sistema, não apenas um equipamento

Quando alguém digita um número na urna, vê uma interface simples: campos, botões e a imagem do candidato. Por trás dela existe um conjunto de componentes que precisam trabalhar juntos: hardware, sistema operacional, aplicação de votação, dados da eleição, mecanismos de segurança, suporte técnico e logística.

Essa visão de ecossistema é importante. Um sistema pode ter código bem protegido e ainda falhar por causa de uma configuração incorreta, de um processo operacional mal executado ou de uma cadeia de atualização comprometida. Segurança não é uma propriedade isolada do software; é o resultado de várias camadas funcionando como planejado.

Por que usar um sistema operacional customizado

Uma distribuição customizada permite controlar quais componentes entram no sistema e como eles são configurados. Em vez de carregar tudo o que um computador de escritório costuma oferecer, a equipe pode reduzir serviços, ferramentas e interfaces que não são necessários para a votação.

Isso diminui a superfície de ataque. Cada serviço ativo, biblioteca instalada ou interface de comunicação pode introduzir riscos e aumentar a quantidade de código que precisa ser mantida. Menos componentes não significa segurança automática, mas facilita revisar, testar e controlar o ambiente.

Para quem desenvolve aplicações, a lição é direta: não leve para produção dependências que o produto não precisa. Um container mínimo, uma imagem de sistema enxuta e uma lista controlada de pacotes não resolvem todos os problemas, mas tornam mais simples entender o que está executando.

O papel dos chips criptográficos nos periféricos

A reportagem descreve chips criptográficos dedicados em cada periférico. Em termos gerais, componentes desse tipo podem apoiar operações como autenticação ou proteção de chaves, dificultando que um periférico adulterado seja tratado como legítimo apenas por estar conectado ao equipamento.

É importante não transformar isso em uma promessa absoluta. Um chip criptográfico não impede qualquer ataque, não corrige uma falha de software e não garante, sozinho, que uma chave nunca será exposta. Ele é uma camada de defesa. O projeto precisa definir como as chaves são provisionadas, como os dispositivos são reconhecidos e como comportamentos inesperados são tratados.

Na prática, esse princípio aparece também em notebooks corporativos, módulos de segurança, tokens e dispositivos IoT. O hardware pode proteger operações sensíveis, mas a aplicação ainda precisa validar respostas, tratar erros e evitar confiar cegamente em qualquer componente conectado.

Segurança por camadas: o que a engenharia precisa resolver

Uma arquitetura de votação precisa responder a perguntas diferentes. O equipamento executa o software autorizado? Os dados da eleição correspondem à configuração aprovada? Os componentes conectados são os esperados? O processo permite detectar alterações? E existe uma forma de verificar resultados sem expor o voto individual?

Essas perguntas não são respondidas por uma única tecnologia. Assinaturas digitais podem ajudar a verificar a origem e a integridade de arquivos. Controles físicos podem restringir acesso ao equipamento. Testes e auditorias podem buscar falhas antes da eleição. Procedimentos operacionais ajudam a garantir que as regras sejam seguidas no local de votação.

Também existe uma diferença importante entre integridade e confidencialidade. Integridade significa detectar alterações não autorizadas. Confidencialidade significa impedir que pessoas não autorizadas leiam dados. Em sistemas de votação, é necessário preservar o sigilo do voto sem abrir mão de mecanismos que permitam verificar o funcionamento e a apuração.

Por que “não estar conectada à internet” não basta

Desconectar um equipamento reduz riscos remotos, mas não elimina todos os caminhos de ataque. Ainda é preciso considerar a cadeia de produção e preparação, o acesso físico, os dispositivos conectados, as atualizações e os erros humanos. Em segurança, “offline” descreve uma condição de rede, não um certificado de invulnerabilidade.

Esse erro de raciocínio aparece com frequência em projetos de software. Um time remove o acesso externo e conclui que o sistema está protegido, mas mantém credenciais compartilhadas, arquivos sem verificação ou permissões excessivas. A superfície de ataque muda; ela não desaparece.

Comparação com outras formas de votação

Uma cédula de papel oferece uma propriedade intuitiva: existe um registro físico que pode ser contado novamente. Em contrapartida, a apuração pode ser mais lenta e também depende de procedimentos, transporte, armazenamento e contagem confiável. Papel não elimina fraude ou erro; muda os riscos e os controles necessários.

Uma votação pela internet seria mais conveniente para algumas pessoas, mas introduziria desafios adicionais: dispositivos pessoais heterogêneos, redes não confiáveis, malware nos computadores dos eleitores, autenticação remota e coerção fora de um ambiente controlado. Um sistema centralizado conectado teria outra superfície de ataque e outras exigências de disponibilidade.

A urna dedicada busca limitar o ambiente de execução e controlar a operação no local. Isso não significa que seja “melhor em tudo” por definição. Significa que cada modelo faz escolhas diferentes entre auditabilidade, privacidade, velocidade, acessibilidade e risco operacional. Comparações sérias precisam avaliar o sistema inteiro, não apenas a tela ou o meio de registro.

Na Prática: verificando a integridade de um artefato

Uma ideia comum em sistemas críticos é comparar o hash de um arquivo com um valor esperado obtido por um canal confiável. O exemplo abaixo não representa o mecanismo interno da urna. Ele demonstra um controle genérico que uma equipe de desenvolvimento pode usar para verificar se um artefato local corresponde ao digest registrado no processo de release.

1. Gere o hash do artefato durante uma etapa confiável do build.
2. Distribua o valor esperado por um canal protegido e separado do arquivo.
3. Calcule o hash no ambiente de destino e compare os valores.
4. Interrompa a instalação se houver divergência; não tente “corrigir” o valor esperado automaticamente.

from hashlib import sha256
from pathlib import Path
import sys

def sha256_file(path: Path) -> str:
    digest = sha256()

    with path.open("rb") as file:
        for chunk in iter(lambda: file.read(1024 * 1024), b""):
            digest.update(chunk)

    return digest.hexdigest()

if len(sys.argv) != 3:
    raise SystemExit("Uso: python verificar.py ARQUIVO SHA256_ESPERADO")

artifact = Path(sys.argv[1])
expected = sys.argv[2].strip().lower()

if not artifact.is_file():
    raise SystemExit(f"Arquivo não encontrado: {artifact}")

actual = sha256_file(artifact)

if actual != expected:
    raise SystemExit("FALHA: o hash do artefato não corresponde ao esperado.")

print("OK: o hash do artefato corresponde ao valor esperado.")

Esse controle tem limites. Se um invasor alterar o arquivo e também o valor esperado, a comparação continuará passando. Por isso, em uma cadeia de distribuição real, o digest precisa estar protegido — por exemplo, associado a uma assinatura digital validada com uma chave pública confiável. Hash verifica igualdade; assinatura ajuda a verificar autoria e integridade do manifesto.

Também vale observar o detalhe de implementação: o código lê o arquivo em blocos, em vez de carregar tudo na memória. É uma prática simples que funciona melhor com artefatos grandes. Em produção, eu ainda adicionaria testes automatizados, tratamento de entradas inválidas e uma política clara para armazenar e rotacionar as chaves usadas na assinatura.

O que desenvolvedores podem aprender com esse projeto

• Reduza a superfície de ataque: mantenha apenas serviços e dependências necessários.
• Separe responsabilidades: autenticação, integridade, autorização e auditoria resolvem problemas diferentes.
• Trate o hardware como parte do sistema: periféricos e interfaces também precisam de controles e validação.
• Planeje a operação: atualização, configuração, suporte e resposta a incidentes fazem parte da arquitetura.
• Não confunda segurança com segredo: sistemas confiáveis precisam de mecanismos de verificação, não apenas de detalhes ocultos.

Na minha experiência com desenvolvimento, uma armadilha recorrente é acreditar que uma tecnologia específica — Linux, criptografia, isolamento ou um chip seguro — resolve o problema inteiro. Ela pode reduzir um risco, mas o sistema ainda depende de decisões de arquitetura, implementação e operação coerentes.

Erros comuns ao avaliar a segurança da urna

• Chamar o equipamento de “computador velho” e concluir que é inseguro: aparência e idade não substituem análise de arquitetura, atualizações e controles.
• Tratar a criptografia como solução universal: criptografia protege determinadas propriedades, mas não corrige bugs nem processos frágeis.
• Supor que estar offline significa estar imune: acesso físico, preparação e cadeia de fornecimento continuam relevantes.
• Confundir uma auditoria com garantia de ausência de falhas: auditorias aumentam a capacidade de encontrar problemas, mas não provam que qualquer sistema complexo é perfeito.
• Avaliar só o código: pessoas, logística e procedimentos também compõem a segurança do sistema.

Segundo o Olhar Digital, a urna é parte de um ecossistema que envolve software, equipamentos e pessoas. A reportagem também ouviu Jéferson Campos Nobre, professor do Instituto de Informática da UFRGS. Essa perspectiva é mais útil do que reduzir a discussão a “confio” ou “não confio”: sistemas críticos devem ser analisados pelas camadas de proteção, pelos processos de verificação e pelos riscos que ainda permanecem.

FAQ: dúvidas técnicas sobre a urna eletrônica

Uma urna baseada em Linux é automaticamente segura?

Não. Linux é uma base tecnológica, não uma garantia. Segurança depende da configuração, dos componentes instalados, do processo de atualização, das permissões e dos controles aplicados ao sistema completo.

Para que servem chips criptográficos em periféricos?

Em termos gerais, eles podem apoiar operações de autenticação e proteção de chaves. O benefício depende de como o sistema os integra e valida. Um chip não elimina falhas no software nem substitui auditorias.

Um sistema de votação offline pode sofrer ataques?

Sim. A ausência de conexão com a internet reduz riscos remotos, mas não elimina riscos ligados a acesso físico, preparação do equipamento, componentes conectados ou erros operacionais.

Hash e assinatura digital são a mesma coisa?

Não. Um hash resume o conteúdo de um arquivo e permite detectar diferenças quando comparado a um valor confiável. Uma assinatura digital usa criptografia para ajudar a verificar a origem e a integridade de uma mensagem ou arquivo assinado.

Gostou? Me segue no GitHub e deixa um comentário se tiver dúvida ou quiser aprofundar algum ponto.