Vulnerabilidades no software da urna eletr onica brasileira

Diego F. Aranha1 , Marcelo Monte Karam2 , Andr e de Miranda2 , Felipe Scarel2

1

Departamento de Ci encia da Computa c ao Universidade de Bras lia (CIC/UnB) 2 Centro de Inform atica Universidade de Bras lia (CPD/UnB)

Vers ao 1.0.2 31 de Mar co de 2013

Coordenador da equipe.

Resumo Este relat orio apresenta uma an alise de seguran ca do software da urna eletr onica brasileira baseada na experi encia dos autores enquanto participantes da 2a edi c ao dos Testes P ublicos de Seguran ca do Sistema Eletr onico de Vota c ao organizados pelo Tribunal Superior Eleitoral (TSE). Durante o evento, foram detectadas vulnerabilidades no software que permitiram a recupera c ao em ordem dos votos computados. Apresentamos cen arios onde as vulnerabilidades permitem a possibilidade de fraude eleitoral e sugest oes para se restaurar a seguran ca dos mecanismos afetados. Tamb em s ao apontadas outras fragilidades no software e nas pr aticas utilizadas para confec c ao do mesmo. Em particular, este relat orio versa sobre os principais problemas de projeto e/ou implementa c ao de mecanismos de seguran ca detectados no software da urna eletr onica: Prote c ao inadequada do sigilo do voto: os votos s ao armazenados fora de ordem, mas e trivial recuper a-los em ordem a partir unicamente dos produtos p ublicos de uma elei c ao e conhecimento supercial do c odigo-fonte, tamb em de acesso p ublico aos partidos pol ticos; Cifra c ao inadequada: a mesma chave criptogr aca e utilizada para cifrar as m dias de todas as urnas eletr onicas. Utilizando a analogia cl assica de um cadeado como abstra c ao de t ecnica criptogr aca, isto e equivalente a proteger meio milh ao de cadeados com uma mesma chave, visto ser este o n umero aproximado de equipamentos em opera c ao. Al em disso, a chave que decifra todas as m dias e armazenada ` as claras na por c ao decifrada das m dias. Utilizando a mesma analogia, isto equivale a esconder a chave do cadeado embaixo do tapete e conar no segredo dessa localiza c ao como fonte de seguran ca; Utiliza c ao de algoritmos obsoletos: a fun c ao de resumo criptogr aco utilizada n ao mais oferece a seguran ca esperada para aplica c ao em verica c ao de integridade. Esta aplica c ao espec ca da fun c ao escolhida n ao e mais recomendada h a pelo menos 6 anos; Formula c ao equivocada do modelo de atacante: h a enfase demasiada no projeto de mecanismos resistentes apenas a atacantes externos, quando agentes internos representam risco muito maior; Processo de desenvolvimento defeituoso: pr aticas inseguras permitem a inser c ao acidental ou maliciosa de vulnerabilidades de software, claramente atestando que o processo de desenvolvimento adotado pelo TSE e imaturo do ponto de vista de seguran ca;

 Verica c ao insuciente de integridade: o software da urna eletr onica verica sua pr opria integridade durante o processo de inicializa c ao, mas toda a informa c ao necess aria para subverter esse mecanismo encontra-se armazenada nas pr oprias urnas eletr onicas, com diculdades distintas para um ataque, dependendo da presen ca do m odulo de seguran ca em hardware. Em urnas sem este recurso, o problema de verica c ao e reduzido a si pr oprio, sem fonte externa de conan ca. Nesse caso, software auto-veric avel [1] por assinatura digital equivale a conar a autenticidade de uma assinatura de punho em um documento apenas ao testemunho do pr oprio autor, que, as sim, pode se passar por quem quiser. E importante ressaltar ainda que uma assinatura aut entica apenas atesta o processamento do conte udo assinado em algum ponto no tempo e espa co no qual tamb em estava presente a chave de assinatura. Mesmo que os mecanismos de verica c ao de integridade n ao sejam contornados e funcionem a contento, ainda n ao h a qualquer garantia de que o conte udo do documento e de fato o desejado, visto que no caso o mesmo (software ) tem extens ao da ordem de milh oes de linhas (de c odigo). Caso o software possua vulnerabilidades (como as descritas neste documento), a verica c ao de integridade (quando n ao subvertida) tem o efeito colateral de garantir que as mesmas vulnerabilidades estar ao presentes em todas as urnas. A vers ao do c odigo observada pelos autores apresentava ainda como desativada a verica c ao de integridade de parte do software contido na urna, evidenciando as limita c oes intr nsecas da t ecnica. Mais detalhes a respeito dos problemas acima s ao fornecidos no decorrer deste relat orio, mas pode-se observar de antem ao que v arios dos recursos implementados no software da urna eletr onica n ao representam mecanismos de seguran ca, mas apenas de ofusca c ao, n ao resistindo a colaboradores internos ou atacantes persistentes. Como v arios dos problemas encontrados resultam de falhas arquiteturais ou premissas inadequadas de projeto, e improv avel que a interven c ao pontual em algumas dessas quest oes resolva as causas fun imprescind damentais para a sua ocorr encia. E vel que se execute revis ao cr tica completa dos processos de desenvolvimento de software para que se estabele cam boas pr aticas que tenham condi c oes de evitar que novas vulnerabilidades sejam inseridas acidentalmente ou intencionalmente por agentes maliciosos internos ou externos. Como o modelo de urna eletr onica adotado no Brasil depende exclusivamente da integridade do software para se atingir integridade dos resultados, os problemas discutidos aqui adquirem um car ater cr tico e exigem urg encia na introdu c ao de mecanismos que permitam a auditabilidade de resultados independente do software. Apenas com uma revis ao de pr aticas e instala c ao de metodologia cient ca para avalia c ao cont nua do sistema, e poss vel que o software da urna eletr onica satisfa ca requisitos m nimos e plaus veis de seguran ca e transpar encia. 2

Sum ario
1 Introdu c ao 1.1 Objetivo deste relat orio . . 1.2 Vis ao supercial do sistema 1.3 Organiza c ao do documento 1.4 Agradecimentos . . . . . . . 2 Testes P ublicos de 2.1 Formato . . . . 2.2 Objetivos . . . 2.3 Metodologia . . 2.4 Resultados . . . 2.5 Pontua c ao . . . 2.6 Aprimoramento 3 3 4 5 5 6 6 7 7 8 9 10 13 13 15 15 17 18 19

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

Seguran ca . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

3 Vulnerabilidades 3.1 Registro Digital do Voto (RDV) . 3.2 Hip otese . . . . . . . . . . . . . . 3.3 Projeto e implementa c ao . . . . . 3.4 Ataques . . . . . . . . . . . . . . 3.5 Consequ encias . . . . . . . . . . 3.6 Corre c oes . . . . . . . . . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

4 Fragilidades 21 4.1 No software . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21 4.1.1 Prote c ao inadequada ao sigilo do voto . . . . . . . . . 21 4.1.2 Fonte inadequada de entropia . . . . . . . . . . . . . . 22 4.1.3 Verica c ao insuciente de integridade . . . . . . . . . 23 4.1.4 Compartilhamento de chaves criptogr acas . . . . . . 24 4.1.5 Presen ca de chaves no c odigo-fonte . . . . . . . . . . . 25 4.1.6 Cifra c ao fora dos limites de opera c ao . . . . . . . . . . 26 4.1.7 Escolha inadequada de algoritmos . . . . . . . . . . . 26 4.1.8 Implementa c oes repetidas de primitivas criptogr acas 27 4.2 No processo de desenvolvimento . . . . . . . . . . . . . . . . . 27

4.2.1 4.2.2 4.2.3 4.2.4 4.2.5 4.2.6 4.2.7 4.2.8 4.2.9

Complexidade acentuada . . . . . . . . . . . . . . . Auditoria externa insuciente . . . . . . . . . . . . . Aus encia de an alise est atica de c odigo . . . . . . . . Formula c ao equivocada de modelo de atacante . . . Aus encia de exerc cios internos . . . . . . . . . . . . Falta de treinamento formal . . . . . . . . . . . . . . Disponibiliza c ao de dados cr ticos aos investigadores Ignor ancia da literatura relevante . . . . . . . . . . . Falsa sensa ca o de seguran ca . . . . . . . . . . . . . .

. . . . . . . . .

27 28 28 29 29 30 30 30 31 32

5 Conclus oes e perspectivas

Cap tulo 1

Introdu c ao
O Brasil vem adotando crescente informatiza c ao das suas elei c oes desde o ano de 1996, culminando no cen ario atual onde se vislumbra a instala c ao de dispositivos de identica c ao biom etrica em todos os equipamentos de vota c ao. Marcos importantes na hist oria da iniciativa foram a realiza c ao das primeiras elei c oes puramente eletr onicas em 2000, a transfer encia da responsabilidade exclusiva do desenvolvimento de software para o TSE a partir de 2006 e a ado c ao de um sistema operacional de c odigo aberto (GNU/Linux) a partir de 2008. Ao se estabilizar os componentes b asicos do sistema eletr onico de vota c ao e procedimentos relacionados, entende-se que a preocupa c ao direta deve ser focada no incremento da seguran ca para que seja poss vel executar elei c oes con aveis que conservem absolutamente o sigilo e a integridade das escolhas denidas pelo eleitor. Uma iniciativa louv avel nesta dire c ao e a realiza c ao desde 2009 de testes peri odicos e p ublicos de seguran ca que permitem, ainda que com algumas restri c oes indesej aveis, a equipes de especialistas da academia e ind ustria avaliar de forma independente a seguran ca dos mecanismos adotados pelo sistema eletr onico de vota c ao.

1.1

Objetivo deste relat orio

O objetivo geral do relat orio e formalizar as observa c oes realizadas pela a equipe de autores quando de sua participa c ao na 2 edi c ao dos Testes P ublicos de Seguran ca organizados pelo Tribunal Superior Eleitoral (TSE). Os relat orios que foram produzidos em conjunto com o Tribunal, e por ele publicados a t tulo de resultados, carecem de informa c oes sobre outros problemas encontrados que n ao se relacionam diretamente aos planos de teste formulados e executados pela equipe. Assim, a motiva c ao principal para apresentar este relat orio e delinear as limita c oes do sistema eletr onico de vota c ao adotado no Brasil e contribuir para a evolu c ao do seu processo de seguran ca. Seguindo pol ticas padronizadas de divulga c ao de vulnerabilidades utiliza-

das na area de Seguran ca da Informa c ao, s ao apresentadas aqui descri c oes sucientes das fragilidades e problemas de processo encontrados, acompanhadas de m ultiplas sugest oes de corre c ao. Desta forma, a parte interessada encontra-se em posi c ao adequada para implementar contramedidas efetivas. importante salientar ainda que o presente relat E orio trata apenas do software da urna eletr onica, n ao se manifestado a respeito dos aspectos f sicos ou do hardware do equipamento. Esta decis ao foi tomada respeitandose os campos de especialidade dos autores. Ainda assim, tamb em vale ressaltar que as observa c oes coletadas referem-se apenas a uma pequena ainda que estrat egica fra c ao do c odigo-fonte do software, exclu dos tamb em os componentes de software que constituem o sistema de vota c ao do qual a urna faz parte, visto que as regras do evento, e o limite de tempo na participa c ao dos investigadores, n ao permitiram uma avalia c ao mais detalhada. Por m, o conte udo e as conclus oes aqui apresentados s ao de inteira responsabilidade dos autores e n ao representam de forma alguma a opini ao da Universidade de Bras lia ou quaisquer outros org aos aos quais eventualmente os autores prestaram ou venham a prestar servi cos.

1.2

Vis ao supercial do sistema

A urna eletr onica brasileira pode ser classicada como um modelo do tipo DRE (Direct Recording Electronic ), sem impress ao do voto. Em termos gerais, uma elei c ao utilizando o sistema eletr onico de vota c ao emprega as seguintes etapas de prepara c ao: 1. Lacra c ao dos componentes de software e produ c ao de m dias de carga; 2. Instala c ao do software nas urnas eletr onicas com m dias de carga; 3. Distribui c ao das urnas ` as respectivas se c oes eleitorais. No dia determinado para realiza c ao das elei c oes, cada urna eletr onica deve executar uma sequ encia bem-denida de procedimentos: 1. Impress ao da zer esima, documento ocial que supostamente atesta que nenhum voto foi previamente computado para qualquer candidato; 2. Abertura da vota c ao pelo mes ario respons avel; 3. Acesso dos eleitores ` a urna eletr onica para que suas escolhas sejam inseridas; 4. Encerramento da vota ca o, realizada tamb em pelo mes ario respons avel; 5. Emiss ao de vias do Boletim de Urna (BU) em papel, contendo a totaliza c ao parcial dos candidatos; 4

6. Grava c ao autenticada dos produtos p ublicos de vota c ao, abrangendo principalmente as vers oes digitais do BU, arquivo de registro cronol ogico de eventos (LOG) e Registro Digital do Voto (RDV); 7. Rompimento do lacre e retirada pelo mes ario da M dia de Resultados (MR) contendo os produtos p ublicos da elei c ao; 8. Transmiss ao dos produtos p ublicos para o totalizador a partir de rede privada de comunica c ao. O papel do totalizador consiste em combinar todas as totaliza c oes parciais no resultado declarado ocial das elei c oes.

1.3

Organiza c ao do documento

O documento obedece a estrutura a seguir. O Cap tulo 2 descreve brevemente o formato do evento e resultados obtidos nos Testes P ublicos de Seguran ca. O Cap tulo 3 apresenta em detalhes a sequ encia de vulnerabilidades que permitiu aos autores executar um plano de testes que terminou por derrotar o u nico mecanismo de seguran ca utilizado pela urna eletr onica para proteger o sigilo do voto. Tambem s ao descritas alternativas para corre c ao das vulnerabilidades e cen arios realistas que amea cam o car ater secreto do voto, caso as vulnerabilidades n ao sejam corrigidas. O Cap tulo 4 apresenta outro conjunto de fragilidades detectadas no software e no processo de desenvolvimento utilizado pelo TSE. Finalmente, o Cap tulo 5 apresenta as conclus oes e sugest oes para que se incrementem a transpar encia e auditabilidade do sistema eletr onico de vota c ao.

1.4

Agradecimentos

Os autores gostariam de agradecer ao colega Prof. Pedro Rezende da Universidade de Bras lia, ao Prof. Dr. Jeroen van de Graaf da Universidade Federal de Minas Gerais, ao Prof. Dr. Paulo S. L. M. Barreto da Universidade de S ao Paulo e ao Prof. Dr. Francisco Rodr guez-Henr quez do Centro de investigaci on y de Estudios Avanzados del Instituto Polit ecnico Nacional de M exico por discuss oes relevantes durante a prepara c ao deste documento. Agradecimentos especiais para o Prof. Dr. J. Alex Halderman da Universidade do Michigan por seus coment arios extremamente abrangentes em uma vers ao preliminar deste documento.

Cap tulo 2

Testes P ublicos de Seguran ca

Formalmente, o evento teve in cio com a inscri c ao das equipes mediante chamada p ublica de participa c ao e protocola c ao de documenta c ao correspondente no setor respons avel dentro do TSE. Segundo consta no edital de abertura [2], apenas as equipes com inscri c oes previamente aprovadas pelo Tribunal teriam oportunidade de participar das atividades. A grande novidade da 2a edi c ao do evento em rela c ao ` a 1a foi a possibilidade de se examinar o c odigo-fonte do software de vota c ao. A 1a edi c ao do evento consistiu exclusivamente em testes de caixa preta.

