A Vulnerabilidade da Urna Eletrônica - Parte IV

Encerrando a nossa série sobre a vulnerabilidade das urnas eletrônicas, o quarto texto. Como sempre, assinado pelo leitor, amigo e analista de sistemas Bruno Nascimento.

Os artigos anteriores podem ser lidos aqui.

Passemos ao texto:

Parte IV – Até onde a criatividade pode ir?

"No post anterior explicamos o básico do processo de desenvolvimento e teste de sistemas para colocar que, tendo acesso ao código-fonte, é possível perpetrar uma fraude desde que o processo não o identifique. Uma vez identificado o problema, ele seria corrigido e retestado. Mas testes podem não encontrar os erros. Mas a criatividade humana não tem limites...

Podemos considerar uma infinidade de outros pontos para imaginar formas de se fraudar. Mas o processo eleitoral deve detectar a maioria das situações. Mas não existe sistema 100% seguro, exatamente pelo que colocamos anteriormente de que os testes provam de que não foram encontrados erros, mas não que não há erros. Uma possibilidade seria mudar o código do banco de dados utilizado na totalização dos votos. Mas, da mesma forma que o Sistema Operacional, seria algo facilmente identificável. Com o agravante de que o banco de dados registra todas as alterações efetuadas internamente.

Para ver outras maneiras necessárias para melhorar o processo eleitoral foi gerado um documento por gente com muito mais conhecimento que eu no assunto. O Relatório sobre o Sistema de Votação Eletrônica do Comitê Multidisciplinar Independente pode ser lido em http://www.brunazo.eng.br/voto-e/textos/RelatorioCMind.pdf. Recomendo. É leitura extensa, mas extremamente esclarecedora sobre as necessidades de melhoria de nosso processo de votação.

A criatividade pode imaginar diversas idéias de falhas a se aproveitar. Uma delas seria a ressurreição do “voto de cabresto”. Para isto, basta verificar a listagem dos votantes determinando o horário em que estes efetuaram a votação com os votos registrados. Mas o voto não é secreto? É. O processo não garante que o voto seja secreto? Garante. Mas como dito antes, o banco de dados registra todas as operações efetuadas neste. Com data e hora precisas de modo a se reconstruir as operações que o banco tenha feito em caso de problemas,  alguém que tenha conhecimento profundo de banco de dados pode determinar a ordem das operações de autorização de voto na urna e a ordem de votos e cruzando estas informações descobrir quem votou em quem. Pode não ser fraude, mas é quebra de sigilo que permite a manipulação de votos.

Outra maneira é que, como ainda não temos a biometria (programas que transformam características corporais como as digitais, a íris dos olhos em códigos numéricos) instalada em todas as urnas, é possível que uma pessoa vote por outra. Por isto, nesta eleição está se exigindo além do título de eleitor um documento com foto. Ainda assim, se tivermos todos os mesários coniventes de uma seção, estes podem inseminar a urna com votos de pessoas que, sabidamente, não estariam presentes... Mas concordamos que este tipo de fraude exige preparação maior, um esquema previamente planejado. Só não podemos dizer que é impossível.

O TSE para demonstrar a segurança de seu processo de identificação de fraudes, abriu para algumas equipes a possibilidade de testar a segurança do processo de detecção de fraudes da urna eletrônica. Dentre estes, houve um que ganhou prêmio do TSE por mostrar que ao utilizar um rádio muito próximo da urna eletrônica, as teclas provocam uma interferência, passível de identificação individual, detectando, portanto, em quem a pessoa votou. Para ver o resultado do teste veja o texto http://idgnow.uol.com.br/seguranca/2009/11/20/perito-quebra-sigilo-eleitoral-e-descobre-voto-de-eleitores-na-urna-eletronica/.  

O autor do teste praticado no TSE, em resposta, divulgou carta para o site que publicou a reportagem indicando “que a quebra do sigilo do voto seria impraticável nestas condições porque a proximidade tornaria o receptor de rádio visível ao eleitor e aos mesários”. E se alguém quiser que uma fraude seja detectada, com o objetivo de anular os votos de determinada seção onde um candidato seria o vencedor para que este tenha menos votos? Pois é, nada é impossível.

