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

Anders Bateva

Nonfiction Litblog. Fichamentos / clippings / recortes de não-ficção. Prospecções literárias em: Ciências Sociais; Informática; e Ciências Ambientais.

Anders Bateva

Nonfiction Litblog. Fichamentos / clippings / recortes de não-ficção. Prospecções literárias em: Ciências Sociais; Informática; e Ciências Ambientais.

Firefox ∩ TLS

O Firefox vem, ao longo do tempo, desativando os padrões obsoletos e inseguros de criptografia de HTTPS, limitando-se ao TLS 1.2 e ao TLS 1.3:

2014 - Firefox 34.0 Release Notes:
Disabled SSLv3.
2018 - Firefox 61.0 Release Notes:
Improved security: On-by-default support for the latest draft of the TLS 1.3 specification.
2020 - Firefox 78.0 Release Notes:
We have disabled TLS 1.0 and TLS 1.1 to improve your website connections. Sites that don't support TLS version 1.2 will now show an error page.

Então agora só há criptografia forte?

Não exatamente... O TLS 1.2, lançado em 2008, se mostrava falho em 2018, na época do lançamento do TLS 1.3:

Mozilla Security Blog: TLS 1.3 Published: in Firefox Today August 13, 2018.
TLS 1.3 removes a lot of outdated cryptography:
  • TLS 1.2 included a pretty wide variety of cryptographic algorithms (RSA key exchange, 3DES, static Diffie-Hellman) and this was the cause of real attacks such as FREAK, Logjam, and Sweet32.
  • TLS 1.3 instead focuses on a small number of well understood primitives (Elliptic Curve Diffie-Hellman key establishment, AEAD ciphers, HKDF).

Porquanto o TLS 1.2 ainda seja amplamente empregado na Web, não foi desabilitado por padrão e, de momento, não possui previsão para sê-lo:

Mozilla Security Blog: Removing Old Versions of TLS. October 15, 2018.
TLS Version Usage (August-September 2018)
Version %
TLS 1.0 1.11%
TLS 1.1 0.09%
TLS 1.2 93.12%
TLS 1.3 5.68%

O que se fez até então foi remediá-lo desabilitando pontualmente algumas características dele, a fim de estender a vida útil do mesmo:

Firefox 78.0 Release Notes, June 30, 2020.
As part of our ongoing effort to deprecate obsolete cryptography, we have disabled all remaining DHE-based TLS ciphersuites by default.

Convém lembrar que criptografia forte não é uma panaceia. Ela serve a um dado propósito, e a outros não. É útil para evitar aulteração e quebra do sigilo dos dados enviados/recebidos (se não for burlada de alguma forma), mas não gera anonimato, por exemplo .

Firefox ∋ Modo Somente HTTPS →maior obsolescência do HTTP

Mozilla Security Blog - Firefox 83 introduces HTTPS-Only Mode. November 17, 2020.

The majority of websites already support HTTPS, and those that don’t are increasingly uncommon. Regrettably, websites often fall back to using the insecure and outdated HTTP protocol. Additionally, the web contains millions of legacy HTTP links that point to insecure versions of websites. When you click on such a link, browsers traditionally connect to the website using the insecure HTTP protocol.

[...]

HTTPS-Only Mode [is] a brand-new security feature available in Firefox 83 [(released on November, 17 2020)] [...] [that] ensures that Firefox doesn’t make any insecure connections without your permission. When you enable HTTPS-Only Mode, Firefox tries to establish a fully secure connection to the website you are visiting. Whether you click on an HTTP link, or you manually enter an HTTP address, Firefox will use HTTPS instead.

Once HTTPS becomes even more widely supported by websites than it is today, we expect it will be possible for web browsers to deprecate HTTP connections and require HTTPS for all websites.

Efeitos colaterais

  • For the small number of websites that don’t yet support HTTPS, Firefox will display an error message that explains the security risk and asks you whether or not you want to connect to the website using HTTP.
  • It also can happen, rarely, that a website itself is available over HTTPS but resources within the website, such as images or videos, are not available over HTTPS. Consequently, some web pages may not look right or might malfunction. In that case, you can temporarily disable HTTPS-Only Mode for that site by clicking the lock icon in the address bar.

Muito útil também para se esquivar de vigilância na rede, como, por exemplo, de um administrador de rede cujo firewall não tem a capacidade deep-packet inspection. A criptografia do HTTPS, nesse caso, evitará que as páginas acessadas fiquem registradas no log, ficando registrados apenas os endereços IP dos servidores ou o nome de domínio do site acessado.