2.1

Formato

As 9 equipes compostas por 24 investigadores com inscri c oes aprovadas participaram das duas etapas que compreenderam intervalos de 3 dias, cada um com 10 horas de atividades: (i) fase de prepara c ao, entre os dias 6 e 8 de Mar co de 2012, quando as equipes puderam examinar o c odigo-fonte do software e solicitar esclarecimentos t ecnicos, em busca de formular hip oteses e planos de teste para avalia c ao da qualidade dos mecanismos de seguran ca implementados na urna eletr onica; (ii) fase de testes, entre os dias 20 e 22 de Mar co de 2012, quando as equipes n ao mais teriam acesso ao c odigo-fonte e poderiam executar os planos de teste com a nalidade de validar hip oteses e obter conclus oes e resultados. Mesmo que os autores n ao tenham sentido a necessidade de fazer uso desse recurso, e importante registrar que a restri c ao de acesso ao c odigo-fonte foi relaxada no segundo dia da fase de testes. As atividades concretas da 2a edi c ao dos Testes P ublicos de Seguran ca tiveram in cio no dia 6 de Mar co de 2012, com a realiza c ao de uma palestra de abertura [3] onde foram apresentados o formato do evento e uma vis ao supercial dos procedimentos para realiza c ao de elei c oes e uma descri c ao mais detalhada dos mecanismos de seguran ca implementados na urna eletr onica. O objetivo da palestra foi nivelar o conhecimento dos participantes a respeito do sistema. A equipe de autores, identicada como Grupo 1, assistiu

atentamente ` a palestra de abertura para se familiarizar com caracter sticas t ecnicas do sistema e come car a detectar pontos de ataque promissores. No per odo compreendido entre as duas etapas, foi solicitado que as equipes protocolassem tamb em os planos de teste elaborados a partir das informa c oes coletadas na fase de prepara c ao, visto que apenas as metodologias aprovadas pela Comiss ao Disciplinadora do evento poderiam ser colocadas em pr atica posteriormente na fase de testes.

2.2

Objetivos

O edital de abertura ainda discriminou os objetivos das equipes em duas classes bastante distintas de testes, aqui copiadas por completo [2]: Falha : evento em que se observa que um sistema violou sua especica c ao por ter entrado em um estado inconsistente e imprevisto ocasionado por uma imperfei c ao (defeito) em um software ou hardware impedindo seu bom funcionamento, sem interferir na destina c ao e/ou anonimato dos votos dos eleitores; Fraude : ato intencional que tenha alterado informa c oes e/ou causado danos, interferindo na destina c ao e/ou anonimato dos votos, e que tenha sido efetuado de forma a n ao deixar vest gios percept veis. Pode-se interpretar a primeira classe como um ataque de nega c ao de servi co, onde o atacante tem interesse em impossibilitar a utiliza c ao do equipamento pelos eleitores. A segunda classe captura os ataques com potencial de causar fraude eleitoral. A equipe elaborou e submeteu dois planos de teste, intitulados Tentativa n ao-rastre avel de quebra do sigilo de vota c ao [4] e Tentativa n aorastre avel de fraude no resultado de vota c ao [5], ambos claramente objetivando satisfazer as exig encias para uma tentativa de fraude em elei c ao simulada realizada seguindo procedimentos ociais. Dado o tempo ex guo, apenas o primeiro plano de testes foi executado por completo.

2.3

Metodologia

A metodologia executada pelo plano de testes exigiu a divis ao da equipe em duas partes, aqui identicadas por A e B, que alternavam sua presen ca no ambiente de testes para impedir qualquer tipo de comunica c ao. Os experimentos seguiram os procedimentos a seguir: 1. Gera c ao pelo TSE de uma lista secreta de votos ct cios abrangendo os cargos de vereador e prefeito; 2. Entrega da lista secreta de votos para a parte A da equipe; 7

3. Carga da urna com cart ao fornecido pelo TSE e impress ao da zer esima; 4. Inser c ao dos votos na urna eletr onica, seguindo a ordem da lista e efetuada pela parte A da equipe sob monitora c ao de funcion arios do TSE; 5. Rompimento do lacre e entrega da M dia de Resultados (MR) para a parte B da equipe; 6. Execu c ao de um programa de an alise que analisa o Registro Digital do Voto armazenado na MR e produz uma lista de votos em ordem que supostamente representa os votos inseridos na urna; 7. Compara c ao da lista mantida secreta para a parte B com a lista de votos produzida pelo programa de an alise. O crit erio de sucesso para a metodologia e naturalmente a correspond encia entre as duas listas. Observe que, dentro do ambiente de testes, houve a necessidade de se romper o lacre da MR para se completar a simula c ao, visto que esta era a u nica forma de se obter o RDV correspondente ` a vota c ao simulada. Em elei c oes reais, o RDV e de acesso p ublico garantido por lei [6]. Naturalmente, tamb em houve a necessidade de se dispor de acesso f sico ` a urna para inserir os votos contidos na lista fornecida pelo TSE, o que foi feito conforme o protocolo descrito acima.

2.4

Resultados

Como consta em relat orio nal da equipe escrito em conjunto com o TSE [4], a metodologia de avalia c ao da qualidade dos mecanismos de prote c ao do sigilo do voto obteve sucesso absoluto em recuperar em ordem os votos de elei c oes simuladas com 10, 16, 21 e 475 eleitores (20, 32, 42 e 950 votos, respectivamente, j a que cada eleitor votava para os cargos de Prefeito e Vereador). Esta u ltima foi realizada para cumprir exig encia do TSE em reproduzir a prova de conceito j a apresentada para elei c oes pequenas com uma massa de dados realista, que inclusive reproduz a m edia de comparecimento das elei c oes de 2010 no universo de 580 eleitores ct cios utilizado como conjunto de treinamento do evento. Como a metodologia executada consistia apenas em an alise dos produtos p ublicos de vota c ao, n ao foi necess aria nenhuma altera c ao em qualquer componente da urna eletr onica ou qualquer invas ao do per metro f sico do equipamento. Por esse motivo, a metodologia e essencialmente n ao-rastre avel e n ao deixa nenhum vest gio percept vel. Registrar os votos inseridos pelo eleitor de forma desordenada e um procedimento cr tico para se proteger o sigilo do voto. Fica claro, portanto, que a metodologia da equipe permitiu derrotar o u nico mecanismo utilizado 8

pela urna eletr onica para proteger o sigilo do voto. Vale salientar que n ao foi poss vel, entretanto, obter uma rela c ao em ordem das identidades dos eleitores a partir unicamente dos produtos p ublicos de vota c ao, existindo a necessidade de obten c ao dessa informa c ao por meios externos para que fosse poss vel efetuar a correspond encia direta e exata entre a identidade do eleitor e sua escolha de candidatos. At e onde se p ode vericar, os produtos p ublicos de vota c ao armazenam apenas a identica c ao dos eleitores faltosos em ordem lexicogr aca. Discutimos no pr oximo cap tulo como a possibilidade de recupera c ao dos votos em ordem pode ser utilizada para se montar fraudes eleitorais em cen arios realistas. N ao houve tempo suciente para executar o segundo plano de testes, que objetivava avaliar os mecanismos de seguran ca que protegem a integridade de uma vota c ao. A prioridade para o primeiro plano de testes foi conferida por sua simplicidade e pela quase completa independ encia de sua execu c ao de qualquer colabora c ao signicativa por parte do TSE. Efetuar ataques ` a integridade dos resultados exige que no m nimo se verique que os resultados fraudados ainda s ao detectados como aut enticos pelos mecanismos de auditoria existentes.

