Analise de Um Sistema Eleitoral Eletrônico

14/05/2021 analise de um sistema eleitoral eletrônico
http://www.cic.unb.br/~rezende/sd.htm > Urna eletrônica: Avaliação
Análise de um sistema eleitoral eletrônico

In memoriam: Leonel de Moura Brizola
Publicado no Observatório da Imprensa em 7/09/04
Prof. Pedro Antonio Dourado de Rezende

Departamento de Ciência da Computação
Universidade de Brasília
22 de Agosto de 2004
Resumo
Em 2003, quatro professores da Johns Hopkins University e da Rice University

publicaram uma análise sobre a segurança do código supostamente utilizado em
um sistema eleitoral eletrônico fornecido pela empresa americana Diebold. Tal
estudo apontou inúmeras falhas e vulnerabilidades a fraudes de origem interna e
externa. Novas denúncias de falhas de segurança nas máquinas de votação da
Diebold foram apresentadas em março de 2004, o que levou ao descredenciamento,
dois meses depois, das máquinas da empresa no Estado da Califórnia.
O presente trabalho, desenvolvido com a ajuda de voluntários, tem por objetivo

oferecer uma análise semelhante, de algo semelhante. Código que, segundo tudo
indica, origina-se da urna eletrônica do sistema eleitoral brasileiro usada em 2000,
e que teria sido desenvolvido pela mesma empresa. As conclusões aqui são também
semelhantes, tão graves quanto aquelas.
Índice
1. Introdução
1.1 Oportunidade
1.2 Apresentação
2. Sobre autenticidade
2,1 Propósito deste trabalho

2.2 Origem do material em análise
2.3 Plausibilidade e verificabilidade
3. Descrição do sistema
3.1 Arquitetura geral

3.2 Arquitetura básica das urnas eletrônicas
3.3 Arquitetura de segurança das urnas eletrônicas
3.4 Garantias invertidas
4. Análise da segurança
4.1 Autoverificação e assinaturas

4.2 Controle dos mecanismos de proteção
https://cic.unb.br/~rezende/trabs/analise_setup.html 1/22
4.3 Modelos de confiança para a arquitetura de segurança

4.4 Calcanhar de Aquiles
5. Conseqüências para eleições seguintes
5.1 Arroubos e frouxidões

5.2 It's not a bug, it's a feature!
5.3 Fiscalização e opinião pública
6. Conclusões
6.1 A questão política

6.2 Homenagem póstuma
Referências bibliográficas
1. Introdução
A primeira eleição nacional 100% informatizada de todo mundo ocorreu no Brasil em 2000.
Neste evento, o fornecimento das urnas eletrônicas e do software que as fazem funcionar coube
à empresa Procomp, subsidiária da empresa americana Diebold, que também fornece urnas
eletrônicas para as eleições norte-americanas.
Em 2003, quatro professores da Johns Hopkins University e da Rice University publicaram uma
análise sobre a segurança do sistema eleitoral eletrônico, equivalente às nossas urnas eletrônicas,
fornecido pela empresa americana Diebold, em relação ao risco de fraudes [1] A análise foi
desenvolvida sobre um software obtido na Internet, publicado anonimamente, e os autores
concluíram pela existência de inúmeras falhas de segurança neste sistema que, se exploradas nos
momentos oportunos, poderiam alterar o resultado eleitoral. Ao tentar impedir judicialmente a
divulgação da análise, a empresa poderia estar implicitamente admitindo a autenticidade do
material analisado pelos professores da John Hopkins e Rice.
Em março de 2004, durante as eleições primarias norte-americanas, problemas em máquinas

eletrônicas de votação voltaram a ocorrer e, após estudo publicado em abril, o Secretário de
Estado da Califórnia, Kevin Shelley, considerando também estudos técnicos feitos pelos Estados
de Mariland e Ohio, decidiu descredenciar o uso das máquinas da Diebold na Califórnia para as
próximas eleições de 2004 [2]. Segundo notícia publicada no New York Times [3], em 1 de maio
de 2004, entre os motivos alegados para o descredenciamento figurava o fato da Diebold ter
trocado parte dos programas do sistema por software não pré-qualificado e de ter mentido aos
Oficiais de Estado tentando esconder os problemas durante sua avaliação.
Esta decisão do Secretário de Estado da Califórnia surpreende a muitos brasileiros, já que, entre
nós, parece comum um alto grau de confiança no sistema eleitoral informatizado aqui em uso,
através do qual somos obrigados a votar. Uma das revelações desta decisão, todavia, é que a
confiança do público brasileiro nas eleições eletrônicas aqui já conduzidas baseia-se mais no
fascínio pela modernidade, explorado pela propaganda dos fornecedores e operadores do
sistema, do que em procedimentos e dados técnicos objetivos. Isto ficou evidente, quando
menos, pela forma atabalhoada e canhestra com que foi votada a mais recente lei federal
destinada a regulamentar o processo eleitoral brasileiro, registrada no artigo “A Seita do Santo
Byte ” [4] e em análise do Fórum do Voto Eletrônico [16].
1.1 Oportunidade
Em fevereiro de 2004 surge uma novidade. Alguém publica na Internet uma parte do software
que, ao que tudo indica, teria sido desenvolvido pela Diebold/Procomp para as eleições de 2000
no Brasil. Este fato criou uma oportunidade única para se estudar o sistema eleitoral brasileiro,
especialmente em vista do precedente nos EUA, para verificar se nele também ocorrem
problemas semelhantes aos lá apontados.
Esta oportunidade é única e valiosa pois a Justiça Eleitoral brasileira escolheu, a nosso ver
equivocadamente, um método de desenvolvimento e validação do seu sistema com modelo de
confiança para seu sistema de segurança baseado no obscurantismo, aparentando transparência
apenas na superfície. Ademais de tê-lo desenvolvido com excessiva e precária dependência a
pessoas que hora ocupam cargos de confiança na Secretaria de Informática do TSE, ao invés de
a processos institucionais. A suposta transparência do sistema atual é crível apenas por leigos,
tendo em vista:
O termo de compromisso de sigilo, absoluto e irrevogável, que fiscais de partido têm sido
obrigados a assinar para poderem ver código-fonte de parte do software do sistema, em
ambiente totalmente controlado pelo fiscalizado, o Tribunal Superior Eleitoral, a título de
fiscalização e/ou auditoria do processo eleitoral.
A natureza dos estudos e análises técnicas independentes que até o momento foram
oficialmente permitidos sobre o sistema. (seguindo a norma de segurança da International
Standard Organization -- ISO -- denominada "Common Criteria", o PT solicitou ao TSE,
em agosto de 2000, permissão para a realização de teste de penetração no sistema, que foi
negada sem explicações)
Com esta novidade pudemos desenvolver o presente trabalho.
1.2 Apresentação
Trata-se de uma análise técnica de parte essencial de um sistema eleitoral informatizado, que
tudo indica ser o brasileiro de 2000, em relação ao risco de fraudes. Começamos analisando, no
capítulo 2, a plausibilidade< de ser autêntica a origem desse novo material. No capítulo 3,
fazemos um esboço da arquitetura do sistema de segurança das urnas eletrônicas brasileiras, que
emerge das descrições oficiais em documentos publicados pelo TSE e em artigos técnicos
apresentados em congressos acadêmicos de computação.
No capítulo 4 a análise propriamente dita, sobre a segurança das urnas em relação à

possibilidade de fraudes, baseada na descrição do sistema, no estudo do código-fonte extraído do
referido material e em pontos de contato entre ambos. O estudo busca mapear consistências e
inconsistências, em termos de princípios gerais da segurança contra fraudes em sistemas
informáticos com modelo de confiança tecnicamente adequado. A saber, no caso, onde se
modela mais de dois potenciais conflitos de interesse: os de dois ou mais partidos, em vencer
pleitos, e o do executor e juiz dos pleitos, para que nenhum deles fraude. O trabalho se encerra
com observações, no capítulo 5, sobre a aplicabilidade desta análise a versões posteriores do
sistema eleitoral brasileiro, e com a apresentação, no capítulo 6, das conclusões e homenagens.
2. Sobre autenticidade
No dia 28 de fevereiro de 2004, mensagens quase simultâneas foram divulgadas em duas listas
de debate sobre voto eletrônico na Internet, anunciando a novidade. A saber, na lista
internacional UPA-EVOTING <http://groups.yahoo.com/group/upa-evoting/> e na lista
brasileira FÓRUM do VOTO-E <http://www.votoseguro.org/forum.htm>, informando que o
código de programa do SETUP.BAT [5], utilizado nas urnas eletrônicas brasileiras de 2000, e
que o relatório da Fundação COPPETEC [6], de avaliação da documentação do software do
sistema eleitoral brasileiro de 2002, estavam disponíveis no endereço
<http://www.angelfire.com/journal2/tatawilson>.
As mensagens tinham como origem aparente (endereço IP) a cidade de Amsterdã, na Holanda,
mas seu autor não se identificava, afirmando apenas ser ex-funcionário da Justiça Eleitoral no
Brasil. A anonímia do publicante levanta, naturalmente, a questão sobre a autenticidade da
alegada origem dos documentos assim disponibilizados. Como o presente trabalho se

desenvolveu com base em material colhido nesse endereço, é necessário avaliar a plausibilidade
de sua alegada origem, de forma a se evitarem os riscos de uma análise incorreta, conclusões
inaplicáveis ou alegações irresponsáveis.
Esta seção busca antes, e especificamente, afastar toda e qualquer possibilidade de que o
propósito da divulgação do presente trabalho possa ser interpretado, em leitura racional e
honesta, para além ou para fora daquele que moveu o autor.
2.1 Propósito deste trabalho
O propósito deste trabalho se constitui, por um lado, em tributo póstumo a um insuperável

exemplo de brasilidade, e por outro, no estrito exercício dos concomitantes deveres de cidadão
especialista, de acadêmico do ensino superior público na especialidade segurança
computacional, e de representante da sociedade civil no Comitê Gestor da ICP-Brasil, incidentes
sobre o autor, para bem fornir seus concidadãos com informações técnicas necessárias à
formação de juízo sadio sobre o grau de confiabilidade que o uso de um tal sistema inspira, na
ausência de salvaguardas fiscalizatórias em grau demandado por leitura direta e insofismada da
Lei 9.504/01.
Ressalte-se, ainda, que, sustentada a hipótese de originalidade do material analisado, em nenhum

