Saltar para: Posts [1], Pesquisa [2]

Anders Bateva

Clippings / recortes de não-ficção: buscando o porquê das coisas.

Anders Bateva

Clippings / recortes de não-ficção: buscando o porquê das coisas.

Urna eletrônica: o voto é secreto mesmo?

Este post consiste de um resumo do artigo a seguir:

Vulnerabilidades no software da urna eletrônica brasileira – Diego F. Aranha, Marcelo Monte Karam, André de Miranda, Felipe Scarel
Universidade de Brasília – 2013

O artigo detalha as conclusões e experimentos feitos pelo grupo, que participou da 2ª edição de Testes Públicos de Segurança da urna eletrônica, evento organizado pelo TSE em 2012.

Durante o evento, foram detectadas vulnerabilidades no software que permitiram a recuperação em ordem dos votos computados. Apresentamos cenários onde as vulnerabilidades permitem a possibilidade de fraude eleitoral e sugestões para se restaurar a segurançaa dos mecanismos afetados.

Este post sobre o artigo foi feito depois o estudo ter sido mencionado em uma palestra do Diego Aranha na CryptoRave 2014, já publicada aqui; daí que fiquei sabendo da existência da publicação. Busquei assim poder pegar, e dar, mais informações sobre o que foi dito naquela ocasião.

Limitações do estudo

Os experimentos foram feitos apenas em software pois os autores do artigo não são especialistas em hardware; também, foram feitos testes apenas em uma pequena parte do código-fonte da urna (durante 5 horas), e excluindo qualquer sistema externo à urna em si (como o totalizador de votos, que soma os votos das urnas), devido a limitações nas regras do evento (até mesmo a formatação como competição), e na disponibilidade de tempo dos autores do artigo. Essas limitações acabaram por permitir que a equipe que publicou o artigo só pudesse testar a identificação do voto do eleitor, e não a possibilidade do voto dado poder ser fraudado (adulterado), como pretendiam.

Sem a possibilidade de se efetuar testes extensos e sem qualquer tipo de restrição, seguindo metodologia cientı́fica, não é possı́vel afirmar que o formato atual do evento colabora significativamente para o incremento da segurança da urna eletrônica. Permite apenas encontrar vulnerabilidades pontuais que permitam ataques de fácil execução, mas com efeitos limitados.

Seção "Resumo"

Já na seção "resumo" do artigo, apresenta-se aproximadamente isto:

  • sigilo fraco do voto: é fácil quebrar o sigilo, ou seja, colocar os votos computados em ordem, permitindo então saber quem votou em quem. Basta ter o resultado público da votação e um acesso mínimo ao código-fonte da urna, aos quais os partidos têm acesso;
  • criptografia sem grande utilidade: a chave criptográfica da urna está na própria urna, em uma parte sem criptografia, e a mesma chave criptográfica é usada para TODAS as urnas do país;
  • hash obsoleto: o algoritmo que gera o hash criptográfico (SHA-1) não deveria ser usado há 6 anos (ou seja, desde 2006), pois já foi avisado que ele não tem segurança suficiente;
  • vulnerável a atacantes internos: o modelo de segurança é focado em ataques externos, mas quem gera mais risco é quem está dentro do esquema de votação;
  • processo de desenvolvimento mal-feito: falhas podem ser inseridas, acidentalmente ou propositalmente, devido a práticas inseguras no desenvolvimento;
  • auto-verificação de integridade: a urna verifica a si mesma para saber se foi adulterada, sendo que, se foi adulterada, o próprio sistema de verificação estaria comprometido. Era necessário ter verificão externa! De qualquer forma, essa verificação só serve para dar certeza de que o programa veio do TSE, não que os milhões de linhas de código funcionam como deveria.
pode-se observar de antemão que vários dos recursos implementados no software da urna eletrônica não representam mecanismos de segurança, mas apenas de ofuscação, não resistindo a colaboradores internos ou atacantes persistentes. Como vários dos problemas encontrados resultam de falhas arquiteturais ou premissas inadequadas de projeto, é improvável que a intervenção pontual em algumas dessas questões resolva as causas fundamentais para a sua ocorrência.

O sigilo do voto