2.5

Pontua c ao

Foram estabelecidos crit erios objetivos de pontua c ao e uma f ormula para compara c ao objetiva do desempenho das diversas equipes [7]. Sem justicativas detalhadas e mesmo atingindo absoluto sucesso no teste que se prop os a executar, o plano de testes da equipe recebeu a pontua c ao nma de 0,0313 em uma escala de 0 a 400 pontos [8]. Os crit erios para a penaliza c ao da pontua c ao da equipe s ao absolutamente discut veis. N ao cou claro, por exemplo, por que foram aplicadas penalidades causadas por pontos de interven c ao que s o existiam no ambiente simulado dos testes e que n ao eram obst aculos a uma instancia c ao do ataque em ambiente real. A Comiss ao de Avalia c ao entendeu como quatro os pontos de interven c ao: acesso f sico ` a urna, lacre e m dias e visualiza c ao do c odigo-fonte. Seria imposs vel simular qualquer elei c ao sem nenhum acesso f sico ` a urna e tamb em seria imposs vel analisar os produtos p ublicos de vota c ao simulada sem o rompimento do lacre que protege a M dia de Resultados. O ataque n ao exigiu acesso ao equipamento al em do acesso permitido ao eleitor durante o processo de vota c ao ou ao mes ario durante o encerramento da sess ao. Vale ressaltar que os partidos pol ticos recebem o conte udo da M dia de Resultados sem a necessidade de qualquer acesso f sico a uma determinada urna eletr onica. Al em disso, parece incoerente penalizar a equipe por ter visualizado o c odigo-fonte do software, quando o objetivo do evento era justamente avaliar a qualidade dos mecanismos de seguran ca implementados neste. Por m, a equipe continua sem entender o porqu e de sua metodologia ter sido classicada como

uma tentativa de causar falha ao inv es de fraude na elei c ao simulada, visto que em nenhum momento qualquer dos equipamentos utilizados apresentou qualquer defeito. Ainda assim, a equipe consagrou-se como vencedora do evento por obter os resultados mais contundentes e oferecer a contribui c ao melhor qualicada para aprimoramento da seguran ca do sistema eletr onico de vota c ao. Conclu mos com duas hip oteses v alidas para a pontua c ao nma: ou a Comiss ao Avaliadora apontada pelo TSE n ao entendeu a seriedade das consequ encias provocadas pela vulnerabilidade encontrada, ou houve uma tentativa deliberada de descaracterizar e minimizar o ocorrido. Ambas as hip oteses s ao absolutamente preocupantes.

2.6

Aprimoramento

A participa c ao da equipe nos Testes P ublicos de Seguran ca permitiu ainda coletar algumas sugest oes pontuais de aperfei coamento do evento em si: Minimiza c ao da interven c ao do pessoal de apoio: ainda que seja compreens vel a necessidade de se monitorar os investigadores durante a execu c ao dos testes, a falta de privacidade e as interven c oes constantes terminaram por causar desconforto ` a equipe; Redu c ao da burocracia: novamente, ainda que seja perfeitamente compreens vel a necessidade de se registrar todos os procedimentos efetuados pelos investigadores, percebeu-se que satisfazer os requisitos burocr aticos exigidos consumiu tempo que poderia ser dedicado ` a execu c ao de planos de testes adicionais; Amplia c ao do tempo: um per odo de 3 dias e absolutamente insuciente para se analisar uma por c ao signicativa do c odigo-fonte da urna eletr onica, que em seu total possui milh oes de linhas de c odigo. Como em dispotivos de miss ao cr tica todo o c odigo termina por se congurar c odigo de seguran ca, visto que uma vulnerabilidade em um trecho inofensivo de c odigo pode disparar um ataque a um trecho cr tico de c odigo, e desej avel que a dura c ao do evento seja maximizada; Amplia c ao da capacidade de exame do c odigo-fonte: foi dedicada uma sala lacrada espec ca para o exame do c odigo-fonte. Visto que a sala foi equipada com apenas 4 computadores, a falta de capacidade terminou por limitar o tempo de exposi c ao do c odigo-fonte. Em particular, a equipe dos autores s o obteve acesso ao c odigo-fonte as 11:00 da manh ` a do segundo dia da fase de prepara c ao, pois uma das equipes obteve acesso exclusivo ` a sala no primeiro dia. No total, a equipe dispendiou apenas 5 horas da fase de prepara c ao investigando trechos estrat egicos do c odigo-fonte da urna. A disponibiliza c ao de 10

ferramentas simples de processamento de texto (grep, vi, cat, etc) no ambiente de exame de uma base de c odigo de tal tamanho e essencial para a utilidade dos testes e deve ser conservada; Amplia c ao do escopo dos testes: o foco do evento foi exclusivamente nos mecanismos de seguran ca implementandos na urna eletr onica. A justicativa fornecida para tal pode parecer razo avel ` a primeira vista, ao argumentar que qualquer entidade pode fazer uma totaliza c ao independente dos resultados, na medida que todos os BUs s ao publicados na Internet. Desta forma, qualquer ataque ao sistema totalizador no m aximo atrasaria a apura c ao e divulga c ao posterior dos resultados. Entretanto, na opini ao da equipe, ataques com sucesso ao totalizador podem for car ambiguidade ou altera c ao dos resultados divulgados. Estes podem ser detectados e neutralizados posteriormente apenas em situa c oes onde as respectivas garantias, de que os resultados corretos de cada urna correspondem aos que s ao publicados na Internet, estejam acess veis a candidatos potencialmente prejudicados. O sucesso de um ataque dessa natureza pode ainda comprometer a imagem e reputa c ao da autoridade eleitoral ou at e mesmo qual o resultado correto das elei c oes; Aprimoramento dos crit erios de pontua c ao: a f ormula utilizada para avaliar o desempenho das equipes foi mal-concebida e tinha foco demasiado em aplicar penalidades. Al em disso, a aprecia c ao ocial e irrecorr vel por parte do Comit e de Avalia c ao [8] n ao justicou qualquer de suas decis oes, limitando-se apenas a listar os pontos de interven c ao e a pontua c ao nal; Altera c ao da natureza do evento: o formato atual de competi c ao incentiva as equipes a n ao compartilhar informa c oes e a utilizar exclusivamente uma m etrica de custo/benef cio. Ou seja, restrige o escopo a decidir qual das vulnerabilidades encontradas permite modelar um ataque executado na menor quantidade de tempo. Desta forma, v arias metodologias sosticadas perdem prioridade por exigir maior dedica c ao. Mesmo que essas caracter sticas modelem uma parcela dos potenciais atacantes, conclui-se que uma avalia c ao mais criteriosa e colaborativa dos mecanismos de seguran ca permite a modelagem de atacantes bem-informados e munidos de recursos para executar ataques persistentes. A avalia c ao completa e cuidadosa do software da urna eletr onica requer enorme esfor co e muito tempo de dedica c ao. Sem a possibilidade de se efetuar testes extensos e sem qualquer tipo de restri c ao, seguindo metodologia cient ca, n ao e poss vel armar que o formato atual do evento colabora signicativamente para o incremento da seguran ca da urna eletr onica. Permite 11

apenas encontrar vulnerabilidades pontuais que permitam ataques de f acil execu c ao, mas com efeitos limitados.

12

Cap tulo 3

Vulnerabilidades
Neste Cap tulo, e descrita a sequ encia de vulnerabilidades que permitiu ` a equipe de autores recuperar os votos em ordem de v arias elei c oes simuladas, uma das quais utilizando um conjunto de dados de tamanho realista.

3.1

Registro Digital do Voto (RDV)

Desde a promulga c ao da lei eleitoral 9.504/97 [9], que ocializou a vota c ao eletr onica com o modelo atual de urna DRE, o voto impresso veric avel pelo eleitor foi institu do no Brasil pela primeira vez em 2002, atrav es da lei 10.408/02 [10]. A nalidade desse recurso e permitir para todos os eleitores, agentes com maior interesse no processo democr atico de vota c ao, a possibilidade de verica c ao independente do seu voto. Sem verica c ao independente, a conan ca e depositada apenas na habilidade dos partidos pol ticos em scalizar a confec c ao dos programas e na boa f e dos t ecnicos do TSE em produzir software correto [11, p agina 23]. A proposta do voto impresso sugere produzir uma vers ao materializada do voto, que pode ser conferida pelo eleitor, sem, no entanto, permitir que o pr oprio comprove suas escolhas para uma parte interessada qualquer. Ap os alega c oes de diculdades operacionais e alto custo por parte do TSE, o voto impresso terminou descontinuado pela lei 10.740 em 2003 [6]. Em seu lugar, adotou-se um substituto puramente digital. O Registro Digital do Voto, ou RDV, e uma tabela separada por cargos em disputa eleitoral que armazena desordenadamente os votos propriamente ditos inseridos pelos eleitores na urna eletr onica. O objetivo desse embaralhamento dos votos e desassociar a ordem em que os votos foram inseridos da ordem em que foram armazenados. O RDV foi introduzido no lugar do voto impresso para supostamente permitir a mesma capacidade de verica c ao independente dos resultados da urna. Por essa raz ao, e um documento p ublico disponibilizado para os partidos ap os as elei c oes. Entretanto, enquanto o voto impresso permite