Convém ter em mente, porém, que é absolutamente essencial dispor de TLS (criptografia) moderno para o HTTPS fazer alguma diferença, do contrário não passaria de um auto-engano.

GNU Social: como começou

Este post é baseado no artigo What is GNU social and is Mastodon Social a “Twitter Clone”?, por Robek World.

Em 2007, Evan Prodromou desenvolveu o "esqueleto" do que eventualmente se tornaria o GNU Social. Na época de sua concepção, ele era conhecido como Laconica, e era utilizado em um serviço de microblogging chamado Identi.ca. Após ser financiado, Prodromou renomeou Laconica para StatusNet e começou o desenvolvimento do serviço. A ideia por detrás da StatusNet era que qualquer um pudesse baixar o software e rodar seu próprio serviço de microblogging. O nobre objetivo estava embrulhado em estratégia de marca, e buscas corporativas, na esperança de um dia levar o microblog para as massas (tanto marcas quanto indivíduos) tal qual WordPress fez para os blogs.

Várias pessoas contribuíram código para a StatusNet e o projeto cresceu. Em 2010, Prodromou documentou o protocolo OStatus que ele criou e fez a StatusNet usar, e conseguiu levar este protocolo para o W3C, para que fosse mais desenvolvido (o que não ocorreria até 6 anos depois). OStatus tornou-se o padrão sucessor do protocolo OpenMicroBlogging. Esta foi uma grande conquista, pois o OStatus é a tecnologia que o W3C mantém e desenvolve, e é basicamente o procedimento operativo padrão para comunidades coesas de microblog. A maioria destas comunidades OStatus podem comunicar-se umas com as outras (Federação).

Em algum momento por aqui, Matt Lee começou a explorar opções para ferramentas sociais para o GNU FM, e a StatusNet capturou sua atenção. Algum interesse continua a crescer, mas nade demais acontece. Prodromou eventualmente perde seu financiamento em 2012, e o desenvolvimento real da StatusNet parece estar condenada à morte, apesar de continuar um pouco.

Devido ao projeto usar uma licença livre, as pessoas tinham a capacidade de fazer "forks" (ramificações do desenvolvimento), e Mikael Nordfeldth havia feito um fork da StatusNet para um projeto chamado Free Social. O projeto de Mikael era "por diversão", mas após Prodromou ter decidido seguir adiante com o pump.io, Matt e Mikael oferecem a ideia de fundir o projeto StatusNet em um novo, nomeado GNU Social (já que os desenvolvedores em questão eram desenvolvedores e apoiadores do Projeto GNU / Fundação do Software Livre). Mikael continua a manter e dar suporte ao GNU Social em 2017, mas houveram vários forks que constroem por sobre seu próprio trabalho, enquanto tentam seus próprios objetivos.

Existe um rumor de que a Identi.ca era um serviço de microblogging independente, e não federava com os nos StatusNet. Este rumor está errado: a companhia StatusNet fazia ser fácil criar seu nó "nome.status.net", de graça para nós de usuário único, e também provia vários nós com nomes como "240.status.net", "unlimited.status.net", para que se experimentasem diferentes tamanhos de mensagem. Prodromou realmente tentou fazer com que pessoas mesclassem-se com a Federação e saíssem do nó com o nome da empresa. Mas Identi.ca era a face da StatusNet, e continuou crescendo. Não foi até o "pumpocalypse" que sites alternativos como Quitter.se realmente deslanchassem, no grande êxodo da Identi.ca por pessoas que estavam confusas ou não gostavam no novo software (pump.io).

Licença Creative CommonsEste post de Anders Bateva está licenciado com uma Licença Creative Commons - Atribuição-CompartilhaIgual 4.0 Internacional.Baseado no trabalho disponível em Robek.World.

GNU Social: o que é? Porquê usar?

Autora: Mariana Fossatti. Tradução por Anders Bateva.

O que é GNU Social?

O GNU Social é um projeto de rede social que está em desenvolvimento há alguns anos. Originalmente implementado através do serviço Identi.ca, logo evoluiu quando a Free Software Foundation se juntou em seu desenvolvimento. Trata-se de uma rede social de aparência muito similar ao Twitter, porém com algumas vantagens, como a possibilidade de enviar mensagens de mais de 140 caracteres, participar de grupos, e seguir usuários de outras instâncias que utilizem os mesmos padrões abertos.

