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.”