13

de fato a verica c ao independente dos votos computados eletronicamente, o RDV e produzido pelo mesmo componente de software que produz o Boletim de Urna (BU) contendo os totais de cada candidato computados pela urna. Desta forma, qualquer ataque que comprometa a integridade do BU pode tamb em comprometer o RDV. Pode-se concluir, portanto, que o RDV n ao serve a nenhum prop osito pr atico, al em de permitir a viola c ao do sigilo do voto caso seja projetado e implementado de forma insegura. A Figura 3.1 apresenta um RDV ct cio para uma elei c ao com 3 cargos com comparecimento de 3 eleitores em um espa co de apenas 7 eleitores poss veis. O primeiro eleitor escolhe 13 para Governador, 31 para Senador e BRANCO para Presidente. O segundo eleitor escolhe 71 para Governador, anula seu voto para Senador com um n umero inv alido e escolhe 37 para Presidente. O terceiro e u ltimo eleitor tamb em escolhe 71 para Governador, BRANCO para Senador e 37 para Presidente. Observe que na vers ao nal do arquivo, a princ pio n ao e poss vel estabelecer correspond encia entre a posi c ao do eleitor na ordem de vota c ao e suas escolhas; e que as posi c oes vazias s ao conservadas pelo embaralhamento.
Governador Senador Presidente Governador Senador Presidente

31 13
BRANCO

71 13

31

NULO
BRANCO

37
(a) Registro do primeiro voto.
Governador Senador Presidente

(b) Registro do segundo voto.

Governador Senador Presidente

71 13 71

31
BRANCO

37

71 13 71

31
BRANCO

37

NULO
BRANCO

NULO
BRANCO

37
(c) Registro do terceiro voto.

37
(d) Aspecto nal do arquivo.

Figura 3.1: Exemplo de armazenamento fora de ordem dos votos no RDV.

14

3.2

Hip otese

A apresenta c ao desse mecanismo de embaralhamento foi encarada com imediata desconan ca pela equipe ap os sua apresenta c ao durante a palestra de abertura [3]. A raz ao para tal foi a constata c ao de que a ordem em que os votos s ao armazenados precisa atingir rigor criptogr aco de aleatoriedade, e apenas um prossional com algum treinamento b asico na area de Seguran ca Computacional observaria que o mecanismo de embaralhamento e t ao cr tico para o sigilo do voto quanto a verica c ao de integridade do software para a integridade dos resultados. Desta forma, ainda na palestra de abertura, a equipe levantou a hip otese de que o RDV n ao havia sido projetado e implementado de forma segura. Com apenas algumas buscas por fun c oes conhecidamente inseguras para a gera c ao de n umeros aleat orios efetuadas na primeira hora de exame do c odigo-fonte, a hip otese j a cou extremamente fortalecida. Restava apenas determinar que informa c oes seriam necess arias para se reverter o embaralhamento e recuperar os votos na ordem em que foram inseridos.

3.3

Projeto e implementa c ao

O mecanismo de embaralhamento foi projetado e implementado utilizando uma progress ao de erros que terminou por permitir a sua revers ao. A implementa c ao utiliza um gerador de n umeros pseudo-aleat orios, procedimento computacional que produz uma sequ encia de n umeros aparentemente aleat orios, mas que pode ser unicamente determinada a partir de um pequeno par ametro chamado semente que precisa ser escolhido de forma verdadeiramente aleat oria. Quando e necess aria a impossibilidade de deriva c ao independente da sequ encia por um atacante, a semente deve ser n ao s o apenas verdadeiramente aleat oria, mas tamb em mantida em segredo. A seguir, apresentamos a progress ao de vulnerabilidades no software que for cou o gerador de n umeros pseudo-aleat orios a funcionar fora de seus limites de opera c ao, n ao atingindo suas propriedades de seguran ca: 1. Escolha inadequada de gerador de n umeros pseudo-aleat orios: foi escolhido o gerador pseudo-aleat orio padronizado da linguagem de programa c ao C implementado com as fun c oes rand()/srand(). Este gerador possui per odo curto e aceita sementes muito pequenas, com comprimento de apenas 32 bits. Logo, n ao alcan ca qualidade criptogr aca [12]. A simples ecolha desse gerador pseudo-aleat orio j a fornece uma metodologia probabil stica de ataque; 2. Escolha inadequada de semente: a semente consistia em uma tomada de tempo com precis ao de segundos no fuso hor ario UTC (Coordinated Universal Time ) implementada com a fun c ao time() 15

e executada na inicializa c ao do sistema de vota c ao. Esta escolha de semente obviamente n ao e verdadeiramente aleat oria. Como o sistema de vota c ao deve ser inicializado entre as 7 e 8 da manh a do dia de elei c ao, ainda reduz signicativamente o espa co de sementes poss veis em caso de busca exaustiva para apenas 3600 valores; 3. Publica c ao da semente: n ao obstante a n ao-aleatoriedade da semente, a mesma ainda era tornada p ublica mediante registro em LOG e impress ao em documento ocial, a zer esima. A zer esima torna-se p ublica logo ap os sua emiss ao, o LOG de eventos torna-se p ublico aos partidos ap os o nal das elei c oes. De posse da hora de emiss ao da zer esima, e poss vel reproduzir a ordem de armazenamento dos votos com exatid ao e eci encia, sem probabilidades de erro ou necessidade de busca exaustiva. O mecanismo de assinatura digital do arquivo de LOG e as assinaturas convencionais dos scais de partido na zer esima ainda garantem que os documentos s ao aut enticos e que o hor ario neles contido consiste de fato na semente necess aria para se recuperar os votos em ordem. Os Algoritmos 3.1 e 3.2 apresentam vers oes simplicadas de como funcionavam a inicializa c ao do gerador pseudo-aleat orio e o armazenamento de um voto em posi c ao pseudo-aleat oria do RDV, respectivamente. A Figura 3.2 apresenta uma c opia de zer esima encontrada na Internet, com a semente (que deveria ser aleat oria e secreta) apresentada em destaque. Seja n o n umeros de eleitores que votaram em um espa co total com m eleitores. Da forma como foi projetado e implementado, a presen ca de posi c oes vazias no arquivo RDV nal permite testar valores distintos de semente para obten c ao da semente correta sempre que o comparecimento na se c ao eleitoral n ao e absoluto. Esse teste e poss vel pela compara c ao entre as posi c oes vazias do arquivo nal e as posi c oes vazias geradas pela semente sendo testada quando n votos s ao registrados. Algoritmo 3.1 Inicializa c ao do RDV. Entrada: Tabela T representando o RDV, total de m de eleitores. Sa da: Tabela T inicializada e gerador pseudo-aleat orio alimentado com semente na forma de tomada de tempo. 1: srand(time(NULL)); 2: for i 0 to m do 3: T [i] VAZIO 4: end for

16

Algoritmo 3.2 Armazenamento de um voto no RDV. Entrada: Tabela T representando o RDV, n umero 0 i < n do voto V . Sa da: Tabela T atualizada com o voto V inserido. 1: j rand() mod m 2: if T [j ] = VAZIO then 3: {Colis ao encontrada!} 4: Incrementar ou decrementar j at e encontrar pr oxima posi c ao livre 5: end if 6: T [j ] V Figura 3.2: Zer esima destacando a semente do embaralhamento de votos.

3.4

Ataques

A progress ao de vulnerabilidades apresentada na se c ao anterior permite a formula c ao de duas metodologias de ataque distintas: Ataque direto: a partir da semente, que n ao deveria ser p ublica mas vinha sendo, recuperada a partir do LOG de eventos ou zer esima da se c ao eleitoral, e poss vel simular o embaralhamento de n votos e detectar em que posi c ao cada voto foi armazenado no RDV da se c ao, que deve ser p ublico e vem sendo, permitindo assim a recupera c ao dos votos em ordem, a partir de documentos que o atual sistema congura como necess arios para a scaliza c ao do processo eleitoral. Ataque indireto: a partir dos votos embaralhados, e poss vel realizar uma busca exaustiva no espa co de sementes poss veis e recuperar a 17

semente correta pela compara c ao das posi c oes vazias. De posse da semente correta, o ataque direto pode ser efetuado. Como os ataques descritos acima n ao envolvem a modica c ao ou altera c ao de qualquer componente do software ou hardware da urna eletr onica e especicamente n ao exigem a invas ao do per metro f sico de seguran ca do equipamento, pode-se concluir que ambos s ao essencialmente n ao-rastre aveis. A raz ao para isso e que a leitura de produtos p ublicos de vota c ao nunca deixa rastro percept vel, visto que n ao e poss vel diferenciar a scaliza c ao da informa c ao p ublica de um procedimento de ataque ao sigilo do voto. Al em disso, os ataques s ao determin sticos, exatos e reprodut veis, sem haver qualquer chance de erro. Fica ent ao derrotado o u nico mecanismo utilizado pelo software da urna eletr onica para proteger o sigilo do voto, observando-se o crit erio de voto secreto como requisito constitucional do sistema de vota c ao. O Algoritmo 3.3 apresenta o ataque direto descrito acima. Algoritmo 3.3 Recupera c ao em ordem dos votos do RDV. Entrada: Tabela T representando o RDV, semente p ublica s, n umero n de eleitores que votaram dentre m eleitores poss veis. Sa da: Lista de votos em ordem. 1: srand(s); 2: for i 0 to n do 3: j rand() mod m 4: if T [j ] = MARCA then 5: {Colis ao encontrada!} 6: Incrementar ou decrementar j at e encontrar T [j ] = MARCA 7: end if 8: Imprimir voto armazenado em T [j ] 9: T [j ] MARCA 10: end for Posteriormente, foi obtida a informa c ao de que o LOG tamb em p ublico de eventos registra o instante de tempo em que cada eleitor conrmou seu voto [13]. Quando esse registro temporal e associado ` a lista de votos recuperados em ordem, ca tamb em poss vel recuperar um voto espec co inserido em um certo instante de tempo.

3.5

Consequ encias

Agora suponha um atacante capaz de coagir k eleitores e monitorar o comportamento de eleitores no dia de elei c ao. A recupera c ao dos votos em ordem permite que esse atacante tenha sucesso com certeza matem atica em um conjunto de fraudes eleitorais, aqui denominadas por voto de cabresto digital : 18

 Inser c ao dos eleitores coagidos nas k primeiras posi c oes da la de vota c ao e posterior recupera c ao dos k primeiros votos. Isto n ao parece dif cil se o atacante transporta os k eleitores e simplesmente comparece com anteced encia ` a abertura da se c ao eleitoral; Utiliza c ao de um voto marcador que indica o in cio do bloco de k eleitores coagidos. Caso a chegada com anteced encia seja um obst aculo, o atacante pode tamb em instruir um eleitor a votar de maneira pr edeterminada (anulando seu voto, por exemplo), a partir do qual tem in cio a sequ encia dos votos dos k eleitores coagidos; O registro da ordem ou do hor ario de vota c ao de todos os eleitores da urna eletr onica sob ataque permite a quebra do sigilo do voto para todos os n eleitores que registraram seu voto, mesmo aqueles n ao coagidos pelo atacante. Observe que essa informa c ao pode ser obtida com colabora c ao dos mes arios ou scais de partido. Um hor ario de vota c ao espec co determina a posi c ao na ordem de vota c ao que um certo eleitor conrmou seu voto. Examinando a posi c ao correspondente na lista de votos recuperada em ordem do RDV revela diretamente quais foram as escolhas do eleitor. Este ataque de quebra de sigilo direcionado pode, al em de violar o crit erio de voto secreto assegurado pela constitui c ao [14], causar constrangimento signicativo para personalidades p ublicas (pol ticos, empres arios, industriais, ministros). Note que o local e hor ario de vota c ao destas personalidades e frequentemente noticiado pela imprensa no dia de elei c ao [15, 16].