A única coisa que devemos evitar é a postura do HAL do filme de Stanley Kubrick, 2001 – uma Odisséia no Espaço. Uma vez descoberto que havia cometido um erro, ele “confundiu” seu propósito original (proteger a missão) com o secundário (não cometer erros) e decidiu eliminar aqueles que poderiam provar que o erro ocorreu. Erros existem, mas é importante que possamos saber onde possam ocorrer para melhorar o processo e evitá-los. A evolução é necessária e auditoria para a segurança do processo de votação também."

A Vulnerabilidade da Urna Eletrônica - Parte III

Mais um domingo, e a terceira parte de nossa série sobre as urnas eletrônicas e as possíveis fraudes eleitorais através delas. Uma vez mais, assinada pelo analista de sistemas Bruno Nascimento.

"Parte III – Desenvolvimento e Testes

No outro post tentamos entender sobre os sistemas operacionais, a linguagem de máquina e o processo de transformar o código gerado nesta através de compilação e interpretação. Além disso, falamos sobre as questões relativas ao código aberto e ao código fechado.

Esta parte da geração do é um pequeno ponto do processo de desenvolvimento de sistemas. O processo é muito maior, pois extende-se desde o levantamento dos requisitos (o que é necessário ter na codificação final dos sistemas), passando por um processo de análise e um desenho de como o sistema deve ficar (esquemas de entendimento comum dos profissionais envolvidos, mas não necessariamente com telas e código fonte gerados), a codificação, testes (para assegurar de que os requisitos estão sendo cumpridos) e a implementação propriamente dita.

Vamos entrar em mais detalhe no processo de desenvolvimento e no próprio processo da urna eletrônica. Primeiro naquilo que já explicamos: a compilação dos códigos. Entrando em mais detalhe no processo da urna eletrônica, http://www.tse.gov.br/internet/eleicoes/relatorio_unicamp.htm nos informa:

“A compilação da versão final do código-fonte é precedida de uma preparação pela equipe do TSE, quando são inseridas as chaves e as rotinas criptográficas.

Finalizada a preparação do código-fonte, é feita a compilação e a geração de códigos executáveis. Atendendo a requisitos legais, os códigos-fonte dos programas são colocados à disposição dos partidos políticos para análise. Encerrado o período de exposição, cópias do programa-fonte e dos executáveis são feitas em mídia permanente (CDs) e lacradas em envelopes que recebem as assinaturas dos representantes de partidos políticos. Esses CDs ficam armazenados sob a guarda do TSE.

A compilação do código-fonte no TSE é feita em máquina isolada da rede, instalada numa sala com acesso restrito, e seu uso é registrado em logs(...)”

Agora a grande questão: como saber que o código-fonte analisado pelos partidos é o mesmo lacrado no CD e que foi o mesmo a ser usado na compilação? Dentro do processo de desenvolvimento de sistemas existente em muitas empresas, armazenamos diversos códigos-fontes, para evitar que um erro introduzido num passo posterior possa impedir com que regeremos o executável original. Mas o que acontece é que mesmo um código-fonte igual, gerado em momentos diferentes pode gerar executáveis diferentes. Como?

Calma... O que acontece é que muitos sistemas operacionais registram dentro dos executáveis um código além da linguagem de máquina para identificação do momento da compilação. Para o processo da urna eletrônica há um processo mais sofisticado, mas a idéia é a mesma. O que significa? Que mesmo um código-fonte igual irá gerar controles diferentes dentro do momento em que foi gerado. Isto implica em segurança para a questão do momento em que o código-fonte foi gerado.

Se está tudo sob controle, então onde está o problema? Recapitulando, a pergunta essencial é: como saber que o código-fonte analisado pelos partidos é o mesmo lacrado no CD e que foi o mesmo a ser usado na compilação? Não há controle externo. Todo este controle é feito internamente no TSE. Não há nenhum controle externo neste caso.

