Índice

1. Introdução

2. Validação de Programas Computacionais

3. A Política de Desenvolvimento Estanque - PDE

4. Avaliação da Efetividade da PDE 

Questão 1 - Como ter certeza do cumprimento da PDE pelo TSE? 

Questão 2 - Validar apenas o código-fonte é suficiente? 

Questão 3 - Para se adulterar um sistema é necessário conhece-lo totalmente?

5. Possibilidades de implantação de códigos espúrios ao sistema 

5.1 Via código-fonte não auditados 

5.2 Via código-fonte após auditoria incompleta 

5.3 Via bibliotecas padrão do compilador 

5.4 Via código já compilado 

5.5 Outras vias

6. Possibilidades do um código espúrio fraudar a apuração 

6.1 Na camada do Aplicativo de Votação, conhecendo-se seus detalhes 

6.2 Na camada das bibliotecas, com algum conhecimento da estrutura de dados 

6.3 Nas camadas do Software Básico sem nenhum conhecimento adicional

7. Conclusão

Apêndice: Relatório sobre apresentação no IX Simpósio Brasileiro de Computação Tolerante a Falhas, SCTF 2001

1. Introdução

A demorada apuração dos votos nas eleições americanas de 2000, estimulou o debate sobre a conveniência e confiabilidade de sistemas eleitorais automatizados. Aqui no Brasil, muitos sugeriram que o sistema eleitoral brasileiro deveria servir de modelo aos americanos. Mas será que a confiabilidade de nosso sistema eleitoral é suficientemente garantida?

Ao longo de 2000, fomos convocados pelo Senado - referências [Teixeira] e [Brunazo] - e por Partidos Políticos para avaliar a confiabilidade do sistema eleitoral informatizado brasileiro. Com este intuito, comparecemos algumas vezes ao Tribunal Superior Eleitoral (TSE) em Brasília e, apesar da simpática e atenciosa acolhida que recebemos do grupo de técnicos em informática do TSE e da Procomp, empresa fabricante das urnas de 1998 e 2000, temos algumas considerações a fazer sobre a questão da confiabilidade dos programas utilizados.

Certamente não se deve confundir a questão da confiabilidade técnica de um programa com a confiabilidade das pessoas envolvidas no seu projeto e operação. Neste artigo não tratamos nem abordamos questões relativas à honra ou moral das pessoas envolvidas no processo de informatização das eleições brasileiras. Abordamos, apenas, a questão técnica de se determinar a confiabilidade de todo um sistema complexo de informatização eleitoral.

 

 
 
 

2. Validação de Programas Computacionais

A norma técnica ISO/IEC 15.408 estabelece complexos critérios para avaliação da segurança de sistemas informatizados em geral. Por se tratar de uma norma recente ainda não foi posta em prática dentro do sistema eleitoral brasileiro. 

Mesmo sendo uma norma técnica rigorosa e bastante detalhada, existem alertas de que tal norma é insuficiente para cobrir todas as necessidades de segurança do voto eletrônico, como o apresentado pela Dra. Rebecca Mercuri em sua defesa de tese. 

Segundo a ISO 15.408, a avaliação da segurança deve ser praticada desde a fase de projeto inicial e definição do perfil de segurança, passando pelo detalhamento do projeto, pelo desenvolvimento, testes, operação, seguindo até a análise pós operacional. 

Mais simplificadamente, costuma-se classificar os procedimentos de avaliação da segurança em: validação, certificação, testes e auditoria.

A validação dos programas de um computador consiste em analisar todo o código dos programas, para verificar se ele atende a todos os requisitos do projeto original.

A certificação se refere a comprovar se os programas devidamente validados foram carregados sem falhas ou defeitos nos computadores.