3.6

Corre c oes

A corre c ao da progress ao de vulnerabilidades parte do fortalecimento do gerador de posi c oes aleat orias para armazenamento no RDV. Este aprimoramento pode inclusive ser implementado a partir de componentes j a dispon veis na pr opria urna eletr onica. A forma mais segura para se efetuar a corre c ao e substituir o gerador pseudo-aleat orio atualmente utilizado por outro gerador pseudo-aleat orio com propriedades estat sticas superiores. Exemplos de geradores assim s ao documentados em padr oes [17] e podem ser encontrados em bibliotecas criptogr acas de uso geral [18]. Resta apenas determinar fontes de semente para o gerador pseudo-aleat orio melhorado. Para satisfazer o crit erio de aleatoriedade verdadeira, recomenda-se que a semente seja produzida por um gerador em hardware baseado em efeito f sico bem estudado. Segundo especica c ao da urna eletr onica modelo 2009 [19], um gerador com estas caracter sticas j a deveria estar dispon vel no m odulo de seguran ca em hardware do equipamento. O processador AMD Geode mencionado na especica c ao tamb em possui um gerador de n umeros verdadeiramente aleat orios [20] acess vel a partir do arquivo /dev/hw random. 19

Para os modelos anteriores, compromissos de engenharia precisam ser atingidos. Uma solu c ao poss vel e a obten c ao da semente do arquivo /dev/random, que comprime eventos de sistema operacional em entropia de qualidade criptogr aca acessada por leituras bloqueantes. Problemas para se adotar essa solu c ao envolvem a previsibilidade da inicializa c ao da urna eletr onica, que pode n ao fornecer a entropia necess aria para obten c ao de uma semente segura, e o preju zo de funcionalidade do equipamento por bloqueio da leitura na situa c ao de falta de entropia. A u ltima solu c ao recomendada e relaxar o requisito de qualidade criptogr aca e efetuar a obten c ao da semente do arquivo /dev/urandom a partir de leitura n ao-bloqueante. Ainda que nesse caso o rigor criptogr aco seja perdido, a qualidade do embaralhamento de votos dever a ser signicativamente superior ` a constru c ao atual. N ao custa enfatizar que e preciso realizar testes cuidadosos para determinar se as corre c oes sugeridas atendem aos requisitos m nimos de seguran ca estabelecidos para o mecanismo de embaralhamento. Os autores se eximem de qualquer responsabilidade caso as solu c oes sugeridas ainda mantenham o mecanismo de embaralhamento como vulner avel.

20

Cap tulo 4

Fragilidades
O exame do c odigo-fonte do software da urna eletr onica n ao revelou apenas a vulnerabilidade no projeto e implementa c ao do mecanismo de prote c ao do sigilo do voto, como discutido no cap tulo anterior, mas tamb em evidenciou um conjunto de fragilidades em componentes cr ticos do software. Cada fragilidade apresentada aqui representa uma vulnerabilidade em potencial que permite a um agente interno ou externo formular uma metodologia de ataque. A presen ca de fragilidades, at e mesmo em componentes cr ticos do software, atesta a presen ca de fragilidades no pr oprio processo de desenvolvimento de software utilizado.

4.1

No software

A seguir, discutimos as fragilidades encontradas no software, algumas j a anteriormente discutidas no Relat orio elaborado pela Sociedade Brasileira de Computa c ao em 2002 [11], ou na an alise acad emica do software de vota c ao das m aquinas utilizadas nos Estados Unidos e fabricadas pela Diebold [21], mesma companhia que fabrica o hardware das urnas brasileiras e produziu as vers oes iniciais do software.

4.1.1

Prote c ao inadequada ao sigilo do voto

O Registro Digital do Voto (RDV) institu do por dispositivo legal e apresentado no cap tulo anterior n ao fornece nenhuma capacidade de verica c ao independente adicional, por ser gerado pelo mesmo software que realiza a contabiliza c ao parcial e gera o Boletim de Urna (BU). Por essa raz ao, a possibilidade de adultera c ao do BU implica diretamente na possibilidade de adultera c ao do RDV, o que signica que o RDV se qualica apenas como informa c ao redundante, t ao pass vel de ataque quanto aquilo que tenta proteger. Como o RDV n ao possui qualquer valor pr atico, serve apenas como uma fonte de ataque ao sigilo do voto caso o mecanismo de embaralhamento

21

dos votos n ao seja projetado e implementado de forma segura. Al em disso, o pr oprio projeto da urna n ao elimina completamente a possibilidade de se vincular a identidade do eleitor ao seu voto atrav es de software adulterado [11, p agina 28], visto que ambos os equipamentos que coletam essas poss informa c oes est ao conectados eletronicamente. E vel concluir que ambas as informa c oes co-existem no estado interno da urna em algum momento e assim podem ser capturadas por um programa malicioso. Como o RDV foi institu do em 2003, e interessante imaginar se a mesma vulnerabilidade discutida no cap tulo anterior estava presente no software utilizado nas quatro elei c oes passadas. Ainda que os autores n ao tenham atualmente nenhuma inten c ao de investigar essa possibilidade, existem apenas tr es respostas poss veis para essa pergunta: (i) o mecanismo de embaralhamento dos votos era mais vulner avel; (ii) o mecanismo de embaralhamento era t ao vulner avel quanto o examinado pela equipe; (iii) o mecanismo de embaralhamento era menos vulner avel. As duas primeiras hip oteses indicam que houve prote c ao inadequada ao sigilo do voto nas quatro u ltimas elei c oes, sendo essa propriedade de seguran ca pass vel de ataque por agentes internos ou externos com algum conhecimento do mecanismo. A terceira hip otese indica que a qualidade do software de vota c ao se degenera com o passar do tempo, existindo a possibilidade do mesmo se tornar menos seguro de uma elei c ao para outra. As tr es hip oteses s ao igualmente preocupantes, especialmente quando se considera que o sigilo do voto e cl ausula p etra da Constitui c ao Federal e que o pa s sempre foi campo f ertil para a fraude eleitoral tradicionalmente conhecida como voto de cabresto. Recomenda c ao. Eliminar o RDV e substitui-lo por um mecanismo que forne ca a possibilidade real de verica c ao independente de resultados, como o voto impresso veric avel pelo eleitor. Caso a presen ca do RDV seja uma exig encia, recomendamos no m nimo a elimina c ao das posi c oes vazias do arquivo em seu formato nal, para dicultar a busca exaustiva no espa co de sementes poss veis. Caso o mecanismo de embaralhamento dos votos continue fr agil, essa compacta c ao n ao resiste a ataques realizados por agentes internos ou bem-informados.

4.1.2

Fonte inadequada de entropia

Entropia tem car ater cr tico para v arias opera c oes criptogr acas que requerem dados aleat orios, como a gera c ao de chaves ef emeras ou a alimenta c ao com semente de geradores pseudo-aleat orios, e em muitos casos e poss vel contornar completamente a t ecnica criptogr aca com ataques apenas na fonte de entropia. Obter entropia suciente em equipamentos com interatividade limitada a partir unicamente de recursos de software e uma tarefa praticamente imposs vel. Como discutido no Cap tulo anterior, o software da urna eletr onica brasileira utilizava apenas a medida do tempo em resolu c ao de segundos como fonte de entropia, mesmo tendo dispon veis fontes 22

de melhor qualidade em hardware. A coleta de informa c ao previs vel para utiliza c ao inadequada como entropia n ao e uma vulnerabilidade desconhecida em sistemas de vota c ao ou software comercial. A urna eletr onica utilizava nos Estados Unidos empregava t ecnicas igualmente inseguras [21, Problema 5.2.12], obtendo informa c ao a partir do conte udo da tela e de uma medida de tempo com resolu c ao de milissegundo desde a inicializa c ao do sistema operacional. Em 1995, calouros de doutorado da Universidade de Berkeley descobriram sem acesso ao c odigo-fonte que a vers ao 1.1 do navegador Netscape apresentava exatamente a mesma vulnerabilidade [22], utilizando inclusive a mesma chamada na linha 1 do Algoritmo 3.1. Recomenda c ao. Adotar as sugest oes apresentadas na Se ca o 3.6.

4.1.3

Verica c ao insuciente de integridade

A urna eletr onica conta com um mecanismo de verica c ao de integridade de software que tem como objetivo vericar se houve adultera c ao dos programas da urna eletr onica entre sua a produ c ao e a sua execu c ao propriamente dita no equipamento. Este mecanismo de verica c ao de software muda radicalmente com a presen ca do m odulo customizado de seguran ca em hardware. Por essa raz ao, a an alise ser a dividida em dois cen arios. Urnas eletr onicas sem m odulo de seguran ca em hardware. A verica c ao da integridade do software cabe a si pr oprio, podendo ser desativada caso haja acesso livre ` as por c oes dos programas que efetuam a verica c ao. Para mitigar esse risco, costuma-se implementar um mecanismo preliminar de verica c ao na BIOS (Basic Input/Output System ), que assegura que o software executado em seguida e ntegro. Entretanto, esta t ecnica apenas reduz a integridade do software ` a integridade do rmware programado na BIOS. O problema de verica c ao de integridade da BIOS, por sua vez, e reduzido a si pr oprio, sem fonte externa de conan ca. Urnas eletr onicas equipadas com m odulo de seguran ca em hardware. A verica c ao funciona como descrito anteriormente, com a exce c ao de que a verica c ao do conte udo da BIOS e agora efetuada pelo m odulo de seguran ca. Neste cen ario, o problema de verica c ao de integridade de software termina por se reduzir a uma fonte de conan ca armazenada no interior do m odulo de seguran ca, sob a forma de uma cadeia autocontida de certica c ao digital para valida c ao das assinaturas digitais realizadas nos demais componentes de software. Derrotar um mecanismo de verica c ao implementado nesses moldes requer a colabora c ao de um agente interno capaz de desativar o m odulo de seguran ca ou substituir a cadeia de certica c ao digital e realizar assinaturas digitais do software adulterado utilizando as chaves privadas correspondentes 23

ao certicado digital inserido posteriormente. Entretanto, segundo a pr opria especica c ao do m odulo de seguran ca em hardware utilizado nas urnas eletr onicas a partir de 2009, h a a necessidade de se programar o m odulo de seguran ca com o resumo criptogr aco correto da BIOS [19]. Isto nos leva a concluir que a BIOS transmite o seu pr oprio resumo para verica c ao pelo m odulo de seguran ca, ao inv es de exigir que o m odulo de seguran ca verique de forma ativa o conte udo da BIOS. Assim, uma BIOS maliciosa pode personicar a BIOS leg tima, a partir da transmiss ao do resumo criptogr aco correto, e desativar a verica c ao de assinaturas digitais no caminho seguinte da cadeia de conan ca. Em u ltimo lugar, vale ressaltar que os autores observaram que a linha de c odigo no Gerenciador de Aplicativos (GAP), respons avel pela verica c ao de integridade das bibliotecas din amicas, encontrava-se desativada com um coment ario, atestando que mesmo que a cadeia de conan ca seja estabelecida de forma correta, o processo de verica c ao de integridade ainda e sujeito a sabotagens ou erros de programa c ao. O Relat orio da SBC j a apresentava ceticismo expl cito a respeito da possibilidade de auto-verica c ao de software atrav es de t ecnicas cripto` esta preocupa gr acas [11, p agina 24]. A c ao, soma-se a observa c ao de que garantir que o software sendo executado na urna eletr onica e exatamente o mesmo produzido pelo TSE n ao torna o software seguro, apenas conrma sua origem, mesmo quando o mecanismo de verica c ao de integridade de software funciona corretamente. O problema de verica c ao de integridade de software e end emico em sistemas de vota c ao eletr onica. Este e um problema particularmente dif cil de se resolver na pr atica. A mesma limita c ao nos controles de integridade tamb em foi observada no software da urna eletr onica utilizada nos Estados Unidos [21, Problemas 4.1.5 e 4.1.6]. E por essa raz ao que se recomenda a instala c ao de mecanismos que forne cam capacidade de verica c ao independente de software dos resultados, para que os resultados da elei c ao n ao dependam unicamente da integridade do software [23]. Recomenda c ao. Promover a verica c ao ativa do conte udo da BIOS pelo m odulo de seguran ca em hardware. Essa recomenda c ao coincide com observa c oes realizadas pelo Grupo 6 durante os Testes P ublicos de Seguran ca [24]. De forma mais geral, recomenda-se transferir a press ao da verica c ao de integridade do software para a verica c ao independente dos resultados produzidos pelo software.