sentido possível o presente trabalho faz dele o uso para qual teria sido criado, qual seja, o de
controlar máquinas eleitorais, oficiais ou não.
O exemplar de SETUP.BAT publicado na internet é um longo arquivo em forma de texto pleno,

codificado em padrão ASCII (txt), com aproximadamente 167 Kbytes de tamanho, constituído
de aproximadamente 6.200 linhas de código e comentários. Contém programação de
computador profusamente explicada e comentada (código-fonte), cuja estrutura interna de
desvios e atalhos é complexa, envolvendo um emaranhado de opções distintas para aplicações e
usos diversos, tais como: modo de votação real, modo simulado, modo de reserva, treinamento
de eleitores, treinamento de mesários, justificativas eleitorais, sistema de voto-cantado (para
apuração do voto manual), manutenção e outras. Constitui, portanto, farto material de análise.
2.2 Origem do material em análise
Apesar da complexidade, a lógica de transição entre suas diversas partes internas é coesa, não
ocorrendo casos de desvios sem destino útil, ou de trechos com desenvolvimento incompleto, o
que revela um longo trabalho de desenvolvimento e depuração. O código-fonte é rico em
comentários que fazem referência a processos, componentes, equipamentos e periféricos todos
compatíveis e coerentes com os nomeados nas especificações oficiais para as Urnas-E 2000,
conforme distribuídas em Edital de Licitação mediante Concorrência nº 27/99 do TSE [7],
licitação vencida e executada pela Procomp/Diebold. Esta complexidade, aliada à coerência
interna e às especificações oficiais do sistema, sugere tratar-se de documento autêntico.
Esta autenticidade se sustenta como plausível, ademais, pela combinação entre complexidade,
coerência e datas envolvidas. Explico-me: seria razoável supor como pouco provável a tese de
um eventual agente falsificador dando-se a trabalho técnico de tal magnitude sem possibilidade
de ganho aparente. É difícil acreditar que alguém se dispusesse a desenvolver código-fonte de
longos programas, tais como módulos para treinamento de eleitores e de mesários, para coleta de
justificativas, para apuração do voto-cantado e mais alguns, e integrá-los funcionalmente a um
programa de votação, sem possibilidade de testes finais posto que sempre foi vedado o acesso
livre ao equipamento a que se destinaria, sendo tudo isto referente a uma eleição já passada há
mais de 3 anos, cujos resultados já estão juridicamente resolvidos e tidos, portanto, como
irreversíveis, com o único propósito de tentar difamar.
Colegas e experientes programadores consultados a respeito foram unânimes, embora sob o

desejo de permanecerem anônimos neste trabalho, em opinar que o exemplar do arquivo
SETUP.BAT em exame não apresenta, devido ao seu porte, à complexidade de opções do se
código, à coerência de sua lógica interna e à indisponibilidade de hardwares homologados para
testes não oficiais, traços de falsificação ou de forja. Os nomes dos supostos autores, citados no
cabeçalho inicial do programa contido no referido exemplar, poderiam, em tese (ou
necessidade), apontar quem poderia confirmar ou refutar a autenticidade do documento.
2.3 Plausibilidade e verificabilidade
Porém, é sabido que esses alegados autores, se verdadeiros, estão legalmente comprometidos em
seus contratos de trabalho com o sigilo do mesmo. Se não pelas práticas trabalhistas e negociais
comuns às empresas contratadas e subcontratadas para fornecimento, manutenção e operação do
sistema eleitoral brasileiro, ao menos indiretamente, pelas cláusulas jurídicas impostas aos que
teriam, por lei, direito de fiscalizar esse trabalho, cláusulas estas de caráter absoluto e
irrevogável [10] (comentários em [18]). E também por justificativas já apresentadas pela Justiça
Eleitoral ao restringir tal direito, baseado na Lei 9.504/01, aos fiscais dos partidos políticos que
tentassem cumprir a bom termo técnico a sua missão [17].
Assim, agimos de boa fé ao acreditar que seria ilegal os alegados autores se manifestassem sobre
a questão, ou mesmo que deles se solicitasse uma tal manifestação, motivo pelo qual não foram
consultados sobre a autenticidade do exemplar de programa que os nomeia como autores, para
aqui reforçar a tese da plausibilidade da autoria e origem do material em exame. Dentro deste
quadro de fatos, e tomando como plausível a autenticidade do material em exame, procedeu-se a
presente análise do código-fonte no arquivo SETUP.BAT publicado na internet, para posterior
encaixe em descrições oficiais do sistema eleitoral brasileiro.
Em respeito ao direito autoral dos verdadeiros programadores ou seus detentores, quaisquer que
sejam, o código completo do exemplar do SETUP.BAT em exame não é reproduzido neste
trabalho; apenas pequenos trechos de poucas linhas, necessários para explicar situações de risco
oferecidas à reflexão. E a imagem aqui replicada apenas pelo desejo e necessidade de se honrar
tributo a um grande brasileiro.
3. Descrição do Sistema
Descrições do fluxo de informação dentro do sistema eleitoral brasileiro podem ser encontradas
em [8] e [9]. Simplificadamente, o processo eleitoral pode ser subdividido em cinco etapas
subseqüentes:
1. Cadastramento nos Cartórios Eleitorais;

2. Identificação do Eleitor nas Seções de Votação;
3. Votação em Cabina Indevassável;
4. Apuração dos votos de cada Seção;
5. Totalização dos Votos de todas as Seções.
3.1 Arquitetura Geral
Introduzidas em 1996, as urnas eletrônicas brasileiras receberam por função a de ser o

dispositivo físico para a execução das etapas 2, 3 e 4. A união das funções de identificação do
eleitor e de votação (etapas 2 e 3) num mesmo equipamento informatizado, sob a premissa
constitucional do sigilo do voto, é peculiar das urnas eletrônicas brasileiras. As urnas eletrônicas
americanas produzidas pelo mesmo fabricante, Diebold, não possuem a função de identificação,
executando elas apenas as etapas 3 e 4.
O acúmulo das etapas 2 e 3 numa mesma máquina introduziu risco adicional e em princípio
evitável ao sistema, que é o fato de duas informações que não poderiam nunca ser juntadas, o
voto e a identidade do votante, estarem disponíveis no mesmo equipamento. Se este
equipamento tiver sua função ampliada, poderá refazer a relação entre esses dados, violando o
princípio constitucional do sigilo do voto. Por este motivo é que o Relatório da Sociedade
Brasileira de Computação [10] afirma em suas conclusões que:
“O projeto da urna não elimina a possibilidade de que a identidade do eleitor seja

vinculada a seu voto.”
O relatório da SBC se referia ao sistema eleitoral do TSE de 2002, mas esta sua conclusão se
aplica sem restrições ao sistema de 2000, visto terem ambas versões exatamente a mesma
arquitetura neste aspecto. O chamado relatório Unicamp [9], por sua vez, descreve análise
conduzida sobre um sistema eleitoral informatizado fornecido pelo TSE como sendo a versão
usada na eleição de 2000. Não se trata, portanto, de análise do sistema em produção, ou seja,
feita diretamente em urnas usadas nas eleições de 2000.
3.2 Arquitetura Básica das Urnas Eletrônicas
Se o material analisado no chamado relatório Unicamp e o usado na eleição brasileira de 2000

forem o mesmo, como dá a entender o TSE, o relatório revela que as urnas eletrônicas
brasileiras em 2000 possuíam arquitetura interna similar aos micro-computadores modelo IBM-
PC, com recursos adicionais de segurança contra falhas não intencionais (bateria, impressoras,
etc), e tendo como software básico o Sistema Operacional VirtuOS, da empresa Microbase, um
sistema similar ao DOS da Microsoft (MS-DOS), mas com recursos adicionais para multitarefas.
O arquivo SETUP.BAT no sistema operacional VirtuOS desempenha a mesma função do

arquivo AUTOEXEC.BAT no MS-DOS e em alguns windows: deve conter programa que é
sempre o primeiro executado pelo sistema operacional, após este completar a sua própria carga,
assim que a máquina é ligada, podendo controlar todo o funcionamento do sistema a partir daí.
Tanto no DOS como no VirtuOS, arquivos de extensão .BAT são interpretados como “lote de
comandos”, ou batch files.
Escritos em texto pleno, isto é, código ASCII como qualquer arquivo de formato txt, batch files
listam comandos a serem executados seqüencialmente pelo interpretador do sistema operacional
(shell). Programas que executam diretamente a partir da forma em que são escritos pelo
programador (código-fonte), sob a ação de um outro programa que interpreta o código-fonte
para a linguagem de máquina subjacente, são ditos interpretados. Batch files são portanto
programas interpretados, também chamados de “scripts”.
Programação por lote de comandos interpretados, ou scripting, é o modo mais simples possível
de se programar em ambiente DOS/VirtuOS. Oferece poucos recursos aos programadores, como
desvios de execução e laços condicionais bastante limitados, programação seqüencial elementar,
sem apoio a objetos (dados e/ou subprogramas com estrutura) e sem passagem de parâmetros
para funções (procedures). Além disso, por ser uma forma de programação interpretada e não
compilada, isto é, onde o código-fonte teria que ser traduzido para linguagem de máquina antes
da instalação do correspondente executável, a modificação de scripts é extremamente fácil,
podendo ser feita em editores de texto comuns, de forma intuitiva e interativa, no próprio
ambiente de produção.
Arquivos de função semelhante à do AUTOEXEC.BAT raramente contém mais que umas

poucas linhas. No AUTOEXEC.BAT por exemplo, apenas os comandos necessários para chamar
as funções que completam a inicialização do sistema básico, tais como tabelas de idioma, cores
da tela, primeira chamada a antivírus, etc. O recurso ao scripting é utilizado com parcimônia
ainda maior em sistemas de alta periculosidade, como são os sistemas socialmente sensíveis
onde se representam mais de dois interesses (num sistema eleitoral: o de cada partido, em
ganhar, e o do operador do sistema, para que nenhum deles fraude). Com raras excessões o
scripting é usado para controlar mecanismos de proteção essenciais à segurança dos seus
agentes, devido à característica limitada de recursos, aliada à facilidade de modificação e de
adulteração. Não surpreende, portanto, que os antivirus falhem tanto.
Na opinião deste autor, trata-se de um fato inédito encontrar-se um script de inicialização de