Assim, a avaliação da segurança e, consequentemente, da confiabilidade de sistemas eleitorais informatizados torna-se uma tarefa bastante complexa, trabalhosa e, para que possa ser completada com eficiência, deve-se contar com a transparência dos dados e com a colaboração dos responsáveis pelo desenvolvimento do equipamento avaliado. Mas ao comparecermos para avaliar os programas do sistemas eleitoral informatizados deparamo-nos com algumas barreiras impostas pelo TSE, que comprometem totalmente o valor e alcance de qualquer avaliação externa que alguém queira efetuar.

 

 
 
 

3. A Política de Desenvolvimento Estanque - PDE

Para tentar demonstrar a segurança e confiabilidade do seu sistema eleitoral, a Secretaria de Informática do TSE afirma que os técnicos responsáveis por uma camada de programação do sistema eleitoral não têm conhecimento de outra camada, ou seja, os desenvolvedores do sistema operacional não tem conhecimento dos fontes dos aplicativos e vice-versa. E por sua vez os desenvolvedores dos aplicativos não conhecem a base de dados. Esta é chamada Política de Desenvolvimento Estanque (PDE), que garantiria a segurança e confiabilidade de todo o sistema.

Pelo edital de concorrência da Urna Eletrônica UE2000, as camadas de seus programas são:

Camadas do Software Básico 

1) BIOS 

2) Sistema Operacional 

3) Gerenciadores de Dispositivos (Device Drivers). 

Camadas dos Softwares Aplicativos (entre eles o Aplicativo de Votação) 

4) Códigos-fonte 

5) Bibliotecas-padrão 

6) Bibliotecas especiais (assinatura digital e criptografia) 

7) Bases de Dados.

Ainda referindo-se à PDE, os técnicos do TSE e da Procomp alegam que apenas a camada (4), correspondente ao código-fonte do Aplicativo de Votação, deve passar por um processo de validação por auditores externos pois, segundo o seu entendimento, nas outras camadas não seria possível se programar fraudes nas eleições. Baseado nesta argumentação, não foram apresentado aos técnicos dos partidos políticos, os códigos-fonte do sistema operacional nem das rotinas de criptografia e assinatura digital.

 

 
 
 

4. Avaliação da Efetividade da PDE

Com o único intuito de contribuir para o incremento da confiabilidade e transparência do sistema eleitoral informatizado brasileiro, vamos analisar tecnicamente a procedência desta argumentação por meio de algumas perguntas e respostas.

 

 

Questão 1 - Como ter certeza do comprimento da PDE pelo TSE?

Seria necessário uma abertura muito maior, do TSE, para que uma auditoria externa pudesse realmente comprovar se esta política realmente está sendo seguida a risca. 

Pudemos constatar que a pessoa responsável pelo desenvolvimento do Aplicativo de Votação é funcionário da mesma empresa (Microbase) que fornece o Sistema Operacional. Como garantir que não haverá vazamento de informações através de membros das equipes, que são colegas próximos de trabalho?

Considerando que as pessoas envolvidas não possuem seguros especiais, estabilidade plena de emprego ou qualquer outra forma de proteção contra pressões econômicas conclui-se que a efetividade da PDE acaba por reduzir-se a uma questão confiabilidade pessoal. Se as pessoas envolvidas forem incorruptíveis a PDE funcionaria, caso contrário a PDE deixa de ser a garantia de confiabilidade que o TSE alega.

 

 

Questão 2 - Validar apenas o código-fonte é suficiente?

Num artigo de Ken Thompson, um dos idealizadores do sistema operacional Unix, que se tornou referência mundial sobre a confiabilidade de programas. Neste artigo, Thompson mostra como se pode introduzir código malicioso em programas de computador através de adulteração do próprio compilador, sem precisar alterar o código-fonte do programa atacado e conclui:

"A moral é óbvia. Você não pode confiar em códigos (de programas) que você não escreveu totalmente por si próprio. (Especialmente código de companhias que empregam pessoas como eu.) Nenhum montante de verificação e escrutínio no nível do código-fonte irá protegê-lo do uso de código não confiável. Ao demonstrar a possibilidade deste tipo de ataque eu usei um compilador de C. Eu poderia pegar qualquer outro programa de manipulação de programas como um assembler, um carregador ou mesmo um microcódigo em hardware. Conforme o nível do programa desce, estes vícios de programação se tornarão mais difíceis de se detectar. Um vício em microcódigo bem instalado será quase impossível de ser detectado."

Questão 3 - Para se adulterar um sistema é necessário conhece-lo totalmente?

Esta é uma questão vital para a PDE, pois se para violar um sistema eleitoral não for necessário conhecer todos os detalhes de todos os programas, se for possível violar o sistema tendo-se apenas conhecimento e acesso parcial, então a PDE perde todo poder de servir como garantia de confiabilidade do sistema. 

Para responder a esta terceira indagação, vamos comentar tecnicamente as possibilidades de um sistemas informatizado ter seus resultados e ou funcionalidades alterados em qualquer uma de suas camadas de programação sistema operacional, um único aplicativo, rotinas especificas, bibliotecas de compiladores, etc.

Dividiremos esta análise em duas etapas:

• Possibilidades de implantação de códigos espúrios ao sistema
• Possibilidades de códigos espúrios fraudarem a eleição mesmo com a PDE

Obs. Por preocupação ética dos autores, que compreendem as possibilidades de mau uso de informações aqui apresentadas, o texto a seguir trata apenas da análise das possibilidades mas não detalha como implementar efetivamente uma adulteração em um sistema computacional.

5. Possibilidades de implantação de códigos espúrios ao sistema

Vamos analisar as possibilidades de se introduzir códigos executáveis dentro de um sistema, de forma que não seja detectado por uma auditoria superficial, como a auditoria permitida pelo TSE aos partidos políticos.

Estes códigos teriam algumas peculiaridades importantes a serem atendidas, como se esconder antes do momento de atuar e se auto eliminar após atuação.

 

 
 
 

5.1 Via código-fonte não auditados

É o caso mais simples, consiste em introduzir a rotina espúria, no código-fonte de um programa que não será apresentado para auditoria, como o sistema operacional e as bibliotecas especiais. 

É um procedimento fácil de ser implementado por um membro da equipe de desenvolvedores dentro de sua própria camada de conhecimento. Seria bem mais difícil de ser implementada por alguém externo ao desenvolvimento do sistema, sem que venha a ser descoberto.

A possibilidade de uma fiscalização externa detectar o código espúrio é praticamente impossível a não ser que seus efeitos sejam bastante visíveis (e não se confundam com um erro de programação). Quanto mais baixo for o nível da camada de programação mais difícil a análise dos programas, principalmente se for implementada na camada do sistema operacional. O sistema operacional, por exemplo, é um programa de baixo nível muito difícil de ser auditado apenas com bateria de testes. 

 

 

5.2 Via código-fonte após auditoria incompleta

Consiste em introduzir a rotinas espúrias no código-fonte de um programa que foi anteriormente analisado pelos auditores externos. 

Como dito, a validação e a certificação são etapas da avaliação de sistemas informatizados. Se a certificação, que consiste em verificar se os programas carregados nas urnas são realmente provenientes dos fontes analisados, não for efetuada, fica muito fácil para membros da equipe que faz o fechamento dos aplicativos adulterá-los antes da compilação final.

Sem se proceder a uma certificação rigorosa é praticamente impossível aos auditores detectarem a adulteração e garantirem a integridade do programa original. 

Obs. Deve-se lembrar que o TSE não permite que os fiscais dos partidos façam qualquer verificação, por meio de assinaturas digitais, por exemplo, para determinar se o programa carregados nas urnas são os mesmos que lhes foram mostrados para análise. Ressalte-se, também, que técnicos do TSE reconheceram publicamente que os programas usados nas eleições de 2000 foram efetivamente modificados depois de apresentados aos fiscais dos partidos.