4.1.4

Compartilhamento de chaves criptogr acas

Todas as urnas eletr onicas em opera c ao no pa s utilizam a mesma chave criptogr aca para cifrar as parti c oes protegidas nos cart oes de mem oria. 24

O vazamento dessa chave criptogr aca tem impacto devastador e revela ao atacante o conte udo completo dos cart oes de mem oria, incluindo a o software de vota c ao, os mecanismos de verica c ao de integridade implementados em software e a chave privada RSA que realiza a assinatura digital dos produtos p ublicos de vota c ao [25]. Esta u ltima chave e compartilhada ainda por todas as urnas eletr onicas da mesma unidade federativa [26] e seu vazamento permite a uma atacante produzir um arquivo forjado (LOG, RDV ou BU) mas vericado como aut entico, em nome de uma urna escolhida arbitrariamente. Observa-se que o m odulo de seguran ca em hardware introduzido nas urnas eletr onicas possui capacidade ociosa para armazenamento seguro de chaves privadas [19]. Ou seja, o sigilo da chave privada e, consequentemente, a integridade dos boletins de urna com a totaliza c ao parcial dos votos, reside apenas na condencialidade de uma chave de cifra c ao compartilhada por meio milh ao de equipamentos [3]. Em posi c ao ocial, o TSE argumenta que utilizar chaves m ultiplas para cifrar os mesmos arquivos pode revelar alguma caracter stica estat stica do texto claro cifrado [27]. Ataques dessa natureza j a s ao estudados na literatura criptogr aca, mas n ao representam nenhum perigo pr atico relevante [28]. Fica claro, portanto, que este risco nem de perto se compara ao vazamento da chave massivamente compartilhada. A utiliza c ao de um modo de opera c ao que aleatoriza o texto claro tamb em elimina trivialmente este risco quando o texto claro n ao pode ser escolhido arbitrariamente pelo atacante [28], como e o caso discutido aqui. Recomenda c ao. Atribuir uma chave criptogr aca distinta para cada equipamento, ou pelo menos, para cada cart ao de mem oria utilizado para inseminar um conjunto reduzido de urnas eletr onicas. Mecanismos de deriva c ao de chaves s ao ferramentas criptogr acas projetadas exatamente para resolver este problema.

4.1.5

Presen ca de chaves no c odigo-fonte

O compartilhamento da chave de cifra c ao das m dias e agravado pela sua presen ca ` as claras no c odigo-fonte do software. Isto signica que qualquer agente interno que possua acesso ao reposit orio onde e mantido o c odigofonte tamb em possui automaticamente acesso ` a chave criptogr aca que protege as parti c oes cifradas dos cart oes de mem oria, podendo realizar o vazamento de impacto devastador mencionado anteriormente. Al em disso, isto tamb em signica que a chave de cifra c ao faz parte do m odulo do sistema operacional respons avel por acessar a parti c ao cifrada e tornar dispon vel seu conte udo, e por isso precisa estar armazenada ` as claras dentro do pr oprio cart ao de mem oria. Ou seja, o objeto cifrado e armazenado no mesmo lugar em que e armazenada a chave criptogr aca que o decifra, qualicando este mecanismo como apenas de ofusca c ao ao inv es de verdadeira seguran ca. Basta que um atacante conhe ca a posi c ao em que e armazenada a chave de 25

cifra c ao, por an alise da por c ao do software armazenada ` as claras nos cart oes de mem oria, para que o vazamento da chave se torne poss vel at e para agentes externos. Recomenda c ao. Armazenar a chave de cifra c ao no m odulo de seguran ca em hardware ou, preferivelmente, em dispositivo criptogr aco seguro externo ao ambiente da urna eletr onica.

4.1.6

Cifra c ao fora dos limites de opera c ao

O algoritmo de cifra c ao das parti c oes protegidas nos cart oes de mem oria eo Advanced Encryption Standard (AES) [29] no n vel de seguran ca de 256 bits, padr ao vigente para cifra c ao em aplica c oes cr ticas. O modo de opera c ao selecionado e o Cipher Block Chaining (CBC). A combina c ao de algoritmo e modo de operac ao e particularmente recomendada. Entretanto, o modo de opera c ao compartilha, al em da mesma chave de cifra c ao, o mesmo vetor de inicializa c ao, elemento respons avel justamente por aleatorizar o texto claro a ser cifrado e eliminar qualquer propriedade estat stica indesej avel ao se cifrar o mesmo programa com chaves m ultiplas. Escolher de forma uniformemente aleat oria um novo vetor de inicializa c ao para cada opera c ao de cifra c ao e requisito inclusive do modo de opera c ao CBC [30]. A argumenta c ao de se utilizar, por alguma quest ao estat stica, uma u nica chave compartilhada para cifrar todas as m dias de todas as urnas perde completamente o sentido quando o pr oprio modo de opera c ao de cifra c ao n ao est a sendo utilizado de forma correta e dentro dos limites de opera c ao onde sua seguran ca e bem entendida. Recomenda c ao. Selecionar um novo vetor de inicializa c ao para cada opera c ao de cifra c ao realizada pelo software da urna eletr onica, respeitando assim a especica c ao do modo de opera c ao escolhido.

4.1.7

Escolha inadequada de algoritmos

Al em da escolha absolutamente inadequada de algoritmo para gera c ao de n umeros pseudo-aleat orios, o software da urna eletr onica tamb em utiliza a fun c ao de resumo criptogr aco SHA-1 [31] para ns de assinatura digital e verica c ao de integridade. Esta fun c ao de resumo espec ca tem uso n ao recomendado para essas aplica c oes desde 2006, quando se vericou que a mesma n ao fornecia a resist encia a colis oes esperada [32], cando recomendada como prudente a migra c ao r apida para fun c oes de resumo mais seguras [33]. Recomenda c ao. Utilizar um gerador de n umeros pseudo-aleat orios de qualidade criptogr aca, como comentado na Se c ao 3.6, e uma fun c ao de resumo criptogr aco padronizada e resistente a colis oes, como as pertencentes ` a fam lia SHA-2 [31]. Caso o comprimento da cadeia de caracteres produzida como sa da da fun c ao de resumo seja cr tico para a confer encia por

26

humanos, basta utilizar uma fun c ao de resumo com seguran ca superior ` a necess aria e truncar o resultado.

4.1.8

Implementa co es repetidas de primitivas criptogr acas

Os autores encontraram diversas implementa c oes repetidas de algoritmos criptogr acos ao longo da base de c odigo. A impress ao e que cada componente de software que utiliza um algoritmo criptogr aco recebe sua pr opria implementa c ao do algoritmo, dicultando em muito a auditoria completa de todas as implementa c oes e aumentando signicativamente a chance de erro. Recomenda c ao. Concentrar todas as implementa c oes de primitas criptogr acas em uma mesma biblioteca cr tica de fun c oes que permita f acil auditoria de suas propriedades. Ou ainda, utilizar uma biblioteca criptogr aca com reputa ca o estabelecida, como o OpenSSL [18].

4.2

No processo de desenvolvimento

As fragilidades discutidas na Se c ao anterior s ao produto de um processo de desenvolvimento de software tamb em fr agil. Discutimos a seguir as fragilidades encontradas ou inferidas pelo contexto nesse processo de desenvolvimento. V arios dos mesmos problemas foram tamb em detectados no processo de desenvolvimento da urna utilizada nos Estados Unidos [21, Se c ao 4.3].

4.2.1

Complexidade acentuada