ambiente DOS com 6.200 linhas de código, e causa espécie encontrá-lo justamente em sistema
que demanda alto nível de proteção. Doutra feita, e pelos mesmos motivos, é muito fácil
encontrar a escolha desse método de programação (scripting) entre softwares embusteiros. A
quase totalidade dos vírus que hoje infestam na internet sistemas operacionais já citados, são
escritos em um dialeto de linguagem de scripting oriunda do MS-DOS, o VBScript.
Segundo o edital de fornecimento das urnas [7], cabia ao fornecedor desenvolver os programas
do sistema, o que nos leva a entender que foi a Procomp/Diebold que escolheu utilizar o sistema
operacional VirtuOS, como também incluir todo o controle da verificação de integridade de
hardware e software da urna em um script de inicialização. Mas cabia à Secretaria de
Informática do TSE avaliar, validar, aceitar e homologar, ou não, estas decisões e métodos de
programação, obviamente de baixíssima resistência a ataques por parte de quem possa ter acesso
privilegiado ao sistema.
No contexto em que sistemas livres, de robustez sobejamente comprovada e superior à dos

supracitados, desimpedidos de barreiras jurídicas artificiosas a seu uso, adaptabilidade ou
auditabilidade (e.g. propriedade intelectual do fornecedor), configura-se incompreensível e
injustificável a validação e aceitação das opções técnicas que vêm subrepticiamente norteando a
informatização do nosso sistema eleitoral, considerando-se o ponto de vista do eleitor
interessado no equilíbrio de riscos e responsabilidades de todos os agentes envolvidos [19].
3.3 Arquitetura do Sistema de Segurança contra fraude nas Urnas Eletrônicas
Por fraude, neste caso, deve-se entender qualquer ação que permita:
a) violar o voto, inclusive seu sigilo; e/ou

b) adulterar a soma dos votos de forma crível.
O chamado relatório Unicamp [9] descreve boa parte do que seriam os mecanismos de proteção
contra fraude nas urnas eletrônicas de 2000. O sistema de 2000 não produz nenhum documento
ou material que permita a recontagem ou conferência da tabulação desses votos (feita na urna),
ou da totalização (apuração feita na rede dos tribunais eleitorais) eletrônicas, como permitiria o
voto impresso, conferível pelo eleitor, previsto na abortada Lei 10.408/02. Assim, toda
segurança contra fraude nas urnas eletrônicas se baseava, e voltou a se basear com a revogação
da referida lei, em mecanismos para se garantir a idoneidade e a integridade dos programas que
executam, nas urnas ou redes de totalização, durante a eleição.
Simplificadamente, o trabalho para se conseguir garantias de idoneidade de um software pode

ser dividido em três etapas:
VALIDAÇÃO: quando se estuda e se testa o programa para verificar seu funcionamento

adequado;
CERTIFICAÇÃO: quando se verifica a integridade do software, ou seja, que o software
validado é o que está sendo de fato utilizado;
AUDITORIA: posterior ao evento, quando de verifica se o desempenho foi regular, e que
o software não foi alterado depois da certificação e antes ou durante a votação.
O sistema eleitoral de 2000 não previa a auditoria da apuração eletrônica (tabulação e

totalização), pois não criava documentação necessária para tal, como por exemplo, o voto
impresso verificado pelo eleitor, previsto na lei 10.408/02, que entraria em vigor na eleição
seguinte. A única auditoria possível era restrita ao processo, excluída a votação propriamente
dita. Seria aquela permitida pela análise dos arquivos de log das urnas, que ademais são
produzidos e armazenados sob condições que comprometeriam sua integridade e, portanto, sua
confiabilidade, como será mostrado adiante. A auditoria pela análise dos logs pode fornecer
informações sobre o uso das máquinas (hora em foram ligadas, programas acionados, etc.), mas
não serve para informar nada sobre a tabulação dos votos que teriam sido sufragados na urna. E
nem pode efetivamente servir, sem a quebra do princípio constitucional do sigilo do voto.
No presente trabalho se procede a uma análise que corresponderia aproximadamente à etapa de

validação do software das urnas-e de 2000. Condições técnicas de se proceder a uma certificação
inexistem, uma vez que as urnas eletrônicas utilizadas em 2000 já foram todas reutilizadas em
2002, com as informações pertinentes ao seu uso em 2000 destruídas quando da regravação dos
flash-cards utilizados. O chamado relatório Unicamp [9], em seu capítulo 4.3, informa que, nas
eleições de 2000, os partidos políticos, fiscais oficiais do sistema eleitoral, também não teriam
condições técnicas de certificar o software utilizado nas urnas eletrônicas, ao afirmar:
“... não há mecanismos simples e eficazes que permitam que representantes de

algum partido, em qualquer lugar do país, possam confirmar que os programas
usados nas Urnas-E correspondem fielmente aos mesmos que foram lacrados e
guardados no TSE.”
Uma perícia nas urnas eletrônicas utilizadas na eleição de Camaçari, Bahia, em 2000 [21],
revelou que o software nelas utilizado durante aquela eleição não era o mesmo que havia sido
validado pelos partidos políticos em agosto de 2000. Ressalte-se, mais uma vez, que o presente
trabalho analisa o exemplar de script no SETUP.BAT pressupondo-o idêntico ao utilizado nas
urnas eletrônicas de 2000, com lastro nas evidências arroladas na seção 2 e complementadas nas
seguintes, mas sem a intenção de assumir ou atestar tal identificação, diferentemente do
chamado relatório Unicamp.
O problema da certificação do software eleitoral não é exclusivo de estudiosos do sistema e

fiscais de partido. Também o próprio sistema deve fazer uma autocertificação ou uma
autoverificação de integridade, em momentos cruciais do processo, para detectar se foi
modificado de forma inesperada. Porém, é necessário compreender que a autoverificação e a
autocertificação, neste contexto, têm alcance limitado à prevenção ou detecção de ataques de
origem externa, direcionados à violação de programas da urna ou de falhas não intencionais nos
componentes do sistema.
Em 2002, tornou-se público o fato de que o sistema não dispunha de nenhum mecanismo de
proteção para efetivamente prevenir ou detectar ataques de origem interna, ou seja, ataques
perpetráveis por parte de quem conhece o sistema pela necessidade de operá-lo. Os lacres
físicos, mandatórios nas urnas eletrônicas, a título de garantia de absoluta inviolabilidade dos
programas e dados armazenados nos seus dispositivos eletrônicos internos, como propalado a
quatro ventos por vários magistrados da Justiça Eleitoral [20], não serviam a tal propósito, como
restou provado numa perícia judicial nas urnas usadas na eleição de 2000 na cidade de Santo
Estevão, Bahia, [12]. Nesta, o perito nomeado pelo Poder Judiciário constatou:
1. Que havia uma urna eletrônica que teria sido lacrada no dia 23 de setembro de 2000, mas
que teve seu software recarregado no dia 25 mantendo os lacres intactos.
2. Que era perfeitamente possível abrir a tampa frontal das urnas modelo 98 e 2000, trocar os
dispositivos eletrônicos de armazenamento interno de programas e dados conhecidos por
flash-cards, violando-os, e voltar a fechá-la, SEM ROMPER OS LACRES!
A lacração da urna periciada em Santo Estêvão cumpria rigorosamente a resolução da Justiça

Eleitoral que detalhava com precisão a posição em que quatro lacres de papel adesivo deveriam
ser afixados, entre a tampa e o chassi da urna. Como deveriam ser afixados em todas as urnas
eletrônicas, da mesma forma que em eleições anteriores, por outras resoluções. Ocorre que o
posicionamento dos lacres demandado pela resolução era tal que violações do tipo desvelada por
essa perícia seriam sempre possíveis na quase totalidade das urnas, através da remoção da
módulo de impressão de boletins, seguido da retirada de parafuso posicionado por detrás do
mesmo, como se constatou naquela perícia [12].
3.4 Garantias invertidas
Ou seja, a garantia dos lacres era, efetivamente, a de que ataques de origem interna, por parte de
custodiantes de urnas lacradas que conhecessem os detalhes, não seriam detectados pelo
mecanismo supostamente projetado para detectá-los. Ao contrário do que alardeavam a quatro
ventos alguns magistrados da Justiça Eleitoral [20], enquanto nenhum perito nomeado por parte
interpelante foi jamais autorizado a periciar uma urna eletrônica, em processos de impugnação.
Enquanto solicitações de testes de segurança, recomendados pelo OSI, foram sequer respondidos
ao partido solicitante. Temos que reconhecer, todavia, que a inversão de sentido na garantia dos
lacres, entre o anunciado e o efetivo, pode ter ocorrido por algum lapso do autor da resolução
que regulamentava a lacração.
Mas temos também que reconhecer: este tipo de lapso é também uma brisa de tentação
assoprada constantemente no modelo obscurantista. Nessas circunstâncias, dizer que o sistema é
seguro porque ninguém nunca provou a ocorrência de fraude é sofisma, que muito se aproxima
do deboche e do cinismo. Para sondarmos tal proximidade, temos que perguntar se a dos lacres
seria a única inversão de garantias obscurecida, talvez acidentalmente. O chamado relatório
Unicamp, apesar de nada mencionar a respeito desta inversão, revela fatos que apontam
indiretamente para outra, agora envolvendo o esquema da autoverificação de integridade dos
programas.
Segundo a descrição oficial do sistema, dois algoritmos de cálculo de “Resumo Criptográfico”

(hash) são utilizados para produzir, cada um, uma espécie de impressão digital de cada arquivo
do sistema, armazenadas num arquivo como "assinaturas", para posterior comparação com o
recálculo das mesmas no momento da verificação. Um desses era o algoritmo conhecimento
publicamente por MD5, enquanto o outro seria de arquitetura fechada, supostamente
desenvolvido pelo fornecedor do sistema operacional VirtuOS e, portando, desconhecido fora de
sua esfera de proteção ao sigilo. Mas, segundo o tal relatório, em sua seção 4.5, o esquema de
autoverificação da integridade usado em 2000 seria o seguinte:
“Usando o algoritmo convencional (MD5), é calculado um resumo criptográfico para cada

arquivo da árvore de diretórios da aplicação de votação. Os nomes dos arquivos e seus resumos
são gravados, um por linha, num arquivo com extensão .CRC. Para prover um nível extra de
segurança, é calculado também o resumo criptográfico (com o algoritmo ASSINA) de cada
arquivo .CRC, o qual é guardado em um outro arquivo com extensão .SIG.
Estes resumos são verificados pelos programas executados durante a inseminação da UE e todas
as vezes em que ela sofrer uma inicialização (boot). Esta verificação também é realizada durante
a execução de alguns programas que compõem o aplicativo de votação.
Qualquer modificação feita em algum arquivo da UE que não seja acompanhada pela
correspondente modificação dos arquivos .CRC e .SIG será detectada, já que os procedimentos de
verificação recalculam os resumos e os comparam com aqueles que foram gravados nos
diretórios na época da criação dos mesmos.
Como o mecanismo de verificação de integridade e autenticidade dos arquivos está embutido