5.3 Via bibliotecas padrão do compilador

Consiste em introduzir rotinas espúrias através de alteração em um biblioteca padrão do compilador (stdio, stdlib, conio, string, etc.). 

Pode-se utilizar de várias técnicas para se alterar um biblioteca. Uma bastante simples seria utilizar a biblioteca original para gerar uma nova biblioteca com o código novo "embutindo" o antigo, por exemplo

void FicaResidente
{
   rotina que
      copia o resto de si mesma para área segura da memória
      implanta desvios como pontos de chamada
      e contém algoritmo malicioso que afeta a apuração
}

int  {novo} printf( const char *format [, argument]... )
{
  FicaResidente ( );
  return printf {original} (format, [,argument]...);
}

Trata-se de procedimento fácil de ser implementado por pessoas que tiverem acesso físico ou remoto, mesmo que temporário, aos ambientes onde se geram as versões finais das várias camadas de programas que compõe o sistema.

A fiscalização externa só conseguiria detectar este tipo de ataque se fizesse uma auditoria minuciosa nos ambientes que geram as versões finais dos programas e esta auditoria teria que acompanhar as compilações das várias camadas de programas. Ambientes de compilação de linguagens que utilizam bibliotecas pré-compiladas, como o Delphy, são particularmente difíceis de serem auditadas pois o atacante poderia inserir o código espúrio, compilar a biblioteca e depois apagar todos os vestígios do seu ataque, como o fonte alterado e a data da compilação.

 

 

5.4 Via código já compilado

A introdução de rotinas espúrias em programas já compilados recorreriam às técnicas de se "envelopar" parte do sistema operacional, do BIOS ou dos aplicativos. São técnicas utilizadas por vírus de computador e, de forma genérica, dependem de:

• Ter acesso físico a um ou alguns programas ou meios que contenham os arquivos executáveis do sistema. (este acesso pode ocorrer em qualquer momento após a compilação até o dia das eleições).
• Conforme o momento que for introduzido o código espúrio, o número de urnas afetadas será diferente, por exemplo 1) logo após a compilação - todas as urnas do país serão afetadas; 2) em um TRE - todas as urnas de um estado; 3) na flash de carga de uma zona - as urnas desta zona; ou 4) em um único equipamento armazenado para as eleições.
• Para este tipo de ataque é necessário conhecimento de assembler do processador utilizado.
• Deve-se introduzir um desvio na inicialização do sistema e fazer acertos em rotinas de conferências internas (como assinaturas digitais).
• Durante a inicialização do sistema, este desvio carrega a rotina espúria que por sua vez introduz outros desvios no sistema operacional, como no acesso a disco, no acesso ao teclado e no acesso ao monitor.
• Estes desvios podem ser nos vetores de interrupções do Sistema Operacional, da BIOS ou no próprio processador (utilizando seus recursos de debug para gerar interrupção quando o programa principal acessar a um determinada área de memória).
• Por ser uma rotina acrescentada ao código compilado depois dele ter sido "assinado" para a verificação de integridade, a primeira prioridade da rotina espúria seria se esconder. Todos os desvios introduzidos filtrarão os acessos de modo a simular a não existência de si própria, num comportamento similar à alguns vírus de computador do tipo "stealth". Por exemplo, se um programa de conferência de assinatura digital ler do disco áreas alteradas pela rotina espúria, ela filtrará estas leituras para enganar a conferência de assinatura.
• A segunda prioridade seria se auto eliminar após as eleições. Basta, para isto, retirar o desvio na inicialização e recompor as áreas alteradas na memória fixa. 

Obs. as explicações, acima, foram propositadamente apresentadas de forma genérica e simplificada. Existem muitos detalhes não mencionados para se evitar que estas informações sejam utilizadas de forma mal intencionada.