Digamos que seja descoberto um bug (um erro) no programa após este ser passado aos partidos políticos. Este é corrigido, porém, pelo cronograma das eleições, se houver necessidade dos partidos reanalisarem o código, não haverá como cumprir o cronograma eleitoral e as eleições teriam de ser adiadas. Mas adiar as eleições por conta de um bug poria a confiança no programa seria quebrar a confiança no processo eleitoral, não? Pois é... Então, como o erro corrigido foi pequeno, decide-se não passar pelo processo completo. E quem garante que não pode ter entrado algum outro código que possa perpetrar uma fraude? Seria o processo de teste.

Como dissemos, o processo de teste verifica se o executável cumpre os requisitos iniciais. Só que testar um programa muito extenso considerando todas as variáveis possíveis torna-se temporal e economicamente inviável. Então escolhe-se as condições suficientes e necessárias para fazer o teste dos requisitos originais. O resultado é que podem haver condições não verificadas nos programas e que só são encontradas após o programa ser implementado. Testes não garantem que não haja erros, apenas que eles não foram mais encontrados. Em resumo, ainda assim, podem haver falhas. Fraudes, inclusive.

E quem poderia introduzir esta fraude? Qualquer pessoa com conhecimento de programação e que possa ter acesso ao código-fonte dos programas do TSE. A partir do 2º período, um estudante de informática tem conhecimento de lógica de programação suficiente para programar. A questão maior é o acesso aos códigos-fonte. Isto porque não estamos sequer cogitando da possibilidade de um dos requisitos do TSE ser exatamente perpetrar uma fraude e iludir os partidos políticos... Longe de mim pensar nisso.

Na próxima parte, vamos encerrar a série mostrando como se pode usar formas mais criativas de se tentar fraudar uma eleição. Inclusive uma que foi feita diante da equipe do TSE como prova de conceito."

A Vulnerabilidade da Urna Eletrônica - Parte II

Conforme dito no último domingo, hoje temos a segunda parte da série sobre a vulnerabilidade das urnas eletrônicas, assinada pelo analista de sistemas e ainda torcedor do Império Serrano Bruno Nascimento.

Parte II – Sistemas operacionais, Código aberto e fechado

Vimos no outro post um pouco sobre o funcionamento dos microprocessadores e da BIOS. Uma das atividades da BIOS é, terminadas suas verificações passar o controle da máquina para a execução de um programa. Normalmente, este programa tem a função de controlar a execução dos outros programas, controlar o sistema de entrada e saída. Este programa chama-se Sistema Operacional e, sem ele, o computador fica impossibilitado de executar outros programas ou seria muito difícil fazê-lo.  Difícil porque uma das funções do sistema operacional  é permitir que tarefas difíceis possam ser executadas de forma simples. Nem todo computador precisa de sistema operacional, pois possui informações e tratamento tão simples que dispensa este intermediário. Em compensação, os programas teriam que lidar com todas as operações que o sistema operacional verifica quanto com sua própria execução.

Na figura acima, exibimos algumas das funções que o sistema operacional faz, desde controlar o hardware, até controlar a execução dos aplicativos, distribuindo quanto tempo cada um pode executar, quando o sistema operacional é preparado para multiprocessamento (vários programas executando simultaneamente na mesma máquina). Se podemos ver que o sistema operacional controla a máquina, alterações e bugs (erros de programa) no sistema operacional podem fazer com que a máquina efetue coisas diversas da esperada. A maioria dos bugs de segurança divulgados do sistema operacional Windows, que usamos na maioria dos computadores pessoais, se referem exatamente a situações em que o sistema operacional acaba cedendo o controle indevidamente para outros programas. A urna eletrônica é um computador de arquitetura semelhante ao IBM-PC, como divulgado pelo próprio TSE. Estaria a urna sujeita a vírus e cavalos de tróia?

Muito difícil. Para tanto estes vírus e cavalos de tróia já teriam que estar presentes na cópia original controlada pelo TSE, ou seja, já enviadas a partir da fabricante do Sistema Operacional. Na versão antiga da urna eletrônica, o sistema Operacional era o VirtuOS da MicroBase, que na época era um sistema de código fechado. Hoje utiliza-se o sistema operacional Linux, de código aberto. Mas o que o código fechado ou aberto tem a ver com a segurança do processo da urna eletrônica?