dentro da própria UE, torna-se difícil criar um esquema totalmente seguro, já que os parâmetros
de verificação estão contidos dentro da própria estrutura a ser verificada (neste caso, nos cartões
de memória flash). Esta verificação poderia ser aprimorada com a adição de um mecanismo
externo independente, o qual é objeto de recomendação deste relatório.
Conclui-se que a combinação do uso das técnicas públicas e proprietárias de resumo

criptográfico torna muito difícil o sucesso de qualquer tentativa de modificação posterior dos
programas executáveis sem que tal tentativa seja detectada. Toda a segurança do mecanismo de
verificação de integridade e autenticidade empregado se baseia no segredo do algoritmo de
resumo criptográfico ASSINA responsável pelos 256 bits guardados nos arquivos .SIG.”
Esta descrição do esquema de autocertificação das urnas eletrônicas é muito esclarecedora, mas
algumas das conclusões acima podem ser contestadas, supondo-se autêntica a origem do
material aqui em análise, como veremos adiante.
4. Análise da Segurança
Comecemos por examinar, na citação anterior do referido relatório, uma primeira fragilidade do
mecanismo de autoverificação da integridade dos programas das urnas eletrônicas. A que se
revela no fato desse mecanismo e o resultado a ser verificado estarem, ambos, no próprio
dispositivo cuja integridade se quer assim verificar (flash-card interna, ou FI). Esta mesma
fragilidade foi também encontrada nas urnas eletrônicas americanas da Diebold, conforme
aponta o estudo dos professores das Universidades de John Hopkins e Rice [1].
Um levantamento sobre o referido relatório, de autoria do engenheiro Amílcar Brunazo Filho

[13], revela, outrossim, que o programa ASSINA (o do algoritmo restrito) era de fato produzido
pelo CEPESC, órgão subordinado à Agência Brasileira de Inteligência, ABIN, tendo sido apenas
encapsulado pela Microbase, para integrar a versão do VirtuOS fornecido ao TSE. E que o
algoritmo encapsulado seria, na realidade, o algoritmo público conhecido como SHA1. Mais
uma informação técnica obscurecida, afetando uma propalada garantia, desvelada apenas ao
final de criteriosa e paciente investigação.
Depois do detalhe dos quatro lacres, agora o de que bastava calcular o hash MD5 de um arquivo
e “reassiná-lo” com o SHA1, trocando, no arquivo de "assinaturas", as do arquivo original pelas
da respectiva versão adulterada. Quem e como poderia trocar, veremos adiante. Por enquanto,
observemos que a “segurança baseada no segredo do algoritmo” era, para não dizer um jogo de
palavras, apenas mais uma garantia cuja efetividade estava invertida. Pois o segredo não era do
algoritmo, era do nome do algoritmo. Não seria preciso ter acesso legítimo e controlado ao
ambiente onde um algoritmo secreto de assinaturas estaria implementado, para se poder
modificar programas com o aval da autoverificação. Bastaria o nome. Mais um acidente
lingüístico, ou, mais um catavento para tentações assopradas pelo modelo obscurantista,
inadequadamente empregado sob condições estruturais de alto risco de conluio.
4.1 Autoverificação e assinaturas
Sustentada a hipótese de origem autêntica do material aqui analisado, outra fragilidade

tampouco citada no referido relatório é o fato da maior parte do esquema de autoverificação de
integridade ser controlado por script profusamente comentado. Portanto, ainda mais facilmente
adulterável por qualquer agente com acesso legítimo às urnas, a um editor de texto qualquer e a
conhecimento mínimo do sistema para operá-lo. Em sistemas com alto risco de fraude de origem
interna, como devem ser classificados, de acordo com práticas saudáveis [14], os sistemas
eleitorais informatizados, esta prática contraria o mais elementar bom senso, não precisando um
profissional mediano da informática se arvorar especialista em segurança de computadores para
percebê-lo.
Listamos alguns dos comentários explicativos encontrados no exemplar do arquivo SETUP.BAT

para ilustrar o que se diz acima. Vale lembrar que, no código-fonte dos shells DOS, comentários
são formados pelas letras “REM” -- de “remark” -- no início da linha, servindo o restante para
informar o leitor humano, ignorado pelo programa interpretador do script. Logo no início do
script em exame, são apresentadas explicações para os nomes dos parâmetros utilizados no
restante do programa para a identificação dos diretórios; identificação esta necessária, por
exemplo, para a alteração ou inserção de novos comandos neste mesmo script, quer com o
intuito de fazer o sistema funcionar conforme a especificação oficial, quer com o intuito de
violá- la sorrateiramente:
REM DEFINE AS UNIDADES DE DISCO
set DQ=a:
set FI=c:
set FC=d:
REM * ANALISE DO CONTEUDO E DA INTEGRIDADE DA FLASH INTERNA
REM * Diretorios possiveis de serem encontrados na Flash Interna:

REM * %FI%\ --- raiz da FI
REM * %FI%\aplic --- software aplicativo
REM * %FI%\virtuos --- software basico
REM * %FI%\trab --- arquivos de trabalho da eleicao
REM * %FI%\resul --- arquivos de resultados da eleicao
REM * %FI%\basedado --- arquivos de dados para a eleicao
Comentários detalhados e abundantes dentro de um programa em código-fonte, como acima, é

prática sadia para facilitar o entendimento e a depuração de programas na fase de
desenvolvimento, ou em versões destinadas à manutenção e validação do sistema. Mas em
scripts de produção, facilitam bastante o trabalho de quem quiser modificá-lo a partir de uma
modalidade de acesso que permita regravação. É preciso refletir sobre as condições em que esta
facilidade é desejável.
Mesmo que o arquivo analisado não seja de produção, isto é, mesmo que a versão instalada para
controlar as urnas eletrônicas durante a votação em 2000 não tenha os comentários do exemplar
analisado, a fragilidade do esquema permaneceria. Para a segurança dos eleitores que usam tais
urnas, a fragilidade não se restringiria à profusão de comentários no script de inicialização.
Começa no fato do controle dos mecanismos de proteção dessas urnas estar em um script de
inicialização.
O controle dos mecanismos de proteção poderia, ao menos, ser colocado em programa ou

programas compilados. Uma vez compilados e instalados, certos ataques de origem interna
menos sofisticados seriam dificultados, porque o processo de compilação (que traduz o código-
fonte em linguagem de máquina) expurga os comentários do código executável. Depois de
instalado, o executável não pode ser mais diretamente manipulado sem risco de colapso, exceto
por quem conheça muito bem a linguagem do processador, tenha bastante experiência em
programação e editores especializados, e alie tais conhecimentos ao da lógica do sistema, este
muito mais difícil de ser extraído do executável do que de um script comentado. Já em relação a
quais ataques seriam dificultados, isso depende dos mecanismos.
4.2 Controle dos mecanismos de proteção
Para ilustrarmos a gravidade do risco de ataque interno a que estaria exposto um sistema com tal
forma de controle da proteção, buscamos exemplo na úlma eleição realizada com o sistema
eleitoral brasileiro, a de 2002. Nela, este controle estaria nas mãos de mais de 10 mil operadores
terceirizados pela fornecedora para operar a eleição, de quem os fiscais de partido não
conseguem da Justiça Eleitoral sequer os nomes, ou nas mãos de quem os instruía em tarefas que
lhes eram opacas. Para entendermos como, e como esse controle poderia ser malversado,
examinemos o trecho do script no SETUP.BAT onde seria acionada a verificação da integridade
dos programas instalados no flash-card interno das urnas eletrônicas.
Este acionamento seria feito pela seguinte seqüência de comandos, da qual foram retirados os
comentários e os desvios intermediários, e ajustada a descrição dos dispositivos de
armazenamento, para facilitar o entendimento:
diskfix c: /vs > nul
if errorlevel 1 goto TentaRecuperar
ckpack c:\raiz.crc c:\ > nul
if errorlevel 1 goto ebatger
O Comando “diskfix” é chamado para verificar o disco C: (flash-card interna) sendo que o
resultado desta verificação não é apresentado na tela da urna por causa do parâmetro “> nul”.
Em seguida, o script verifica se o comando encerrou corretamente ou se houve erro na

verificação de integridade. Se houve erro (if errorlevel), a execução da inicialização se
desvia (goto) para o endereço “TentaRecuperar”, senão segue adiante para o comando
“chpack”, que verifica se as assinaturas recalculadas sobre os arquivos no diretório raiz da
flash-card interna (disco C:) são as mesmas que estão gravadas no arquivo “raiz.crc”.
Um dos arquivos no diretório raiz é o próprio SETUP.BAT, de forma que a sua autoverificação
seria facilmente burlável, de maneira imperceptível por quem usa a urna, pelo simples acréscimo
da diretiva “REM” em posições adequadas. Assim, a inserção de apenas oito letras no script de
inicialização do sistema operacional, conforme descrito abaixo, faria com que as assinaturas dos
programas instalados na urna deixasse de ser recalculado e comparado aos valores no arquivo de
assinaturas. Inclusive, obviamente, a do próprio arquivo SETUP.BAT contendo este script, não
sendo necessário ao fraudador nem mesmo trocar as assinaturas previamente gravadas nos
arquivos .crc:
diskfix c: /vs > nul
REM - if errorlevel 1 goto TentaRecuperar
ckpack c:\raiz.crc c:\ > nul
REM - if errorlevel 1 goto ebatger
Isto poderia ser feito por quem tivesse, por exemplo, acesso físico ao flash-card interno. A partir
desse acesso, poder-se-ia contaminá-lo com programas embusteiros, antes ou depois de
carregado com os softwares eleitorais, bastando editar as duas linhas do arquivo SETUP.BAT,
conforme descrito acima, e alterar o processo que tabula votos sufragados na urna. A maneira
mais simples de alterar a tabulação de votos seria através de um pequeno programa que age
como Robin Hood. Inserido entre os arquivos da urna, ao final da votação ele interceptaria a
gravação do boletim de urna para alterar, de forma balanceada, porcentagens pré-programadas
nos totais de votos de candidatos, indexados pelo número que lhe foi designado desde o registro
da candidatura, meses antes [19].
Esse programa "Robin-Hood" poderia ser acionado por uma linha de comando tão simples como
as citadas anteriormente, inserida em posição adequada no script do SETUP.BAT, já hackeado
para não verificar alterações nos arquivos. Se o programa "Robin-Hood" for bem feito, sua
última tarefa será deletar a si mesmo, e as alterações no script SETUP.BAT que permitiram o seu
silencioso acionamento. Com isso, apagaria seus rastros depois do boletim de urna ser alterado,
tornando a fraude indetectável até por eventuais auditorias, após a divulgação do resultado da
eleição.
Perante a tentação de se voltar a sofismar sobre as dificuldades de acesso físico às flash-cards