Trata-se de um ataque sofisticado que apresenta as maiores dificuldades de implementação, mas quanto mais informações privilegiadas o atacante tiver, mais fácil fica seu trabalho. Por exemplo, membros da equipe responsável pelo desenvolvimento das rotinas de conferência de assinatura digital possuem informações privilegiadas que facilitam a tarefa de fazer o código espúrio se "esconder". 

Mas esta forma de introdução de rotinas espúrias pode, também, ser feita por pessoas completamente de fora das equipes de desenvolvimento, desde que tenham acesso a uma cópia dos executáveis para proceder a engenharia reversa (desassembler e debug) de algumas rotinas chaves. 

É bastante difícil se detectar este tipo de adulteração do sistema, quanto mais bem feito for o ataque, mais difícil será sua detecção. 

 

 

5.5 Outras vias

Associação das formas descritas acima ou outras vias de ataque não pensadas pelos autores. A criatividade dos programadores é grande.

 

 
 
 

6. Possibilidades do um código espúrio fraudar a apuração

Agora vamos analisar as possibilidades de se desenvolver algoritmos maliciosos dentro de rotinas introduzidas conforme item 5, que permitiriam adulterar o resultado da apuração de uma ou de várias urnas eletrônicas.

A maior ou menor facilidade para o desenvolvimento de rotinas fraudulentas depende diretamente da quantidade de informação sobre o sistema-alvo que o atacante tem conhecimento. É justamente para limitar a quantidade de informação disponível para cada pessoa que se adota a PDE. Mas ainda assim se pode desenvolver códigos capazes de interferir no resultado da apuração mesmo contando-se apenas com informações parciais e incompletas do sistema.

Inicialmente considere-se que apesar da PDE existem várias informações que qualquer potencial atacante do sistema tem acesso:

• Interface do programa de votação com o eleitor, que é bastante veiculada pela imprensa e em treinamento patrocinados pelos diversos tribunais eleitorais.
• Interface do programa de votação com o mesário, que são disponíveis nos manuais de treinamento dos mesários que trabalharão nas eleições.
• Número e nome dos candidatos, que são divulgados com bastante antecedência.
• Informações técnicas que constam nos editais de concorrências [5]
• Explicações dadas pelos técnicos do TSE em audiências públicas. 

A seguir analisamos algumas possibilidades de se desenvolver códigos maliciosos conforme as informações adicionais que se disponha.

 

 

6.1 Na camada do Aplicativo de Votação, conhecendo-se seus detalhes

Atuando-se dentro e com conhecimento do Aplicativo de Votação é o caso mais simples de se programar fraudes que alterem o resultado da apuração dos votos. Como a certificação dos programas das urnas não é permitida pelo TSE aos auditores externos, basta se criar algoritmos de desviem sistematicamente os votos já que todos os votos passarão por esta camada. 

Alegar desconhecimento da base de dados para dificultar a geração de um algoritmo malicioso não procede pois os números e nomes dos candidatos são divulgados meses antes de uma eleição e os números dos partidos para cargos majoritários se mantém de uma eleição para outra.

O código fraudulento poderia atuar antes dos dados acumulados serem remetidos para o banco de dados, por exemplo, ao final da votação de cada eleitor a rotina fraudulenta trocaria alguns votos de certos candidatos por votos nulos ou vice versa.

 

 

6.2 Na camada das bibliotecas, com algum conhecimento da estrutura de dados

Embora o aplicativo de votação não contenha nenhuma chamada explícita para uma rotina maliciosa que tenha sido implantada numa biblioteca externa, esta seria chamada quando se usa algumas das funções padrão da linguagem ou funções específicas da biblioteca adulterada e passa a ficar residente na memória volátil, passando a controlar eventos determinados como o horário, a digitação de teclas e acessos ao disco.

A principal diferença com o caso anterior é que naquele a própria chamada explícita da rotina determinava que era o momento de se executar o algoritmo fraudulento. Neste caso será necessário um outro algoritmo para se determinar o momento certo de se chamar a rotina de adulteração de votos, pois a função padrão poderá ser chamada em várias situações que não seja o momento certo de alterar o resultado.