Diferente do Twitter, que é um serviço centralizado, o GNU Social é um software livre que pode ser instalado em qualquer servidor. Cada instância da rede social inter-opera com as demais de maneira horizontal, formando assim uma rede distribuída onde os participantes não dependem das políticas corporativas de uma única empresa, e aonde a adoção de novas funcionalidades é livre, desde que siga-se os protocolos de comunicação.

Como é de se imaginar, existem muitos serviços "públicos" de GNU Social. Alguns dos mais conhecidos são: Quitter.se, Quitter.es e lamatriz.org; porém, existem muitos outros, que você pode conferir no site Fediverse.org. Mesmo estando em um nó qualquer, é possível conectar-se às demais instâncias e assim inter-conectar-se com os outros usuários também.

Porquê usar?

De que nos interessaria criar um novo perfil em uma outra rede social que tem uma aparência similar ao Twitter? Porquê se dar ao trabalho e tempo?

Em primeiro lugar, porquê na Internet, sempre vamos estar vivendo mudanças e saltos, de uma tecnologia a outra. Se não o fizermos conscientemente e por escolha própria, os donos das grandes plataformas nos obrigarão, de qualquer maneira, a aceitar as mudanças que eles impõe a partir de suas políticas empresariais centralizadas, em termos que não conhecemos nem controlamos. Assim, somar-se à história de uma tecnologia livre, aberta, e descentralizada, como o GNU Social, é abrir uma janela de ar fresco em direção a uma comunicação que podemos controlar mais coletivamente, sob normas comunitárias de netiqueta, e não sob Termos de Uso abusivos, e sob permanente ameaça de censura.

Em segundo lugar, porquê nestas redes sociais distribuídas, estão acontecendo coisas interessantes! Estão somando-se cada vez mais pessoas, e estão se abrindo novos nós nos quais prosperam todo tipo de comunicades, com sua variedade de idiomas e temas a explorar. Entramos em um território livre de algoritmos de personalização, e que assim não podem ser manipulados visando lucros com propaganda. Bem distante dos ruídos impostos pelos grandes meios de massa, das marcas, das celebridades, e dos trolls que inundam o Twitter e Facebook, podemos retomar espaços de comunicação mais adequados para o diálogo real.

Licença Creative CommonsEste post de Anders Bateva está licenciado com uma Licença Creative Commons - Atribuição-CompartilhaIgual 4.0 Não Adaptada.Baseado no trabalho disponível em Ártica Online.

GNU Social: como funciona o OStatus?

Autor: Manuel Ortega. Tradução por Anders Bateva.

Graças ao OStatus, as instâncias do GNU Social não são jardins murados, e se conectam nentre si, permitindo a seus usuários comunicarem-se e seguirem uns aos ouros. OStatus é a engrenagem que dá vida à rede distribuída de nós/servidores do GNU Social. Uma rede distribuída, também conhecida como a «federação», cujas implicações são chave para impulsionar um modelo social totalmente oposto ao de redes centralizadas, como Twitter e Facebook, e ao das descentralizadas também.

Entender como funciona o OStatus facilita que novos desenvolvedores possam unir-se ao projeto e criar novas possibilidades para o GNU Social.

OStatus: as peças da engrenagem

Ostatus combina de forma natural e eficiente um conjunto de peças, protocolos, que permitem implementar comunicações distribuídas na Web:

  • Activity Streams codifica as publicações, atividades e eventos sociais dos usuários nos padrões Atom ou RSS;
  • PubSubHubbub envia, em tempo real, estes feeds a seus assinantes ao redor da Web;
  • Salmon notifica aos usuários sobre as respostas a suas publicações;
  • Webfinger torna fácil encontrar outros usuários na rede de nós.

Ainda que cada um destes protocolos cumpra uma função determinada, veremos como colaboram entre si e ganham sentido ao trabalharem como uma engrenagem dentro de cada nó do GNU Social. Seguiremos agora os passos que o GNU Social dá quando lhe pedimos para assinar os posts de um usuário remoto, ou seja, um usuário que não está cadastrado no próprio nó de quem assina.

Porém, antes de passar à ação, vejamos onde encontrar OStatus dentro do código-fonte do GNU Social:

OStatus no código-fonte do GNU Social

Uma das maravilhas do GNU Social é sua modularidade. E, como não podia ser de outra forma, a implementação do OStatus está encapsulada dentro do plugin OStatus que podemos encontrar no diretório plugins.

O plugin OStatus agrega ao GNU Social um conjunto de bibliotecas, funcionalidades, e rotas para fazer possível a comunicação entre os nós do GNU Social. Vamos seguir os passos do processo de assinatura entre usuários remotos. O ponto de acesso principal para esta opção em qualquer nó do GNU Social é main/ostatussub. Por exemplo, na instância Quitter España, é no endereço https://quitter.es/main/ostatussub.