O computador entende instruções que chamamos de linguagem de máquina. Para gerar estas instruções diretamente, existe uma linguagem denominada Assembly. O Assembly varia de máquina a máquina, de acordo com o conjunto de instruções oferecido pelo hardware. Mas se os programadores tivessem que conhecer o conjunto específico de instruções de cada máquina, os programadores teriam de ser extremamente específicos com relação à máquina. Haveria programadores de Pentium, programadores de Core Duo, de Athlon e outros mais, de acordo com o microprocessador da máquina. Ao invés disso, existem linguagens que chamamos de médio ou alto nível, dependendo da proximidade da linguagem com a linguagem da máquina, denominada de baixo nível. Assim, os programadores se especializam nestas linguagens e não nas máquinas em que têm de executar, permitindo maior flexibilidade no conhecimento de programação.

Para transformar estas linguagens de alto nível em linguagem de máquina, existem 2 formas: a compilação e a interpretação. A compilação é a transformação prévia para a linguagem de máquina do código gerado na linguagem de alto nível para que este seja executado também. A interpretação é a transformação no momento da execução da linguagem de alto nível ou de uma linguagem intermediária, gerada a partir do código gerado na linguagem de alto nível, no momento em que há a execução do programa. O código que gera o programa é denominado de código fonte ou fonte. Sistemas operacionais são programas também e são gerados desta forma. Para que rodem rapidamente na máquina, os programas têm que usar o processo de compilação. Existem linguagens interpretadas rápidas, mas no processo atual, elas ainda assim geram código intermediário para acelerar o processo. Só muito antigamente (há mais de 50 anos atrás) ou que necessitam muito se aproveitar de características da máquina são gerados em linguagem de máquina diretamente. Programas que têm seus fontes divulgados em conjunto com o programa a ser executado são chamados de código aberto. Programas que enviam apenas o código a ser executado ou o intermediário a ser interpretado são chamados de código fechado.

Sistemas de código aberto têm possibilidade de auditoria neste caso mais ampla, que sistemas de código fechado, sem entrar em questões de custo de manutenção ou suporte que não cabem aqui, exatamente por terem a possibilidade de análise do código fonte que originou o programa executável. Assim, fica mais difícil perpetrar uma fraude sem ser descoberta em um sistema qualquer. Deste modo, a auditoria do código fonte se torna de suma importância para a segurança da urna eletrônica e é mais fácil de ser efetuada em sistemas de código aberto, correto? Correto. Como dito, vírus e cavalos de tróia poderiam então ser detectados no código original já vindo de fábrica. Alterações que o programa efetue seriam detectadas e estaria configurada a fraude. Para que esta suceda, teria de ser inserida no TSE e aprovada por todos os especialistas dos partidos que auditassem esse código fonte. Mas estamos falando da auditoria do código fonte. Mas vimos que o código fonte não é necessariamente o que executa. Como garantir que o executável a ser código fonte seja o programa executado nas urnas eletrônicas? Entraremos então com mais detalhe no processo da urna eletrônica e no desenvolvimento de sistemas para verificar como é feita a transformação do código fonte em código executável.

A Vulnerabilidade da Urna Eletrônica - Parte I

O Ouro de Tolo apresenta a partir de hoje uma série especial. Assinada pelo analista de sistemas com mais de quinze anos de experiência Bruno Nascimento, meu amigo há duas décadas, vai mostrar que a urna eletrônica, pilar do nosso sistema de votação eletrônica, possui vulnerabilidades que podem ser exploradas por entidades políticas desonestas.

Serão quatro artigos, a serem publicados em dois domingos e duas quintas feiras. Recomendo atenção especial, pois é assunto muito sério e que tem influência direta em nossas vidas.

"Parte I – Microprocessadores e BIOS

Sou analista de sistemas e não sou especialista de segurança. Conversando com o Pedro ele se assustou com uma informação que passei, baseado no meu conhecimento da profissão e de desenvolvimento de sistemas. Eu disse que, com o contato interno correto, um estudante de 2º período da faculdade poderia efetuar uma fraude em uma urna eletrônica.