Por exemplo, uma rotina maliciosa feita com conhecimento da estrutura dos dados pode monitorar o horário para, às 16:59 h, trocar os totais acumulados dos candidatos e dos votos nulos e brancos antes da emissão do Boletim de Urna (BU).

 

 

6.3 Nas camadas do Software Básico sem nenhum conhecimento adicional

Lembrando-se que as camadas do Software Básico (BIOS, Sistema Operacional e Device Drivers) não são apresentadas para análise do seu código fonte, pode-se nelas introduzir códigos que desviem votos mesmo sem se ter conhecimento adicionais do sistema além dos disponíveis ao público. Por exemplo

• No primeiro passo, a rotina fraudulenta implantaria desvios e passaria a controlar todo acesso ao teclado e todo acesso à memória de vídeo sempre que estes dados circulassem entre o Software Aplicativo e o Software Básico.
• Em seguida passaria a montar um banco de dados com os números dos candidatos e respectivas telas.
• Quando o eleitor confirmar seu voto, se salvaria os números digitados no teclado (equivalente ao número do candidato) e o respectivo conteúdo da tela com a foto do candidato escolhido.
• Este procedimento se repetiria para vários candidatos.
• Montado um banco de dados passa-se a fase de desvio de votos.
• Quando o eleitor digitar o seu voto interfere-se no processo enviando ao Aplicativo de Votação o número de outro candidato e enviando ao monitor a tela respectiva ao candidato escolhido pelo eleitor.
• Quando o eleitor digitar o "confirma" deixa-se de interferir no processo e assim o Aplicativo de Votação contaria o voto para o candidato errado.
• Antes da 17 h a rotina espúria apagaria todos os seus vestígios na memória permanente, inclusive seu banco de dados, e desfaria os desvios implantados. 
• A apuração teria sido fraudada. 

7. Conclusão

As barreiras impostas pelo TSE à auditoria externa dos programas da Urna Eletrônica limitam muito o alcance desta auditoria. Sendo permitida apenas uma validação parcial pelo insuficiente prazo de cinco dias e nenhuma certificação dos programas, os auditores não conseguem avaliar a real segurança do sistema.

Ao contrário do que dizem os técnicos do TSE e da Procomp, um código fraudulento poderia ser implantado em qualquer camada de programação e a política de desenvolvimento estanque, por si só, não garante a integridade do sistema uma vez que é possível desenvolver tal código numa das camadas mesmo sem informações completas sobre o resto do sistema. 

Na realidade, nem mesmo existem garantias de que a PDE é respeitada pois a proximidade das pessoas envolvidas e o longo tempo que participam do processo são fatos notórios.

Dentro destas condições, um auditor externo não pode afastar a hipótese da existência rotinas maliciosas nas urnas eletrônicas, rotinas estas que não seriam detectadas pela insipiente fiscalização permitida aos partidos.

Como disse Thompson, não se pode confiar em um sistema informatizado cujo código não tenha sido inspecionado em todas as suas minúcias e como disse Mercuri, sistemas eleitorais necessitam de critérios de segurança e de confiabilidade redobrados.

O TSE criou um sistema eleitoral que não pode ter sua apuração conferida ou recontada pois a urna eletrônica não emite comprovante impresso do voto. Ao impedir a análise profunda e completa dos seus programas pelos fiscais dos partidos políticos, o TSE diminui muito o nível de confiabilidade do sistema, reduzindo-o apenas à palavras dos técnicos envolvidos já que não se pode auditar a apuração nem pela análise dos programas nem pela recontagem dos votos.

Os técnicos envolvidos nos "garantiram" serem todos eles absolutamente honestos e está é a única garantia que o sistema eleitoral brasileiro oferece aos eleitores atualmente.