Esta URL será nosso ponto de partida para dar uma viagem guiada pelo processo de assinatura a usuários remotos. Um processo aonde centramo-nos no trabalho que realiza o protocolo PubSubHubbub.

Iniciamos a viagem até a assinatura

Estando no ponto de partida, main/ostatussub, perante o usuário final o processo não tem grandes segredos: insere-se o endereço do OStatus, usuario@exemplo.net ou https://exemplo.net/usuario, do usuário que deseja-se seguir, e então o GNU Social pede-lhe para confirmar a assinatura, realiza a confirmação e, a partir deste momento, começa a receber todas as publicações do usuário a que foi solicitado seguir, em sua linha do tempo pessoal.

Sigamos estes mesmos passos, mas agora fazendo referência às linhas de código do GNU Social adonde se desenvolve a ação:

    • Executa-se a ação. Quando o usuário aperta o botão «continuar», executa-se uma solicitação POST, que inclui a variável profile, sobre a ação ostatussub implementada pelo plugin OStatus.A partir deste momento o GNU Social lança-se à caça do feed, tudo é um feed, que se esconde por detrás do usuario OStatus que indicamos a ele.
    • Uma URI ou um e-mail? O primeiro a se fazer é confirmar se o usuário introduziu no formulário uma URI ou um usuário em formato de endereço de e-mail. Se o que temos é um usuário OStatus em formato de endereço de e-mail, teríamos que extrair pelo Webfinger. Porém, para este post, vamos a supor que temos uma URI para encontrar o feed que buscamos. A partir deste momento é quando entra en ação o PubSubHubbub.PubSubHubbub permite-nos assinar um feed em tempo real. Não temos que fazer solicitações regulares ao feed para obter as novas publicações, ao invés disto nós é que seremos notificados, e nos será enviado o novo conteúdo, em tempo real, quando o feed se atualizar. Para entender a lógica por detrás do PubSubHubbub recomendo ver este vídeo.Nos passos para implementar PubSubHubbub, o primeiro é descobrir como assinarmos o feed, descobrir qual é o agente (hub) a que temos que pedir que o feed assine. Este hub se encarrega de informar aos assinantes remotos sobre as atualizações dos feeds dos usuários em seu nó. Cada nó do GNU Social tem seu próprio agente (hub).
  • Descobrir o hub. Uma vez que tenhamos a ULR do feed, o GNU Social realiza uma solicitação GET para obter a informação sobre o hub ao qual tem de solicitar assinatura, dá persitência aos dados encontrados (URL do feed, hub do feed, etc), guarda-os na base de dados associados ao usuário OStatus para o qual recebemos uma pedido de assinatura. Terminado este passo, o GNU Social nos apresenta os dados do usuário do qual queremos assinar, e nos pede confirmação.
  • Enviamos solicitação de assinatura ao hub. Uma vez que o usuário confirme a assinatura, o GNU Social dá início ao processo de assinatura. Seguindo a especificação do PubSubHubbub, para solicitar a assinatura a um hub, temos que fazer uma solicitação POST enviando-lhe a seguinte informação: mode=subscribe, topic=, callback=, verify=sync. O "topic" é a URL do feed a que queremos assinar, e "callback" é a URL à qual queremos receber primeiro a chave de confirmação, e a partir daí, as atualizações do feed. Aqui está o código que implesmenta isto no GNU Social. Enviada a solicitação, temos que esperar que o hub faça-nos uma petiação GET com a chave de confirmação.
  • Recebemos a chave desde o hub e voltamos a confirmar.
  • Já estamos seguindo!! A partir deste momento o hub nos vai enviar as atualizações do feed ao qual nós acabamos de assinar, com solicitações à URL do callback que passamo-lho.
Descoberta do hub.
Solicitação de assinatura.
CC0O texto deste post de Anders Bateva está liberado sob domínio público.Baseado no trabalho disponível no blog Las Indias.

Urna eletrônica ∋ voto secreto?

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.

Nuvem de tags (todas as etiquetas)

Arquivo anual

  1. 2021 ...
  2. 2020 (32)
  3. 2019 (15)
  4. 2018 (16)
  5. 2017 (08)
  6. 2016 (02)
  7. 2015 (02)
2012-2014: posts não mantiveram-se

Subscrever por e-mail

A subscrição é anónima e gera, no máximo, um e-mail por dia.