Seguran ca adv em de simplicidade, transpar encia e correta avalia c ao de premissas e condi c oes de conan ca. O volume de milh oes de linhas de c odigofonte empregado para se realizar elei c oes no Brasil elimina qualquer possibilidade de auditoria completa ou ecaz do software. Pode-se argumentar que uma parte signicativa dessas milh oes de linhas s ao provenientes do sistema operacional e n ao precisam de auditoria. Entretanto, vericou-se que o TSE realiza interven c oes nos componentes do sistema operacional, para por exemplo inserir a chave criptogr aca de cifra c ao no m odulo correspondente. Al em disso, quando n ao h a compartimentaliza c ao suciente, mesmo vulnerabilidades em trechos inofensivos de c odigo podem criar vulnerabilidades severas em trechos cr ticos que afetem os mecanismos de seguran ca. Um volume de c odigo dessa magnitude ir a possuir, inevitavelmente, vulnerabilidades que podem ser exploradas. Por essa raz ao, a base de c odigo deve ser completamente orientada em torno de um pequeno conjunto cr tico de funcionalidades, das quais depende o funcionamento correto e seguro do equipamento. Como um valor de refer encia, os pesquisadores que realizaram a avalia c ao das m aquinas de votar dos Estados Unidos em um intervalo de 60 dias conclu ram que os milhares de c odigo dedicados ` as camadas de

27

aplica c ao daquele equipamento s ao de complexidade tal que n ao e poss vel tornar o software seguro [21, Problema 4.1.2]. Recomenda c ao. Reduzir o volume de c odigo a partir de t ecnicas de reuso e componentiza c ao, como exemplicado na Se c ao 4.1.8. Evitar interven c oes no c odigo-fonte externo ao TSE e isolar as por c oes de c odigo de sistema operacional e aplica c ao para facilitar a auditoria interna do software.

4.2.2

Auditoria externa insuciente

Os partidos possuem a prerrogativa legal de examinar o c odigo-fonte do software da urna eletr onica, mas para isso precisam assinar um Acordo de N ao-Divulga c ao (AND) que os impede de detalhar publicamente qualquer problema observado no c odigo, mediante imposi c ao legal. Desta forma, os scais de partidos s ao impedidos de prestar contas ` a sociedade sobre a qualidade do que e feito no software, enquanto agentes desonestos possuem toda a liberdade para tentar articular fraudes eleitorais, sem qualquer risco de vazamento dos detalhes das vulnerabilidades encontradas. Como a scaliza c ao por investigadores independentes e extremamente limitada, consistindo em apenas alguns dias e sob monitora c ao completa, ou mais recentemente, por um per odo em que a imensa base de c odigo e constantemente modicada e em condi c oes inadequadas, na pr atica nenhuma scaliza c ao efetiva e realizada sobre o software do sistema eletr onico de vota c ao. Como arma de forma contundente o Relat orio SBC [11, p agina 23]: A seguran ca e corretude dos programas usados na urna baseia-se em conar na boa f e dos t ecnicos do TSE. Repetimos: n ao h a nenhuma raz ao para duvidar da boa f e destas pessoas. Mas isto fere as boas pr aticas de seguran ca. Como a integridade dos resultados depende unicamente da integridade desse software, ca montado um cen ario perfeito para fraudes que n ao deixam vest gios. Recomenda c ao. Permitir a auditoria do c odigo-fonte por qualquer cidad ao brasileiro, especialista ou n ao, sem qualquer obst aculo legal.

4.2.3

Aus encia de an alise est atica de c odigo

A fam lia de fun c oes vulner avel utilizada para embaralhamento dos votos e detectada como potencialmente insegura por qualquer ferramenta de an alise est atica de c odigo. A ferramenta gratuita Flawnder [34], por exemplo, produz o seguinte alerta quando examina um trecho de c odigo contendo a chamada de fun c ao, como por exemplo o programa de an alise que implementa o Algoritmo 3.3:

28

This function is not suciently random for security-related functions such as key and nonce creation. Use a more secure technique for acquiring random values. Recomenda c ao. Utilizar ferramentas sosticadas de an alise de c odigo para minimizar o impacto de erros de programa c ao que produzem vulnerabilidades, respeitando as boas pr aticas para desenvolvimento de software de miss ao cr tica.

4.2.4

Formula c ao equivocada de modelo de atacante

O projeto de mecanismos de seguran ca utilizado preocupa-se exageradamente com atacantes externos e ignora o risco de atacantes internos. Em particular, como demonstra a pr opria posi c ao ocial do TSE [27], a detec c ao de comportamento malicioso por agentes internos e reduzida a processos de auditoria tamb em executados por humanos, obviamente internos. A quest ao da chave compartilhada de cifra c ao e um exemplo perfeito deste fen omeno, visto que h a enorme preocupa c ao com ataques estat sticos esot ericos montados por atacantes externos, enquanto o risco muito maior de vazamento da chave por um agente interno e completamente ignorado. O armazenamento as claras desta mesma chave de cifra ` c ao dentro da pr opria urna eletr onica evidencia que os mecanismos de seguran ca n ao s ao projetados para resistir a atacantes que disp oem de informa c ao privilegiada. Recomenda c ao. Adotar mecanismos de seguran ca que resistam a agentes externos e, particularmente, a agentes internos que os conhecem em seus m nimos detalhes.

4.2.5

Aus encia de exerc cios internos

Em reuni ao ap os a audi encia p ublica para presta c ao de contas, realizada entre a equipe e v arios membros dos setores respons aveis pelas fases de projeto, produ c ao e log stica da urna eletr onica, os autores ofereceram a possibilidade de ministrar uma palestra t ecnica para detalhar todos os problemas encontrados no software e o racioc nio espec co que os levou ` a detec c ao e explora c ao da vulnerabilidade discutida no Cap tulo 3. A proposta foi bem recebida, por permitir aos interessados o entendimento exato de como funciona a mente do atacante, nas palavras dos pr oprios membros do TSE. N ao houve convite concreto posterior para tal, mas a leitura dos autores a partir dessa arma c ao e de que n ao existe um time interno respons avel por simular o atacante, exercitar metodologias de ataque e tentar derrotar os mecanismos de seguran ca. Recomenda c ao. Instituir, treinar e orientar um time interno de atacantes simulados, pr atica recomendada para software de miss ao cr tica [21]. N ao faz sentido projetar mecanismos de seguran ca sem que existam tentativas simult aneas de subvert e-los. 29

4.2.6

Falta de treinamento formal

As fragilidades discutidas nesse Cap tulo, presentes inclusive em mecanismos cr ticos de seguran ca, demonstram claramente que os membros da equipe de desenvolvimento de software do TSE n ao recebem treinamento suciente para implementar software de seguran ca. A pr opria hip otese formulada pelos autores, ainda na palestra de abertura, de que o mecanismo de embaralhamento dos votos poderia n ao ter sido projetado e implementado de forma segura, por entender que apenas uma equipe com treinamento formal poderia faz e-lo, j a demonstra o grau da falta de treinamento observado. A aus encia de simula c oes internas que modelem satisfatoriamente atacantes plaus veis, por falta de entendimento sobre o modo de atua c ao de um atacante, tamb em corrobora essa observa c ao, visto que um prossional com treinamento adequado na area de seguran ca j a naturalmente costuma se alternar entre os pap eis de projetista e atacante por todo o tempo. Recomenda c ao. Instituir uma pol tica para treinamento especializado da equipe de desenvolvimento e fundamental para se incrementar a qualidade geral do software. N ao e plaus vel esperar software seguro como resultado do trabalho de uma equipe de desenvolvimento sem treinamento formal.

4.2.7

Disponibiliza c ao de dados cr ticos aos investigadores

As m aquinas dedicadas por exibir o c odigo-fonte na sala lacrada durante os Testes P ublicos de Seguran ca pareciam ter vindo diretamente da equipe de desenvolvimento. A raz ao para tal e a disponibiliza c ao para todos os investigadores de informa c oes cr ticas a respeito de nomes de usu ario, senhas e o caminho na rede interna para servidores de versionamento do c odigo da urna. Um atacante externo que consiga invadir a rede interna do TSE e esteja munido dessas informa c oes consegue ainda realizar altera c oes maliciosas no c odigo-fonte e efetiv a-las sob a alcunha de um membro leg timo da equipe de desenvolvimento, transferindo completamente para um inocente a responsabilidade por seus atos. Recomenda c ao. Sanitizar equipamentos disponibilizados para visitantes externos, para que os mesmos n ao revelem informa c oes cr ticas.

4.2.8

Ignor ancia da literatura relevante

Como discutido no Cap tulo 3, a vulnerabilidade encontrada no embaralhamento dos votos e conhecida h a pelo menos 17 anos [22]. Al em disso, v arias fragilidades apresentadas nesse relat orio j a foram descritas em laudos t ecnicos de outros sistemas de vota c ao [21], e mesmo em do pr oprio [11], os quais contrariam o bom senso e a especica c ao formal das t ecnicas criptogr acas utilizadas. A persist encia desses problemas em uma base de c odigo com 16 anos de hist oria e injustic avel e evidencia claramente que a equipe

30

de desenvolvimento do TSE n ao acompanha de forma adequada os movimentos relevantes na area de vota c ao eletr onica. Recomenda c ao. Responsabilizar parte da equipe de desenvolvimento por estudar e disseminar avan cos relevantes de car ater acad emico ou pr atico para a seguran ca de sistemas.

4.2.9

Falsa sensa c ao de seguran ca

A repeti c ao incessante de que a urna eletr onica brasileira e absolutamente segura e inviol avel, mesmo que isso constitua at e uma impossibilidade te orica, perturba o senso cr tico dos membros da equipe de desenvolvimento, que terminam por suspender seus pr oprios mecanismos de avalia c ao. O processo de desenvolvimento do software da urna eletr onica parece funcionar sob o efeito de suspens ao de descren ca, instalando uma falsa sensa c ao de seguran ca generalizada. Este n ao e o ambiente ideal para se desenvolver solu c oes de seguran ca, especialmente quando as mesmas precisam satisfazer o requisito de miss ao cr tica. Recomenda c ao. Adequar o processo de desenvolvimento de software para que estimule a verica c ao m utua e cr tica do trabalho realizado, com par ametros realistas de avalia ca o.

31

Cap tulo 5

Conclus oes e perspectivas

