http://www.pedro.jmrezende.com.br/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
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:

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:

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;
    3. 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.pedro.jmrezende.com.br/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.pedro.jmrezende.com.br/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.pedro.jmrezende.com.br/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.pedro.jmrezende.com.br/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.pedro.jmrezende.com.br/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.pedro.jmrezende.com.br/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