internas depois de instaladas nas urnas, agora com um quinto lacre, vale antes observar que esta
não é a única forma de se adulterar o seu conteúdo. E que tais adulterações podem ter efeito
tanto mais abrangente quanto mais cedo forem feitas, ao longo do processo de replicação de
softwares para inseminação nas urnas. Ou seja, quanto antes no transporte e replicação desses
softwares, copiados da rede de computadores da Justiça Eleitoral para os geradores de mídia
usados para inseminar as urnas, processo este, aliás, muito mal fiscalizado pelos partidos
políticos, muitas vezes até dificultado por postura ostensivamente obscurantista de certos
tribunais regionais eleitorais.
Depois de inseminadas as urnas, esse tipo de fraude teria o menor efeito possível, localizado.
Mesmo assim, alcance igual ao das antigas técnicas de fraude com urnas de lona e cédulas de
papel. Uma a uma, só que invisível na forma eletrônica. Essa forma invisível de violação a
varejo era possível não apenas sob a proteção da resolução que ditava os detalhes da lacração
física das urnas eletrônicas, em vigor até junho de 2002. Resolução que foi depois corrigida, por
outra instituindo um quinto lacre, datada de antes, mas até onde se pôde constatar vinda a
público somente depois da perícia de Santo Estêvão, na internet em 16 de agosto de 2002.
Outras formas invisíveis de violação a varejo resistiriam ao fim do segredo dos quatro lacres.
4.3 Modelos de confiança para a arquitetura de segurança
Formas de fraude eletrônica de varejo e de origem interna sem abir a urna serão explicadas; mas
antes, cumpre relembrar que o detalhamento aqui oferecido não constitui denúncia de fraude no
sistema eleitoral brasileiro, muito menos incitação à fraude. Seu objetivo, a quem o queira
interpretar como denúncia, será somente sobre a inadequação do modelo obscurantista de
segurança adotado. Mesmo porque não se tem como fato, mas como hipótese, a origem do
exemplar do arquivo SETUP.BAT aqui analisado.
Em outras palavras, este detalhamento busca, unicamente, explicar de forma didática o porquê
dos conceitos de autoverificação e autocertificação serem totalmente inócuos para proteção geral
de sistemas informáticos que operam em circunstâncias onde o conluio seja uma possibilidade
teórica no modelo de confiança a ele adequado [19]. No caso, adequado pela ocorrência de mais
de dois interesses potencialmente conflitantes em cena. A saber, os interesses de pelo menos
dois partidos, concorrentes a um pleito, e os da Justiça Eleitoral, que executa esse pleito com tal
sistema e julga o resultado com seu poder de Justiça.
De volta aos exemplos didáticos, e sob o único intuito de explicar o sentido desta inadequação,
observe-se que todas as formas de ataque aqui descritas se devem ao mesmo equívoco
conceitual na modelagem da segurança, decorrente da dependência completa a mecanismos de
proteção que só servem para detectar falhas não intencionais ou intrusões por quem não detêm
direitos de acesso e conhecimento do sistema necessários para operá-lo. Decorrentes do
equívoco de se buscar proteção eficaz apenas contra as ameaças menos perigosas à lisura de um
pleito sufragado eletronicamente, as mais fáceis de serem neutralizadas.
Para indicar mais algumas dessas formas de ataque de origem interna, podemos começar, no
script, com o ponto de controle para ataques que requeiram alteração de dados da sessão
eleitoral de cada urna
REM VERIFICANDO INTEGRIDADE DOS ARQUIVOS ESPECIFICOS DA ELEICAO
ckpack c:\aplic\apl_elei.crc c:\aplic > nul
if errorlevel 1 goto eaplic
E o que permite ataques que requeiram alteração em componentes eletrônicos da urna, já que a
verificação de integridade da BIOS (Binary Input-Output system), também é controlada pelo
mesmo script (A BIOS é um programa de inicialização de hardware que vem embarcado em
chip removível e que controla o acionamento e a intercomunicação entre os diferentes
dispositivos eletrônicos de um computador tipo PC):
REM VERIFICA SE O BIOS ESTA PROTEGIDO
uecheck /J > nul
if errorlevel 1 goto bios_desprotegido
A inserção de "REM" antes dos comandos ckpack e uecheck burla a verificação da

integridade esperada.
Outra forma de ataque muito simples consiste em adulterar a tabela de candidatos (excluindo um
candidato a vereador indesejável, por exemplo) ou a tabela de eleitores (incluindo ou retirando
eleitores). Como a verificação da integridade dos arquivos com estas tabelas também seria
controlado por comando no script do SETUP.BAT, com as mesmas falhas de segurança já
apontadas, torna-se fácil, a quem tem acesso legítimo à urna, perpetrar estes ataques (que não
modificariam o programa de votação e apuração, apenas a base de dados), manipulando os
comandos
REM CONTROLA A INTEGRIDADE DA BASE DE CANDIDATOS GERADO NA CARGA
ckpack c:\basedado\candidat.crc c:\basedado > nul
if errorlevel 1 goto ecandidat
REM CONTROLA A INTEGRIDADE DA BASE DE ELEITORES GERADO NA CARGA
ckpack c:\basedado\elelocal.crc c:\basedado > nul
if errorlevel 1 goto eeleitores
Com a inserção da diretiva “REM” à frente dos comandos “ckpack” ou dos comandos de desvio
(“if”), burlar-se-ia invisivelmente a verificação da integridade da base de dados da urna.
Também a verificação de integridade feita por outros programas da urna, como o próprio
programa de votação por exemplo, poderiam ser eventualmente burladas, por quem detivesse
acesso privilegiado na inseminação do software, conhecimento do segredo sobre o verdadeiro
sentido da inviolabilidade dos quatro lacres, ou do algoritmo de assinatura de "arquitetura
fechada". A do aplicativo de votação, por exemplo, como sugerido por Teixeira e Brunazo [11,
cap. 6.3].
A ativação, em momento oportuno, de um programa residente embusteiro, como o já citado

"Robin-Hood" seria simples. Basta incluir, em posição adequada, uma nova linha no script do
SETUP.BAT com o seu nome e caminho, junto com a neutralização (comentando o script) ou
atualização (trocando assinaturas) da autoverificação. Entretanto, a fragilidade talvez mais grave
ainda não foi apontada.
4.4 Calcanhar de Aquiles
O calcanhar de Aquiles da arquitetura de segurança que emerge do encaixe das peças em exame,
que são o script de inicialização analisado e as descrições oficiais do sistema eleitoral brasileiro
de 2000, está no fato de muitas autoverificações se darem com base na checagem da existência,
ou não, de arquivo com determinado nome em determinado dispositivo, independentemente do
seu conteúdo. Por exemplo, a decisão do script do SETUP.BAT de verificar os arquivos de teste
é tomada pela existência ou não de um arquivo com o nome de “eleicao” no diretório raiz:
if exist c:\eleicao goto bypassa_teste_integridade
ckpack c:\raiz2000.crc c:\ > nul
Para burlar verificações controladas por arquivos cujo único propósito é sinalizar um caminho
de execução ao sistema, bastaria renomear o arquivo apontado, não importa o seu conteúdo. Não
seria necessário nem que se adulterasse o script do SETUP.BAT. Além disso, o uso desses
arquivos pode servir de "esconderijo". Usados para abrigar programas embusteiros, chamados a
executar por algum comando introduzido nalgum script, como o do SETUP.BAT. Em momento
oportuno, e sem chamar a atenção pela existência de arquivos inesperados na flash-card interna.
Como o hipotético programa "Robin-Hood", do exemplo inicial.
Também os arquivos de log das urnas, que registram o uso das mesmas para efeito de posterior
auditoria, seriam passíveis de manipulação semelhante. Por exemplo, a seqüência que registra a
primeira operação da urna seria:
:faz_log_inicial
REM URNA FOI LIGADA
REM log 02 - A LIGADA JA É LOGADA NA SUBIDA DO PROPRIO DRIVER DE LOG
REM SE EH A PRIMEIRA VEZ QUE SOBE A URNA, FAZ LOG DE QUE OCORREU
CARGA COM SUCESSO
REM
if not exist c:\novo.sb goto JaLogouCarga
log 07
del c:\novo.sb
O comando “log 07” é que registra a mensagem de “carga com sucesso”. Comentar este
comando (colocar as letras REM no início da linha) faria o script seguir adiante sem que nada se
registre no arquivo de log. Aliás, tal adulteração poderia ser feita em qualquer ponto onde um
eventual registro de log se tornasse indesejável. Ou, ao contrário, poder-se-ia forçar no log o
registro de um evento que não se realizou. Nesta seqüência de comandos se vê, novamente, a
fragilidade em se decidir por um caminho do processo com base na existência de um arquivo.
No caso anterior, determinado “novo.sb”. Bastaria brincar de esconde-esconde como tal
arquivo, renomeando-o lá e cá, para que o comportamento do sistema, como registrado nos logs,
entre com Alice no país das maravilhas.
Em outras palavras o arquivo de log, como instrumento de auditoria das urnas eletrônicas, seria
ineficaz, visto que se poderia adulterar dinamicamente a sua função, via script do SETUP.BAT,
tornando-o uma peça ficcional. Todas estas fragilidades apontadas por uma breve análise do
script em exame facilitariam e viabilizariam inúmeras formas de ataque de origem interna ao
sistema eleitoral, e de rastros também facilmente apagáveis antes da divulgação dos resultados
fraudados. Possibilidades estas antes já sinalizadas, só que de forma mais hipotética em [11] e
[19], e solenemente ignoradas, talvez pelo caráter especulativo.
Mas a novidade agora nos permite melhor dosar especulação, observação e dedução. Com ela, a
segurança do eleitor interessado em opiniões e sistema equilibrados, aquelas quanto à seriedade,
e este quanto aos riscos dos agentes envolvidos, inclusive no tocante à competência para avaliar
riscos, e dentre riscos inclusive os de interesses privilegiadamente ocultos, apresenta-se como
potencialmente bem mais precária do que se podia antes especular. É que, no script de
inicialização em análise, arquivos sinalizadores são por vezes procurados em disquete. Como
por exemplo, na linha de comando:
if exist a:\disco9 goto ConsisteBaseCandidatos
fato que pode ter gerado uma das críticas do chamado relatório Unicamp, que assim corrobora a
plausibilidade de origem autêntica do script aqui analisado. A equipe contratada para produzir
tal relatório detectou que o sistema da urna eletrônica poderia ter seus arquivos trocados nos
flash-cards internos, a partir da colocação de disquetes devidamente preparados com um
determinado conjunto de arquivos. Por exemplo, a seqüência de procedimentos que dispara o
programa de votação do 1º turno é a seguinte:
1. Verifica-se se no disquete existem arquivos com nomes: “disco15”, “eleicao” e