Os testes feitos pela equipe conseguiram pôr na ordem de votação os 950 votos (vereador e prefeito) de 475 eleitores fictícios usados no teste.

Registrar os votos inseridos pelo eleitor de forma desordenada é um procedimento crı́tico para se proteger o sigilo do voto. Fica claro, portanto, que a metodologia da equipe permitiu derrotar o único mecanismo utilizado pela urna eletrônica para proteger o sigilo do voto.

Esse tipo de vulnerabilidade não deixa rastro ou vestígio ao ser abusada, pois não é preciso abrir a urna eletrônica e adulterá-la, basta usar os produtos públicos da votação... Mas não é dada a identidade dos eleitores diretamente, apenas a ordem do voto. As identidades de quem votou precisariam ser adquiridas externamente, para ser feita a correlação. Numa situação de voto de cabresto, em que um agente coloque as pessoas em uma ordem específica, por exemplo, dá pra verificar quem votou em quem.

O problema parte do Registro Digital de Voto (RDV), uma tabela com colunas para os cargos que armazena os números dos candidatos votados, mas fora da ordem de voto. Em 2002, foi instituída a impressão do voto, para permitir a verificação do voto em relação ao sistema eletrônico, mas em 2003 foi extinguido, e trocado pelo RDV. O RDV existe para permitir verificar que o Boletim de Urna (BU), que entrega o resultado parcial da urna, está certo, mas isso é inútil, pois é o mesmo software que gera tanto o BU quanto o RDV, e por isso a adulteração do programa alteraria ambos os "documentos". Além disso, se implementado errado, permite quebrar o sigilo do voto!

Com a adoção do voto impresso pela Índia, o Brasil permanece como o único paı́s no mundo a adotar sistema de votação sem verificação independente de resultados.

Números aleatórios

Um bom embaralhamento dos resultados, ou seja, um suficientemente aleatório, precisa de rigor criptográfico, e o desenvolvedor precisa de suficiente entendimento de Segurança Computacional para poder perceber isto e fazer certo. O que ocorre é que a urna usa números pseudo-aleatórios, e além disso foi decidido usar o geramento padrão da linguagem C: rand()/srand()! Esse processo de geração não tem qualidade criptográfica, aceita apenas sementes muito curtas, de até 32-bit. Além disso, a semente é simplesmente a combinação hora, minuto e segundo obtida pela função time(), que pega a representação Unix do calendário UTC.

O calendário UTC é um fuso horário que a Era Unix segue, e essa contagem da era é feita em segundos desde o seu começo, representados em um valor de 32-bit (exemplo: 1466404014).

Como o sistema de votação tem que ser ligado entre as 7AM e as 8AM, isso dá 3600s de variação máxima, então 3600 valores diferentes de semente (dia, mês, ano obviamente já são conhecidos por todos, se não, como as pessoas iriam até a urna votar?). Para completar, a semente é publicada no LOG (público para os partidos ao fim da eleição) e na zerésima (imediatamente pública), essa sendo a "comprovação" de que há zero votos na urna no começo da eleição.

Ou seja, qualquer um que pegue a zerésima (pública) saberá a hora, e portanto a semente de geração de números pseudo-aleatórios, e poderá assim determinar a ordem certa dos votos. Tanto o LOG quanto a zerésima são assinados digitalmente, e à mão pelos fiscais, então fica confirmado: 'os números são embaralhados seguindo essa semente!'. O padrão de posições vazias no RDV, mais o total (público) de eleitores que compareceram à votação, permite comparar o resultado da geração de números aleatórios, vendo se coincidem os espaços vazios, ou seja, se foi deduzido certo.

Solução

A forma mais segura para se efetuar a correção é substituir o gerador pseudo-aleatório atualmente utilizado por outro gerador pseudo-aleatório com propriedades estatı́sticas superiores. Exemplos de geradores assim são documentados em padrões e podem ser encontrados em bibliotecas criptográficas de uso geral.

Esse gerador pseudo-aleatório melhorado apenas precisaria de uma semente mais segura, i.e. não algo que está impresso e divulgado em todo lado. Para resultados realmente aleatórios, seria preciso um gerador em hardware, que depende de algum processo físico conhecido. Nada demais também, os modelos de urna fabricados de 2009 em diante já têm uma CPU AMD Geode que faz isto! Note-se que isso não extingue a necessidade de testes para essas soluções também...