Como assim? Nosso processo eleitoral não é 100% seguro? Eu diria entre 95 a 99%. Só que em uma eleição muito disputada, este percentual poderia alterar a decisão final. Como a explicação envolve muito de explicação sobre computadores, códigos fonte, do processo de desenvolvimento de sistemas e do próprio processo eleitoral, a idéia aqui é apresentar um pouco de conhecimento de informática e de situações passíveis de exploração, com ou sem controle do processo eleitoral. A análise do processo das urnas eletrônicas, feita pela Unicamp em 2002, é um documento público e disponível no site do TSE em http://www.tse.gov.br/internet/eleicoes/relatorio_unicamp.htm. Deixemos claro que os próximos textos referem-se a opiniões minhas e que colocarei o conhecimento necessário para embasá-las. Cada um é responsável por sua interpretação e seus questionamentos. Como disse, não sou especialista em segurança, muito menos dono da verdade.

A urna eletrônica, segundo o relatório da Unicamp, “possui uma estrutura similar à de um computador IBM-PC”. O que seria uma estrutura similar a de um IBM-PC? Seria o que chamamos de máquina Von-Neumann. As principais características de uma máquina Von-Neumann são as seguintes:

·         A existência de 3 subsistemas: a CPU (Central Process Unit, ou Unidade Central de Processamento), a Memória Principal e o Sistema de Entrada e Saída (E/S ou I/O, de Input e Output).

·         A CPU se divide em 3 blocos principais: a Unidade de Controle, a Unidade Lógico-Aritmética (ALU – Arithmetical Logical Unit)  e Registradores, incluindo aí um registrador da posição da última instrução executada (PC – Program Counter).

·         O programa é armazenado na memória principal.

·         A execução de instruções pelo computador é seqüencial, uma após a outra.

·         E há um único caminho entre a memória principal e a Unidade de Controle

·         A execução de comandos na máquina é comandada pelos ciclos de máquina, onde se busca a próxima instrução de máquina (através do que está registrado no PC – Program Counter) e a execução da mesma através da Unidade de Controle e da ALU que realiza as operações matemáticas de somar, subtrair, multiplicar e dividir, além de realizar as operações de ponto-flutuante, para os números fracionários.

Computadores, apesar de executar várias operações que não conseguiríamos executar tão rapidamente, são máquinas burras.  A CPU é o que chamamos  ao microprocessador, o coração da máquina. Então quando falamos de Pentium, Athlon, Core Duo, Core Quad, falamos do microprocessador. Os microprocessadores além do acesso à memória principal, chamada também de memória RAM (Random Acesss Memory – Memória de Acesso Aleatório) possui também uma memória denominada ROM (Read Only Memory). Porquê o computador precisa destes 2 tipos de memória? Porque a memória RAM, uma vez que o computador é desligado perde todo seu conteúdo. Então para executar as primeiras instruções e verificar todo o computador é necessário ter um conjunto de instruções básicas que serão o primeiro conjunto de instruções a serem executadas pelo computador ao ser ligado. Estas instruções armazenadas em memória ROM são no IBM-PC chamadas de BIOS (Basic Input and Output System – Sistema Básico de Entrada e Saída).

Aqui entram os primeiros pontos que poderiam ser aproveitados. E se alguém substituísse a BIOS existente nas urnas por uma outra que permitisse manipular resultados? É uma situação em que a própria verificação da urna verificaria e capturaria a fraude facilmente. A BIOS já vem de fábrica com a programação destas prontas e têm uma codificação prevista controlada. Assim alterações nesta seriam identificáveis pouco após o momento em que o computador fosse ligado. Neste ponto, a mudança seria detectada. Até aqui, dificilmente haveria fraude sem conhecimento de ninguém, pois as instruções aqui necessárias são tão básicas para o funcionamento do computador que a fraude ficaria clara em quaisquer testes de verificação e mesmo nos testes de programa. Só se esta viesse de fábrica ruim, mas normalmente tal situação seria detectada com antecedência o suficiente para que não houvesse impacto na eleição.

Seguiremos na próxima parte explicando mais componentes de programa que estariam envolvidos no funcionamento de um computador, o Sistema Operacional e os programas executáveis."