“instala.bat” ;
2. Se existir o arquivo “instala.bat”, este arquivo é copiado para o disco C: e em
seguida executado;
Se não existir, o aplicativo “roda_t1” é executado.
Desta forma, quem tivesse acesso legítimo à urna eletrônica, entre a inseminação e o uso na
eleição, poderia facilmente alterar o conteúdo de qualquer programa e base de dados do flash-
card interno explorando a janela aberta por essa tosca verificação. Com um pequeno script em
disquete, idêntico em formato ao do SETUP.BAT, contendo comando para sobrescrever um ou
mais arquivos do flash-card interno por homônimos do disquete, junto com sua assinatura no
arquivo correspondente, também no mesmo disquete.
No caso do exemplo anterior, bastaria dar o nome instala.bat ao arquivo com este pequeno
script e ligar a urna com o disquete nela inserido, para se ter uma urna transformista. Tal
situação é precária porque esse tipo de janela -- emoldurada na greta para o disquete -- pode
levar a urna ao país das maravilhas mesmo com seu trinco fora do script de inicialização.
5. Conseqüências para Eleições Seguintes
Com isso, a arquitetura de segurança que emerge do encaixe dos peças do material analisado
continuaria permitindo os mesmos ataques de origem interna, independente de onde estejam os
controles. Mesmo que esses passem para um programa executável compilado, por exemplo. A
medida "de segurança adicional" de impressão das assinatutas dos arquivos da urna, por
exemplo, mudaria apenas na forma de se obter a informação sobre como funciona o trinco da
janela de Alice, mas nada nas paisagens dos dois lados dessa janela. Janela pela qual poderia
passar um disquete tirado de um bolso sem crachá, por um terceirazado sem nome, sem vínculo
trabalhista com a Justiça, enquanto as urnas vão sendo inseminadas na ausência do juiz da Zona,
como na 1a. eleitoral de São Paulo em 2002, em seu próprio fórum.
Ressalte-se, novamente, que dentre as mudanças ocorridas desde 2000 visando eliminar
vulnerabilidades já antes sinalizadas, é de conhecimento público apenas uma. Apenas aquela
destinada a corrigir o sentido da garantia oferecida pelos lacres de papel adesivo, posicionados
entre as tampas e os chassis das nossas urnas eletrônicas. O que até aqui se revela, revela
também um grave equívoco que os técnicos da Unicamp poderiam ter cometido em seu
relatório, caso o arquivo de SETUP.BAT aqui analisado coincida, mesmo que só em
funcionalidade, com o que lhes foi dado analisar. O grave equívoco estaria na assertiva ali
lavrada, de que
“Qualquer modificação feita em algum arquivo da UE que não seja acompanhada

pela correspondente modificação dos arquivos .CRC e .SIG será detectada”.
5.1 Arroubos e Frouxidões
Tal assertiva seria patentemente falsa com respeito ao arquivo SETUP.BAT. Através da análise
acima oferecida, fica claro como seria fácil, a quem tiver acesso legítimo à urna, eliminar a
citada detecção pela inserção de apenas oito letras no script, e com isso modificar qualquer dos
programas nela instalado, sem detecção. A verificação de integridade do sistema pode ser
facilmente neutralizada se, ao conceito de integridade, incluirmos o modo mais relevante para
sistemas com a missão social daquele analisado por profissionais da Unicamp. A saber, a
integridade relacionada à possível associação entre má-fé e abuso de poder, por parte de quem o
controla. Nessa assertiva, os autores do relatório omitem uma predicação essencial, do tipo "por
agentes que ignorem o script de inicialização" ou "por agentes que desconheçam os controles do
mecanismo de verificação", ao substantivo "qualquer modificação feita".
Esta omissão compromete a cientificidade da assertiva e, em conseqüência, da gerenalidade

excessiva na linguagem que abre sua seção "Conclusões", eleita "resumo executivo" pela grande
mídia. A segurança do sistema eleitoral brasileiro foi ali menosprezada no que tange a esse
modo de integridade, se não ignorada. Desleixo explicável apenas, dada a competência dos
profissionais contratados para a tarefa de avaliação relatada, pela sua acrítica aceitação dos
objetivos impostos à tarefa pelo contratante, conforme analisado em [15]. Tarefa esta que teria
custado aos cofres públicos R$450 mil, e cujo nebuloso valor semiológico foi creditado, ao
menos pela grande mídia e por tabela pelo leigo, ao nome da instituição científica que os
contratados integram.
No contexto geral, a ambigüidade nas conclusões do referido relatório poderia se justificar pela
acriticidade. Por exemplo, argumentando-se que "algum arquivo" não pretendia significar
"qualquer arquivo", embora seja este o sentido que o contexto semântico da frase selecione, na
ausência de predicado à ação 'qualquer modificação feita' [15]. Mas não se justificaria
eticamente, pela importância social do sistema e pelas potenciais conseqüências de uma semiose
enganosa. Se a base ética do menosprezo aos riscos à integridade em modo citado, quer na
arquitetura de segurança do sistema, quer em avaliações oficiais tidas por independentes, for a
aristotélica -- a ética da virtude no caráter da autoridade --, na democracia esta ética só se realiza
pela transparência, estratégia oposta à obscurantista adotada, paradoxalmente à guisa da
necessidade de segurança.
Uma das contribuições adicionais que esta presente análise pode oferecer é a de colocar o
referido relatório em perspectiva. Para que não se lhe atribuam, em citações apressadas ou
desleixadas, mais do que a tarefa relatada em sua introdução se propôs a alcançar,
independentemente da linguagem imprecisa -- e nada científica -- que possa ser encontrada em
incautos arroubos e frouxidões semânticas ali lavradas, dedutivamente ou a título de conclusão.
Segurança é controle da proteção, e proteção não existe sem sujeito e predicado. Se estão
implíticos, como na introdução no relatório, isto não significa que sejam universais. Resumindo,
não se deve confundir segurança contra a fraude com segurança para a fraude, muito menos
induzir leigos a confundi-las.
5.2 "It's not a bug, it'a feature!"
Toda a análise acima se aplica às eleições de 2000 no Brasil, se a origem indicada no material
analisado for autêntica. Já nas eleições seguintes, de 2002, a empresa fornecedora do software
das urnas eletrônicas brasileiras foi a Unisys, que optou por manter o sistema VirtuOS em 350
mil urnas e adotar o sistema Windows CE em outras 50 mil urnas.
As fragilidades aqui apontadas dizem respeito ao sistema que teria sido produzido pela
Diebold/Procomp, não se aplicando diretamente às urnas com sistema operacional Windows CE
fornecidas pela Unisys. Mas poderiam, potencialmente, ainda ser aplicadas às 350 mil urnas que
vêm mantendo o sistema operacional VirtuOS e às outras, devido à arquitetura do sistema como
um todo. Como por exemplo, ataques de Alice-no-país-das-maravilhas com disquetes e arquivos
sinalizadores, por mãos terceirizadas que operam eleições cumprindo ordens. Nesse contexto,
antes que se sofisme sobre a desatualização do material em exame, como fez a Diebold na
grande mídia dos EUA, examinemos o que mais pode ser dito acerca de versões posteriores,
tendo em vista a última eleição já transcorrida no Brasil, em 2002.
Sabe-se que técnicos da COPPE foram contratados para produzir um relatório sobre o sistema
eleitoral brasileiro de 2002, mas não se tem notícias de sua publicação oficial. Como foi dito na
introdução, junto com o script aqui analisado foi também publicado um relatório cuja autoria
original é atribuída à Fundação COPPETEC, ligada à COPPE [6]. Este relatório aponta a baixa
qualidade e imaturidade no desenvolvimento do software eleitoral, que seria o brasileiro de
2002, predizendo que, daquela forma como fora desenvolvido, o comportamento do sistema
seria imprevisível. Esta afirmação, anonimamente atribuída à análise que a equipe da
COPPETEC teria feito sobre a documentação oficial do sistema brasileiro, foi corroborada por
fatos.
Nas eleições de 2002, devido aos inúmeros problemas apresentados no 1º Turno, incluindo um
momentâneo mergulho da apuração oficial do candidato Lula em território negativo (menos 41
mil votos), resolvido com o desliga-religa de computadores e explicações do seu presidente na
linha "foi erro de formatação e não se fala mais nisso", o TSE promoveu um reparo de
emergência nos programas entre o 1º e o 2º Turnos. Curiosamente, as alterações nas urnas
eletrônicas forma introduzidas pela via de duas das fragilidades contra fraudes internas aqui
apontadas: a possibilidade de alteração dos dados e programas pela simples inserção de um
disquete ou flash-card devidamente preparado, e a possibilidade de controle do arquivo de log
para registrar apenas os eventos desejados. Fato que ademais corrobora a plausibilidade da
origem autêntica do material aqui analisado (ainda bem que o sistema em questão não era o da
Venezuela!).
Mas mesmo não sendo o da Venezuela, pode-se entender que, também nas eleições de 2002,
havia graves falhas de segurança no nosso sistema. Não na segurança de quem o controla acima
do bem e do mal, mas na do eleitor interessado em opiniões e sistema isentos. Onde o risco de
detecção de conluio envolvendo operadores se equipare ao risco destes cometerem fraudes
impunemente. Apesar de algumas alterações terem sido feitas, como a resolução determinando a
colocação de um quinto lacre nas urnas, para inverter o sentido da efetiva garantia por eles
oferecida, e a adoção de mais um programa de autocertificação, para imprimir os valores das
assinaturas dos arquivos da urna, essas novas medidas têm efeito apenas cosmético na segurança
que poderia almejar o nosso hipotético eleitor.
A primeira, como já explicado. E a segunda (a impressão dos valores das assinaturas dos
arquivos da urna), para saber como burlá-la, basta notar a forma como ela é acionada. Se
novamente por Alice, pela presença em disquete quando a urna é ligada, de arquivo de programa
com um determinado nome, bastará a um eventual fraudador interno reescrever o programa que
imprime as assinaturas dos arquivos, fazendo-o imprimir não os valores que possam estar no
arquivo de assinaturas da urna, nem os de lá recalculados quando da verificação, nem ambos,
apenas os valores esperados por quem esteja "fiscalizando".
5.3 Fiscalização e opinião publica
Como o disquete não é transparente nem translúcido, mas opaco, o fiscal só pode fiscalizar com
olhos crédulos aquilo que o programa escreve na tela ou na impressora da urna, sem poder tocar
em nada. O fiscal acredita que não pode tocar em nada por causa da segurança, achando que a
dele, mas sem saber porque. E como o fiscal não sabe, o programa cujo comportamento ele está
ali para observar poderia transmutar-se em programa Tudo-jóia. Rodando a partir do disquete
acionador do original, interceptando o comando que acionaria o original, Tudo-jóia mostraria o
que o fiscal possa interpretar com tranqüilidade: tudo jóia, no país das maravilhas eleitorais.
Para 2004, a Procomp/Diebold voltou a ser a fornecedora do software das urnas brasileiras e, até
o momento, nada indica que as falhas aqui apontadas foram ou serão corrigidas. Em especial a
falha de se ter no mesmo ambiente todos os dados de verificação da confiabilidade do sistema e
a própria ferramenta de verificação. Somente um estudo isento e independente sobre o que está
sendo desenvolvido no presente momento, poderia esclarecer tais dúvidas.
Porém tal meta, apesar de nobre, parece impossível de ser alcançada. Sob o atual regime
jurídico-institucional, a inspeção dos arquivos de programas do sistema, a título de fiscalização
permitida por lei, sempre foi e vem sendo possível apenas em condições absolutamente inócuas
à fiscalização eficaz de sistemas informáticos. Permitidas somente em ambiente computacional
totalmente controlado pelo fiscalizado, fora do ambiente de produção (o das eleições em si) e,
pior, sob o mais rigoroso compromisso de sigilo acerca das informações relativas ao objeto da
fiscalização. No mais, pode-se apenas observar o que dizem as resoluções, leis e processos, e
tentar compreender suas correlações. E estas, quanto mais convolutas, menos impactam o eleitor
leigo, quanto a eventuais falácias e ineficácias.
Podemos resumir esse drama com uma metáfora. A cada nova eleição, somos brindados com um
novo jogo de espelhos, se não mais sofisticado, mais complexo que o anterior. Seu mais
espetacular efeito é seguir entretendo a opinião pública ufanista e ingênua, enquanto o modelo
de confiança sobre o qual se construiu, se legisla, se julga e se opera nossa maravilha eleitoral
continua o mesmo. Um modelo que despreza o risco de conluio, por demais simplista em missão
social como a de um tal sistema, em regime institucional que se pretenda democrático. Se
continuar a evoluir nessa direção, em algum momento alguma dessas fantasias irá se esboroar.
6. Conclusões
As conclusões desta análise, no que tange ao arquivo SETUP.BAT supostamente desenvolvido