VeraCrypt: é possível quebrar a segurança pela memória RAM?

Este post consiste de um resumo do artigo a seguir:

ANÁLISE DA MEMÓRIA DE ACESSO RANDÔMICO: ARQUIVOS MAPEADOS PELO VERACRYPT - Anderson Luís Moreira
Universidade Católica de Brasília - 2015


O VeraCrypt é um sistema de software para a criação e manutenção de volumes criptografados (containers) on-the-fly-encrypted. Ou seja, os dados são criptografados automaticamente antes de serem salvos e decodificados logo após serem carregados, sem intervenção do usuário. Nenhum dado armazenado em um container pode ser lido (descriptografado) sem a utilização das chaves de criptografia corretas, como senha e key-file(s) este último se existir. O software criptografa o sistema de arquivo inteiro, como por exemplo: Nomes de arquivos, nomes de pastas, o conteúdo de cada arquivo, espaço livre, metadados, etc. Os arquivos são automaticamente descriptografados (em memória / RAM) enquanto são lidos ou copiados. Da mesma forma, os arquivos que estão sendo gravados ou copiados para o container VeraCrypt são automaticamente criptografados on-the-fly (antes de serem escritos no disco) na RAM.
— Anderson Luís

O artigo visa analisar se é possível pegar as chaves criptográficas dos containers criados pelo VeraCrypt enquanto este programa está em execução, afinal, a memória RAM (memória temporária volátil) é o único local onde não há criptografia dos dados manipulados pelo programa enquanto ele está em execução. Após ser finalizado, os dados que estavam na RAM podem ser apagados (aleatoriamente) e aí restariam apenas os dados criptografados no disco rígido. Em outros termos, a memória RAM parece ser o ponto mais fraco de todo o processo.

Para copiar a memória RAM do computador periciado, foi usado o programa DumpIt (para Windows), e para copiar uma imagem do disco, o software dcfldd (para UNIX e similares) - criado pelo Laboratório de Forênsica Computacional do Departamento de Defesa dos EUA. Para analisar a memória RAM, foi usado o programa forense código-aberto Volatility. O processo foi feito 4 vezes, para garantir um padrão no funcionamento do VeraCrypt.

De forma relativamente simples, as keyfiles do volume criptografado foram encontradas, com base em comparação de datas de acesso a arquivos e execução de programas - lembrando que isso apenas porquê esses registros foram tirados diretamente da memória RAM - . As keyfiles, conforme a documentação própria do VeraCrypt, são arquivos que, usados em combinação com as senhas, provêem mais segurança à criptografia, pois sem os arquivos certos não é possível montar o volume. Tendo o realizador do estudo encontrado as keyfiles, pôde montar o volume.

Porém, para de fato acessar o volume, é preciso saber também a senha! A senha não é guardada em forma pura, como texto simples, mas como hash. Ou seja, estão codificadas de uma maneira "praticamente impossível" de reverter, só sendo usável se o usuário digitar a mesma senha no programa, este gerar o mesmo hash, comparar com o hash guardado e eles coincidirem. O desenvolvedor do estudo tentou encontrá-la na memória RAM, onde ficaria armazenada, mas observou que o VeraCrypt em particular tem o devido cuidado de sobrescrever esses dados, impedindo que a senha pura ou os hashes sejam encontráveis nesse tipo de análise posterior.

Dentre os fatores que a equipe de desenvolvimento do VeraCrypt se propôs a melhorar [em relação ao TrueCrypt], o tratamento dos dados armazenados temporariamente na memória RAM foi um ponto de fundamental importância para o presente artigo.
— Anderson Luís

A única alternativa a encontrar a senha ou hash seria quebrá-la na força bruta (tentativas sucessivas exaustivas), mas o uso de derivação de chaves torna isso imprático... se o usuário seguiu a boa prática de usar senha adequada. Se a senha for fraca, ainda pode ser possível! Mas é tema para outros estudos...


Você tem interesse por segurança da informação?Então confira também os outros posts sobre este tema!

Licença Creative CommonsO texto deste post de Anders Bateva está licenciado com uma Licença Creative Commons - Atribuição 4.0 Internacional.