Este relat orio apresentou um conjunto de vulnerabilidades no software da urna eletr onica que permitiram a recupera c ao eciente, exata e sem deixar vest gios dos votos em ordem registrados eletronicamente. Associando essa informa c ao ` a lista em ordem de vota c ao dos eleitores, obtida externamente, possibilita a viola c ao completa do sigilo do voto. A partir do registro cronol ogico de eventos, tamb em e poss vel recuperar um voto computado em um instante de tempo espec co. As consequ encias dessas vulnerabilidades foram discutidas sob um modelo realista de atacante e corre c oes foram sugeridas. Diversas fragilidades adicionais no software ou processo de desenvolvimento que o produz tamb em foram detectadas e aqui discutidas, com recomenda c oes concretas de mitiga c ao. Em particular, demonstrou-se como derrotar o u nico mecanismo de prote c ao do sigilo do voto utilizado pelo software da urna eletr onica. A necessidade de se instalar recursos para avalia c ao cient ca, independente e cont nua do software torna-se evidente, havendo ampla disponibilidade de especialistas na academia e ind ustria capazes de contribuir na dire c ao do incremento real das propriedades de seguran ca na solu c ao adotada para vota c ao eletr onica no pa s. Esse conjunto de fragilidades e vulnerabilidades termina apenas por fornecer evid encias materiais para as preocupa c oes j a levantadas pelo Relat orio SBC de 2002 [11, Considera c oes Finais]. Em particular, pode-se concluir que n ao houve incremento signicativo nas propriedades de seguran ca fornecidas pelo software da urna eletr onica nos u ltimos 10 anos. Continuam preocupantes a prote c ao inadequada do sigilo do voto, a impossibilidade pr atica de auditoria completa ou minimamente ecaz do software, e a verica c ao insuciente ou in ocua de integridade do software de vota c ao. Como estas tr es propriedades s ao atualmente cr ticas para garantir o anonimato e destina c ao correta dos votos computados, resta aos autores repetir as conclus oes do Relat orio SBC e defender a reintrodu c ao do voto impresso nos termos apresentados em [11, p agina 29] como mecanismo simples de verica c ao de

32

integridade dos resultados de elei c oes. O voto impresso distribui a auditoria do software entre todos os eleitores, que se tornam respons aveis por conferir que seus votos foram registrados corretamente pela urna eletr onica, desde que apura c ao posterior seja realizada para vericar que a contagem dos votos impressos corresponde exatamente ` a totaliza c ao eletr onica parcial. Essa apura c ao pode ser realizada por amostragem, de forma a n ao haver impacto signicativo na lat encia para divulga c ao dos resultados. Vale ressaltar que o voto impresso e para ns de confer encia apenas no interior da se c ao eleitoral e n ao pode servir de comprovante no ambiente externo ` a se c ao eleitoral, como determina a legisla c ao a respeito [35]. A proposta de voto impresso retornaria para o sistema brasileiro de vota c ao nas elei c oes de 2014, mas infelizmente foi suspensa por alega c oes question aveis de inconstitucionalidade. Um movimento nesta dire c ao acompanharia a tend encia mundial vigente em sistemas de vota c ao eletr onica. Com a ado c ao do voto impresso pela India, o Brasil permanece como o u nico pa s no mundo a adotar sistema de vota c ao sem verica c ao independente de resultados. Acreditamos que por esse motivo, e dadas as fragilidades discutidas neste relat orio, o software utilizado no sistema de vota c ao eletr onica brasileiro n ao satisfaz requisitos m nimos e plaus veis de seguran ca e transpar encia.

33

Refer encias Bibliogr acas

[1] Janino, G. D.; Balc ao Filho, A.; Montes Filho, A.; Lima-Marques, M; Dahab, R.: Relat orio do Comit e Multidisciplinar nomeado pela PortariaTSE 192, 2009. [2] Tribunal Superior Eleitoral. Edital No 01/2012. Arquivo dispon vel em http://www.justicaeleitoral.jus.br/arquivos/ tse-2-edicao-dos-testes-de-seguranca-na-urna-eletronica [3] Azevedo, R.: Aspectos T ecnicos da Seguran ca do Sistema Eletr onico de Vota c ao. Dispon vel em http://www.tse.jus.br/ hotSites/testes-publicos-de-seguranca/arquivos/material/ Apresentacao_aspectos-tecnicos.pdf [4] Grupo 1. Plano de Teste GP1T1 Tentativa n ao-rastre avel de quebra de sigilo de vota c ao. Dispon vel em http://www.tse.jus.br/hotSites/ testes-publicos-de-seguranca/arquivos/G1PT1.pdf [5] Grupo 1. Plano de Teste GP1T2 Tentativa n ao-rastre avel de fraude no resultado de vota c ao. Dispon vel em http://www.tse.jus.br/ hotSites/testes-publicos-de-seguranca/arquivos/G1PT2.pdf [6] Presid encia da Rep ublica. Lei No 10.740, de 1o de Outubro de 2003. Dispon vel em http://www.planalto.gov.br/ccivil_03/leis/2003/ l10.740.htm [7] Tribunal Superior Eleitoral. Edital No 05/2012. Dispon vel em http: //www.tse.jus.br/hotSites/testes-publicos-de-seguranca/ arquivos/TSE-edital-5-2012-criterios-de-classificacao.pdf [8] Comiss ao de Avalia c ao. Avalia c oes sobre o Teste de Seguran ca. Arquivo dispon vel em http://www.tse.jus.br/hotSites/ testes-publicos-de-seguranca/arquivos/RelatorioFinal.pdf [9] Presid encia da Rep ublica. Lei No 9.504, de 30 de Setembro de 1997. Dispon vel em http://www.planalto.gov.br/ccivil_03/leis/ l9504.htm

34

[10] Presid encia da Rep ublica. Lei No 10.408, de 10 de Janeiro de 2002. Dispon vel em http://www.planalto.gov.br/ccivil_03/leis/2002/ L10408.htm [11] van de Graaf, J.; Cust odio, R. F.: Tecnologia Eleitoral e a Urna Eletr onica Relat orio SBC 2002. Dispon vel em http: //www.sbc.org.br/index.php?option=com_jdownloads&Itemid= 195&task=view.download&catid=77&cid=107 [12] Wheeler, D.: Secure Programming for Linux and Unix HOWTO, 2003. Dispon vel em http://www.dwheeler.com/secure-programs/ Secure-Programs-HOWTO.html [13] Tribunal Superior Eleitoral. Especica c ao do Arquivo e Registro de Log das Urnas Eletr onicas para as Elei c oes 2008, Vers ao 2. Dispon vel em http://www.tse.gov.br/internet/eleicoes/arquivos/logs2008/ EspecificacaoArquivoRegistroLogUrnasEletronicasEleicoes2008. pdf [14] Presid encia da Rep ublica. Lei No 4.737, de 15 de Julho de 1965. Dispon vel em http://www.planalto.gov.br/ccivil_03/leis/l4737. htm [15] Ag encia de Not cias da Justi ca Eleitoral. Presidente do TSE vota em tr ansito na capital federal. Dispon vel em http://agencia.tse.jus. br/sadAdmAgencia/noticiaSearch.do?acao=get&id=1336461 [16] Correio Braziliense. Presidente do TSE, Ricardo Lewandowski, vota em tr ansito no IESB. Dispon vel em http://www.correiobraziliense. com.br/app/noticia/especiais/eleicoes2010/2010/10/03/ interna_eleicoes2010,216159/index.shtml [17] National Institute of Standards and Technology. FIPS 186-1 Digital Signature Standard (DSS), 1998. [18] The OpenSSL Project. Dispon vel em http://www.openssl.org/ [19] Tribunal Superior Eleitoral. Aquisi c ao de Urnas Eletr onicas UE2009 / PB Projeto B asico. http://www.tse.jus.br/transparencia/ arquivos/tse-projeto-basico-audiencia-publica-2009 [20] AMD. Design without compromise, 2007. Dispon vel em http://www. amd.com/us/Documents/33358e_lx_900_productb.pdf [21] Calandrino, J. A.; Feldman, A. J.; Halderman, J. A.; Wagner, D.; Yu, H.; Zeller, W. P.: Source Code Review of the Diebold Voting System, 2007. Dispon vel em https://jhalderm.com/pub/papers/ diebold-ttbr07.pdf. 35

[22] Goldberg, I.; Wagner, D.: Randomness and the Netscape Browser. Dr. Dobbs Journal, 1996. [23] Rivest, R. L.; Wack, J. P.: On the notion of software independence in voting systems. Philosophical Transactions of The Royal Society A 366 (1881), 2008. Dispon vel em http://people.csail.mit.edu/rivest/ pubs.html#Riv08b [24] Grupo 6. Plano de Teste GP6T1 Teste de seguran ca do sistema eletr onico de vota c ao do TSE. Dispon vel em http://www.tse.jus.br/ hotSites/testes-publicos-de-seguranca/arquivos/G6PT1.pdf [25] Tribunal Superior Eleitoral. Elei c oes 2010 Listagem de Hashs. Dispon vel em http://www.tse.jus.br/ arquivos/tse-urna-eletronica-modelo-2009-eleicoes-2010turno-1-e-2-atualizado-em-22-09-2010-991ue09 [26] Tribunal Superior Eleitoral. Sistema OKEY - 1o Turno, 2010. Dispon vel em http://www.tse.jus.br/arquivos/tse-chaves-das-u.f. s-eleicoes-2010-turno-1-e-2-991okey [27] Coluna Seguran ca Digital, por Altieres Rohr. Falha na urna brasileira reproduzia elmente erro de 1995, diz professor. http://g1.globo.com/platb/seguranca-digital/2012/05/28/ falha-na-urna-brasileira-reproduzia-fielmente-erro-de-1995 -diz-professor/ [28] Hong, J.; Sarkar, P.: New Applications of Time Memory Data Tradeos. ASIACRYPT 2005: 353-372. [29] National Institute of Standards and Technology. FIPS 197 Advanced Encryption Standard (AES), 2001. Dispon vel em http://csrc.nist. gov/publications/fips/fips197/fips-197.pdf [30] National Institute of Standards and Technology. Recommendation for Block Cipher Modes of Operation, 2001. Dispon vel em http://csrc. nist.gov/publications/nistpubs/800-38a/sp800-38a.pdf [31] National Institute of Standards and Technology. FIPS 180-2 Secure Hash Standard (SHS), 2002. Dispon vel em http://csrc.nist.gov/ publications/fips/fips180-2/fips180-2.pdf [32] Stevens, M.: New collision attacks on SHA-1 based on optimal joint local-collision analysis. EUROCRYPT 2013. [33] National Institute of Standards and Technology. NIST comments on Cryptanalytic Attacks on SHA-1, 2006. http://csrc.nist.gov/ groups/ST/hash/statement.html 36

[34] Wheeler, D.: Flawnder. Dispon vel em http://www.dwheeler.com/ flawfinder/ [35] Presid encia da Rep ublica. Lei No 12.034, de 29 de Setembro de 2009. Dispon vel em http://www.planalto.gov.br/ccivil_03/ _ato2007-2010/2009/lei/l12034.htm

37