pela Diebold/Procomp para as eleições brasileiras de 2000, são muito semelhantes àquelas dos
técnicos e acadêmicos norte-americanos que analisaram software de funcionalidade e origem
semelhantes [1], supostamente oriundas das máquinas de votar da Diebold americana.
Sustentadas as hipóteses de origem autêntica dos documentos analisados lá e cá, fornecidos pela
mesma empresa, foram encontradas inúmeras fragilidades nos seus sistemas de segurança que
permitiam, e que poderiam em tese ainda permitir, com grande facilidade a quem precisa
manipulá-lo, a execução de mecanismos destinados a desviar ou identificar votos. E o que é pior,
de forma também facilmente obscurecível a qualquer auditoria a posteriori.
6.1 A questão política
A arquitetura de segurança do sistema eleitoral informatizado parece ter sido relegada, lá e cá, a
segundo plano, tratada antes como opção de projeto da alçada de empresas ou consultorias
contratadas para o seu desenvolvimento [19], ou a obscuros lobbies legislativos [17], do que
como tema político da mais alta sensibilidade e importância cívica, que precisa seguir seu
próprio curso. Cá, com o agravante do mais próximo resgate -- o processo de fiscalização
eleitoral -- vir sendo tratado como atividade lúdica, performance na qual uma cinderela chamada
opinião pública dança em fabuloso salão, lotado de belas teses hermenêuticas positivistas,
encerado com uma mistura pastosa de fobia e desdém pelo saber técnico como poder difuso.
Chamar a si, para delegar a poucos, tamanha responsabilidade pode ser um erro, pois, no poder,
aparência de má fé é contagiosa.
Contra este tipo de ameaça aos princípios democráticos, parece que os cidadãos norte-
americanos estão mais dispostos a se defenderem do que os nossos compatriotas, ainda
embriagados de ingênuo ufanismo por nossa "conquista tecnológica", ainda sem bem entender
quem nela é conquistador e quem é conquistado. Assim nos parece pelas notícias que nos
chegam. De lá, sobre a crescente mobilização popular contra o poder excessivo de quem fabrica
e/ou opera as novas caixas-pretas da cidadania. De cá, pela forma atabalhoada e canhestra como
foi aprovada a última lei eleitoral brasileira no Congresso Nacional, em 1/10/2003 [4, 17]. E
como esta lei vem sendo regulamentada e aceita, ademais agora que o grande líder desta luta
cívica entre nós se foi, homenageado póstumo desta singela contribuição à causa.
Leonel Brizola deve, porém, ser antes visto como exemplo de brio e digna tenacidade, do que
como nosso último bastião de vigilância cívico-democrática, tombado pela inexorabilidade da
morte. Morte irônica, já que o velório teve mais eleitores por ele chorando do que sua última
eleição os teve nele votando, para senador da República. É a mágica dessas urnas eletrônicas,
conquista tecnológica cantada em prosa e verso pela grande mídia, como na capa da revista Veja
de 16 de Outubro de 2002, reproduzida abaixo
Leonel de Moura Brizola

Falecido em 21/06/04 aos 81 anos
No destaque jornalístico lastreado em deboche e ofensas a esse baluarte da vida pública

brasileira, ali execrado em duvidosas companias, apesar de modelo de brasilidade que a história
há de reverenciar, faltou ao grande veículo do absolutismo tecno-neoliberal na mídia explicar
algo: como foi tirado de circulação o único politicossauro desenhado com as quatro patas firmes
no chão. Os outros, é fácil intuir, teriam tropeçado em suas próprias contas e explicações
obscuras, mas e o velho Briza? No texto atrás da capa, apenas a verdade absoluta e meteórica
das maravilhosas urnas eletrônicas brasileiras. Subentendida, mas agora distoante das lágrimas
do adeus.
6.2 Homenagem póstuma
Brizola nunca desistiu de lutar pela transparência dessa maravilha. Ele, o então senador Roberto
Requião e alguns brancaleontes, espicaçados como conspiracionistas retrógrados, lutaram e
conseguiram, com a ajuda do fugaz mal estar que o escândalo do painel do senado nos causou, a
aprovação da lei 10.408/02, introduzindo meios para recontagem de votos impressos,
posteriormente atabalhoada e canhestramente banida. Banida em meio a piruetas semânticas de

magistrados potencialmente atingíveis, a achincalhes circulados por essa espécie de mídia,
entrelaçadas a cínicas mentiras como as enunciadas do plenário da Câmara dos Deputados, em 1
de Outubro de 2003 [17].
E agora, onze meses depois da grotesca farsa democrática desse banimento, e dois meses de
enterrado quem chamou de fóssil político, esta mesma espécie circulante volta à carga. Até em
telejornais de campeã audiência, regurgitando diariamente irresponsáveis denúncias vazias de
"monstruosas fraudes", sem nenhum embaraço pela farsa da renúncia de Chávez orquestrada em
abril de 2002, ela agora insiste num sagrado direito democrático. Mas não nosso: o de abusados
perdedores em país vizinho, inconformados com uma surra diferencial de 17% em referendo
presidencial. Qual direito? O de fazerem auditoria do sistema eleitoral eletrônico, através da
recontagem dos votos impressos, lá disponíveis. Seria a firmeza das quatro patas brizolistas um
ato falho do inconsciente coletivo no artista gráfico da Veja, a denunciar tão deslavada e
nauseabunda hipocrisia?
Independente de suas últimas escolhas eleitorais terem sido boas ou más para o mundo, o povo
irmão norte-americano ainda tem lições de cidadania a dar, a uma sociedade globalizada pelo
cerco cada vez mais ubíquo e sinistro da aliança entre poder econômico e domínio tecnológico.
Aliança que coopta o poder político sob o véu de inevitabilidade com que o poder mitiático --
operado por essa espécie circulante -- hipocritamente lhe cobre, enquanto dela se nutre.
Lá, onde leis eleitorais são estaduais, vários estados vêm modificando as suas, de sorte a impor a
seus processos eleitorais mecanismos de recontagem por meio de registro material dos votos, no
rastro do escândalo dos softwares da Diebold e da última eleição presidencial, sob pressão de
grupos de cidadãos organizados contra o risco de fraudes eleitorais. Justamente lá, no tear dessa
tessitura de nova ideologia e nova religião, que é o absolutismo tecno-neoliberal. Sua
inevitabilidade, caros leitores, é apenas mais um véu sobre a face do destino humano. Pode
parecer maravilhoso, especialmente a Narcisos, mas é um véu que um dia cairá, para revelar o
próximo.
Descanse em paz, velho Briza! A firmeza de seu caráter sobrevive como ícone, nem que pelas
patas do poder.
Referências Bibliográficas
[1] – Rubin, Aviel D., Kohno, T.,Stubblefield, A. e Wallach, D. S., “Analysis of an Electronic
Voting System”. Consultado em 10 de janeiro de 2004 em: http://avirubin.com/vote.pdf
[2] – Shelley, K., “Decertification and Whitdrawal of Approval of Accuvote-TSx Voting

System”.Secretaria de Estado da Califórnia. Abril de 2004. Consultado em 02 de maio
de 2004 em: http://www.ss.ca.gov/elections/ks_dre_papers/decert.pdf
[3] – Schwartz, J., “High-Tech Voting System Is Banned in California” . New York
Times. Publicado em 01 de maio de 2004 em:
http://www.nytimes.com/2004/05/01/national/01VOTE.html
[4] – Rezende, P. A. D., “A Seita do Santo Byte”. Consultado em 20 de fevereiro de 2004 em:
http://www.cic.unb.br/~rezende/trabs/azeredo.htm
[5] – Seixas, I., Paglerani, R. B., Gonçalves, M. J. [?], “Setup.FI - Setup da urna usado para a
Eleição Oficial do Tribunal Superior Eleitoral". Setembro de 2000. Consultado em 01
de março de 2004 em: http://www.angelfire.com/journal2/tatawilson/ue2000.zip
[6] – Rocha, A. R. C., Travassos, G. H., Souza, G. S., Mafra, S. [?], “Relatório de Avaliação do
Software do TSE”. Fundação COPPETEC, COPPE/UFRJ, agosto de 2002. Consultado
em 01 de março de 2004 em: http://www.angelfire.com/journal2/tatawilson/coppe-

tse.pdf
[7] – Tribunal Superior Eleitoral. “Edital de Licitação, mediante Concorrência, nº 27/99”.

Diretoria Geral do Tribunal Superior Eleitoral, julho de 1999, Disponível em:
http://www.votoseguro.org/arquivos/EditalUE2000.zip
[8] – Brunazo F., A., “A Segurança do Voto na Urna Eletrônica Brasileira” in Seminário de
Segurança em Informática, SSI’99, ITA. Anais... São José dos Campos, SP, Brasil,
1999. Disponível em: http://www.votoseguro.org/arquivos/SSI99int.zip
[9] – Tozzi, C. L. et alli. “Avaliação do Sistema Informatizado de Eleições (Urna Eletrônica)”.

UNICAMP, maio de 2002. Disponível em:
http://www.tse.gov.br/servicos/download/rel_final.pdf
[10]– Graaf, J. V., Custódio, R. F., “Tecnologia Eleitoral e a Urna Eletrônica”. Sociedade
Brasileira de Computação. 2002. Disponível em:
http://www.sbc.org.br/ArquivosComunicacao/TSE.pdf
[11] – Teixeira, M. C. e Brunazo Filho, A., “Reflexões sobre Confiabilidade de Sistemas

Eleitorais”. Fórum do Voto Eletrônico. Janeiro de 2001. Disponível em:
http://www.votoseguro.org/textos/reflexoes.htm
[12]– Rego, C. A., “Auditoria de Sistemas Eleitorais – O Caso Sto. Estevão ”. Fórum do Voto
Eletrônico. Consultado em 10 de março de 2004 em:
http://www.votoseguro.org/textos/stoestevao1.htm
[13] – Brunazo F., A., “O Relatório TSE-FUNCAMP - Um Laudo, Duas Conclusões”. Fórum do
Voto Eletrônico. Disponível em:
http://www.votoseguro.org/textos/relfuncamp1.htm#1.4
[14] – Brunazo F., A., “Critérios para Avaliação da Segurança do Voto Eletrônico” in Workshop
em Segurança de Sistemas Computacionais, Wseg'2001, UFSC. Anais... Florianópolis,
SC, Brasil, 2001. Disponível em: http://www.votoseguro.org/arquivos/Wseg2001.zip
[15]- Rezende, Pedro A. D. "Análise do relatório Unicamp"
http://www.cic.unb.br/~rezende/trabs/relunicamp.htm
[16]- Forum do Voto-E: "Lei do voto virtual às cegas" http://www.brunazo.eng.br/voto-

e/textos/PLazeredo.htm
[17] – Brunazo F., A., “Lei do Voto Eletrônico” revista eletrônica Consultor Jurídico,
17/12/2001. Acessado em http://www.cic.unb.br/~rezende/trabs/e-voto.htm.
O Dep. Moroni Torgan afirmou, em discurso do plenário da câmara, que o voto

impresso é perigoso porque permite ao eleitor vender seu voto de posse do recibo
do voto impresso. (http://www.brunazo.eng.br/voto-e/arquivos/collares2.rm). A lei
10.408/02, que intruduziria o voto impresso sendo banido pelo PL em votação,
nada fala de recibo de voto.
[18] – Rezende, P. A. D., Brunazo F., A., e outros “Burla Eletrônica”. Livro Eletrônico sobre
experiências fiscalizatórias com o sistema eleitoral eletrônico brasileiro. Disponível em:
http://www.cic.unb.br/~rezende/trabs/BurlaEletronica.pdf
[19] – Rezende, P. A. D. “A Lanterna de Diógenes”. Artigo escrito para um seminário técnico

que teria ocorrido no Senado Federal, no esteio do esândalo do painel, mas que nunca foi
realizado. http://www.cic.unb.br/~rezende/trabs/paisagem.htm
[20] – Rezende, P. A. D. “Fiscalização e Garantias”. Entrevista ao jornalista Fabrício Azevedo,

do Jornal da Comunicade de Brasília.
http://www.cic.unb.br/~rezende/trabs/entrevistaJCBSB.htm
[21]- Teixeira, M. C. et alli. “Parecer sobre o Laudo Técnico da Perícia das urnas Eletrônicas
de Camaçari - 2000”. Partido Popular Socialista, Processo n.º 41/01 da 171ª Zona Eleitoral da
Bahia. Disponível em: http://www.votoseguro.org/textos/camacari2.htm
Direitos autorais
Este artigo é distribuido sob a licença copyleft publicada em
http://www.gnu.org/licenses/fdl.pt.html:
Livre para republicação resguardadas a integridade e autoria, e vedadas quaisquer restrição alem
desta, em republicações

Analise de Um Sistema Eleitoral Eletrônico

Enviado por

Dados do documento

Descrição original:

Título original

Direitos autorais

Formatos disponíveis

Compartilhar este documento

Compartilhar ou incorporar documento

Opções de compartilhamento

Você considera este documento útil?

Este conteúdo é inapropriado?

Direitos autorais:

Formatos disponíveis

Analise de Um Sistema Eleitoral Eletrônico

Enviado por

Direitos autorais:

Formatos disponíveis

14/05/2021 analise de um sistema eleitoral eletrônico

http://www.cic.unb.br/~rezende/sd.htm > Urna eletrônica: Avaliação

Análise de um sistema eleitoral eletrônico

Publicado no Observatório da Imprensa em 7/09/04

Prof. Pedro Antonio Dourado de Rezende

Em 2003, quatro professores da Johns Hopkins University e da Rice University

O presente trabalho, desenvolvido com a ajuda de voluntários, tem por objetivo

2,1 Propósito deste trabalho

3.1 Arquitetura geral

4.1 Autoverificação e assinaturas

4.3 Modelos de confiança para a arquitetura de segurança

5. Conseqüências para eleições seguintes

5.1 Arroubos e frouxidões

6.1 A questão política

Em março de 2004, durante as eleições primarias norte-americanas, problemas em máquinas

Com esta novidade pudemos desenvolver o presente trabalho.

No capítulo 4 a análise propriamente dita, sobre a segurança das urnas em relação à

alegada origem dos documentos assim disponibilizados. Como o presente trabalho se

2.1 Propósito deste trabalho

O propósito deste trabalho se constitui, por um lado, em tributo póstumo a um insuperável

Ressalte-se, ainda, que, sustentada a hipótese de originalidade do material analisado, em nenhum

O exemplar de SETUP.BAT publicado na internet é um longo arquivo em forma de texto pleno,

2.2 Origem do material em análise

Colegas e experientes programadores consultados a respeito foram unânimes, embora sob o

2.3 Plausibilidade e verificabilidade

1. Cadastramento nos Cartórios Eleitorais;

3.1 Arquitetura Geral

Introduzidas em 1996, as urnas eletrônicas brasileiras receberam por função a de ser o

“O projeto da urna não elimina a possibilidade de que a identidade do eleitor seja

3.2 Arquitetura Básica das Urnas Eletrônicas

Se o material analisado no chamado relatório Unicamp e o usado na eleição brasileira de 2000

O arquivo SETUP.BAT no sistema operacional VirtuOS desempenha a mesma função do

Arquivos de função semelhante à do AUTOEXEC.BAT raramente contém mais que umas

Na opinião deste autor, trata-se de um fato inédito encontrar-se um script de inicialização de

No contexto em que sistemas livres, de robustez sobejamente comprovada e superior à dos

3.3 Arquitetura do Sistema de Segurança contra fraude nas Urnas Eletrônicas

a) violar o voto, inclusive seu sigilo; e/ou

Simplificadamente, o trabalho para se conseguir garantias de idoneidade de um software pode

VALIDAÇÃO: quando se estuda e se testa o programa para verificar seu funcionamento

O sistema eleitoral de 2000 não previa a auditoria da apuração eletrônica (tabulação e

No presente trabalho se procede a uma análise que corresponderia aproximadamente à etapa de

“... não há mecanismos simples e eficazes que permitam que representantes de

O problema da certificação do software eleitoral não é exclusivo de estudiosos do sistema e

A lacração da urna periciada em Santo Estêvão cumpria rigorosamente a resolução da Justiça

3.4 Garantias invertidas

Segundo a descrição oficial do sistema, dois algoritmos de cálculo de “Resumo Criptográfico”

“Usando o algoritmo convencional (MD5), é calculado um resumo criptográfico para cada

Como o mecanismo de verificação de integridade e autenticidade dos arquivos está embutido

Conclui-se que a combinação do uso das técnicas públicas e proprietárias de resumo

Um levantamento sobre o referido relatório, de autoria do engenheiro Amílcar Brunazo Filho

4.1 Autoverificação e assinaturas

Sustentada a hipótese de origem autêntica do material aqui analisado, outra fragilidade

Listamos alguns dos comentários explicativos encontrados no exemplar do arquivo SETUP.BAT

REM DEFINE AS UNIDADES DE DISCO

REM * ANALISE DO CONTEUDO E DA INTEGRIDADE DA FLASH INTERNA

REM * Diretorios possiveis de serem encontrados na Flash Interna:

REM * %FI%\aplic --- software aplicativo

REM * %FI%\virtuos --- software basico

REM * %FI%\trab --- arquivos de trabalho da eleicao

REM * %FI%\resul --- arquivos de resultados da eleicao

REM * %FI%\basedado --- arquivos de dados para a eleicao

Comentários detalhados e abundantes dentro de um programa em código-fonte, como acima, é