Por 01010001
Nenhuma decisão é apenas técnica, sempre existem implicações sociais e políticas. A Internet é feita de protocolos, e as decisões tomadas para elaboração dos protocolos têm consequências que afetam diretamente a segurança e a usabilidade de cada sistema. A centralização de serviços nas mãos de uma ou poucas entidades pode trazer conforto e usabilidade, mas muitas vezes isso tem um preço em termos de segurança e privacidade. O contrário também é verdadeiro: decisões que visam o aumento da segurança e privacidade muitas vezes têm seu preço em termos de usabilidade e conforto.
Dois exemplos podem ajudar a compreender um pouco as concessões que têm de ser feitas ao buscar fortalecer um ou outro desses aspectos. O aplicativo Signal de mensagens instantâneas tem código aberto e possui diversas funcionalidades focadas na privacidade dos usuários, mas o gerenciamento de grupos é um pouco inconveniente pela falta da figura dos administradores. O ecossistema de e-mails, por sua vez, é federado e permite a participação de qualquer entidade, porém ainda não conseguiu atingir padrões massivos de criptografia ponto a ponto.
Vamos aos exemplos.
As opções pela privacidade no aplicativo Signal
Signal é um aplicativo para celular e computador desktop que desenvolveu um protocolo bem sucedido de criptografia ponta a ponta para mensagens instantâneas. A solução foi tão bem pensada que a organização que desenvolveu o protocolo e o aplicativo foi contratada para implementar o mesmo protocolo no Whatsapp. Até então, o servidor do Whatsapp podia ver todo o conteúdo das mensagens trocadas entre usuários.
Algumas características do Signal não são tão interessantes em termos de privacidade, como por exemplo a centralização do serviço (você tem de usar o servidor do Signal para usar o aplicativo) e a necessidade de uso de um número de telefone para registro (se seu número é associado ao seu CPF então é possível para o Signal saber quem são os usuários do serviço). Essas escolhas foram alguns compromissos conscientes feitos para permitir melhor usabilidade: a centralização do serviço resolve uma série de problemas de autenticação e atualização, e a utilização de números de telefone permite o funcionamento sem necessidade de uma senha e os contatos são facilmente encontrados a partir da agenda. Algumas medidas foram tomadas para minimizar os problemas de privacidade, como por exemplo um protocolo que permite a descoberta de contatos sem que o servidor do Signal fique sabendo quem é contato de quem, além de uma forma, ainda em implementação, de permitir a troca de mensagens sem que o servidor saiba quem está falando com quem.
Mas um dos exemplos que considero mais interessantes é o fato de que os grupos do Signal não têm administrador: simplesmente não existe a figura de alguém que pode tirar pessoas do grupo. Todas as pessoas que participam de um grupo têm os mesmos poderes de incluir outras pessoas, mudar o nome e foto, ou mudar o período de autodestruição de mensagens, mas ninguém consegue tirar ninguém do grupo à força. As únicas opções são: ou uma pessoa sai por livre e espontânea vontade, ou todas as outras pessoas abandonam o grupo e criam um grupo novo sem incluir a pessoa “excluída”.
Esse exemplo é interessante porque a ausência da figura de administrador não é uma escolha explícita por horizontalidade, mas sim uma consequência técnica de uma escolha explícita por privacidade. Funciona assim: a única forma de permitir administradores nos grupos seria manter, no servidor do Signal, um mapeamento dos grupos existentes e dos usuários administradores. O servidor seria a “autoridade” que decidiria se um certo usuário tem ou não poderes para excluir outro. Acontece que o Signal optou por não manter esse tipo de informação nos servidores, e sem isso a consequência é a impossibilidade de existência de uma figura de administrador. Na verdade, o Signal não mantém nenhuma informação sobre os grupos no servidor. É por isso que, ao reinstalar o aplicativo, seus grupos antigos não aparecem (compare com o Whatsapp, por exemplo).
Esse exemplo é uma instância da inerente tensão entre segurança e usabilidade/conforto: o aumento na privacidade dos usuários causado pela opção de não armazenar nenhuma informação sobre grupos no servidor faz com que seja mais inconveniente lidar com a necessidade de retirada de alguém do grupo.
As consequências da federação na especificação do sistema de E-mail
Se já há algo de milagroso no simples fato de que a Internet funciona, maior milagre ainda é o funcionamento do ecossistema de serviços de e-mail. E não é só pela quantidade de SPAM (diferentes estatísticas que mostram que algo entre 45% e 75% de todas as mensagens de e-mail que trafegam na Internet são SPAM). Os desafios vão além e tocam em questões centrais para a segurança da informação como a confidencialidade e autenticidade das mensagens trafegadas.
Os protocolos que definem o serviço de e-mail foram desenvolvidos, desde o começo, para operar de forma federada. Uma estrutura federada, no nível do protocolo, significa que não há uma entidade central que controla o serviço, e que qualquer pessoa pode instalar e manter seu próprio servidor de e-mail, podendo assim enviar e receber mensagens de e-mail para qualquer provedor. No caso dos serviços de e-mail, hierarquias continuam existindo em diversos níveis (por exemplo, usuários dependem de algum provedor para ter sua comunicação estabelecida), porém não há uma entidade central que dite as regras e que seja essencial para o funcionamento de todo sistema. Existem sim assimetrias de poder causadas pelo tamanho de alguns provedores e grande concentração de usuários mas, se um dia os serviços do Gmail caírem, todos os outros provedores continuarão trocando e-mails entre si sem problemas.
Essa é uma das grandes vantagens do ecossistema de serviços de e-mail. Compare, por exemplo, com serviços de mensagem instantânea centralizados como Whatsapp ou o próprio Signal. Nesses casos, para inviabilizar a comunicação basta cortar o acesso a um servidor central. Quando o Whatsapp foi bloqueado no Brasil, as pessoas tiveram de buscar outras formas de continuar se comunicando. Como todas as especificações e padrões para o funcionamento dos serviços de e-mail são abertos, qualquer um pode desenvolver softwares para servidores e usuários, e esses softwares podem ser usados com qualquer provedor de e-mail.
Por outro lado, uma das grandes desvantagens de protocolos abertos e federados como os do e-mail é que o avanço dos padrões é muito mais lento, porque depende de consensos técnicos entre, literalmente, milhares (senão milhões) de pessoas e organizações. Um exemplo são os padrões de criptografia ponto a ponto de e-mail. No início, os padrões de e-mail não tinham nenhum tipo de proteção do conteúdo trafegado. As mensagens eram enviadas sem nenhum tipo de criptografia, totalmente visíveis para qualquer máquina no meio do caminho entre o remetente e o destinatário (pense, por exemplo, nos provedores de conexão e de e-mail de cada um). Com o tempo, diferentes padrões foram surgindo para dar conta de diferentes aspectos de privacidade, mas o desenvolvimento tem sido lento e as consequências de um projeto inicialmente inseguro são sentidas até hoje. Mesmo com a utilização de padrões de criptografia ponto a ponto, os assuntos das mensagens ainda são, por padrão, visíveis para os provedores de e-mail do remetente e destinatário. Apesar de haver propostas, a comunidade ainda encontra dificuldades para decidir coletivamente qual caminho faz mais sentido seguir.
Além da criptografia do conteúdo, outra questão delicada no ecossistema de e-mails é a autenticação dos interlocutores. Quantas vezes você já recebeu e-mails falsos dizendo ser desta ou daquela empresa, deste ou daquele banco? Como já comentado anteriormente, serviços centralizados podem facilmente usar a entidade central como uma “autoridade” que tem o poder de dizer quem é quem no sistema. Mas serviços federados têm que encontrar outras formas de permitir a autenticação das partes entre si. Soluções para e-mail existem, como os padrões OpenPGP e S/MIME, porém dependem de um protagonismo grande dos usuários ou de organizações intermediárias para realizar a distribuição e autenticação de chaves criptográficas. Esses problemas são técnica e socialmente difíceis de resolver e, apesar de haver vários avanços, o caminho ainda é longo e tortuoso.
Moral da história
Existem diversas alternativas de aplicativos de mensagens instantâneas, cada um com diferentes funcionalidades e escolhas de privacidade e usabilidade. Cabe a nós procurar conhecer cada um e experimentar para encontrar aqueles que fazem mais sentido para diferentes situações. Da mesma forma, é importante conhecer um pouco o funcionamento do sistema de e-mails para poder usar essa ferramenta conhecendo suas possibilidades e limitações.
Mais do que dar respostas, o objetivo aqui é ajudar na compreensão da relação entre decisões técnicas e as consequências delas para a privacidade da comunicação. Isso dito, é importante ter em mente que a relação entre segurança/privacidade e usabilidade/conforto é inversamente proporcional. Também, quando nos abstemos de escolher ativamente as ferramentas que utilizamos, então alguém as está escolhendo por nós.
Dica ao escriba do texto:
1. O Signal está hospedado nos EUA,sob o domínio da legislação daquele país, ou seja, basta um “tchan” do FBI para a segurança do aplicativo ser arrombada.
2. Em tempos de computação quantica todo o nosso papo sobre o tem do texto irá pro saco;
3. Se você é um esquerdista que necessita de muita segurança+privacidade, a opção seria um aplicativo Federado, como Riot (matrix.org)
4.Fazer uso de ferramentas desplugadas ainda ajuda (face a face), além do email criptografado.
Boa semana
Kuarup
Vou discordar de Kuarup em alguns pontos.
Riot, assim como Signal e WhatsApp, tem uma infraestrutura de telecomunicações que funciona no modelo “guarde e encaminhe”. Resumindo: a mensagem sai do celular/computador remetente, vai para um servidor central, este servidor guarda a mensagem enquanto localiza o celular/computador destinatário, depois encaminha a mensagem para o celular/computador destinatário. Neste modelo, os pontos de vulnerabilidade são os aparelhos e o servidor.
Nos aparelhos, basta manter um padrão no Signal de apagar a mensagem em uma semana (ou menos, a depender da conversa), ativar a autenticação de dois fatores e colocar uma senha forte, e as vulnerabilidades se reduzem muito. Reduzir não quer dizer eliminar, mas já é um adianto.
Não tem como usuários garantirem a segurança dos servidores. Só dois itens são as únicas soluções para o momento: uma criptografia forte nas mensagens trocadas (para que elas passem criptografadas pelos servidores), e a confiança em quem presta o serviço.
No item “criptografia forte”, tanto o Signal quanto o Riot têm passado em todos os testes e auditorias feitos até o momento. Isto é bom. Deste modo, o FBI pode até aparecer com uma gag order para ter acesso ao servidor, pode inclusive copiar todo o fluxo de mensagens, mas só encontraria dados criptografados.
Me permita um parêntese antes de continuar. Se o “fator FBI”, ou o “fator repressão/legislação” fosse determinante, por exemplo, Riseup também está nos EUA, e ninguém pensa em deixar de usar os serviços do Riseup por causa disto. Comparativamente, Disroot está na Holanda, cujas leis de privacidade não são lá nenhuma maravilha, Autistici está na Itália, com problemas parecidos e sob um governo filofascista… Resumindo: se o “fator repressão/legislação” fosse determinante, ativistas e militantes teriam de abandonar toda e qualquer comunicação eletrônica. É exatamente o que a repressão quer, desarticular todo mundo.
Voltando ao assunto, tem o item “confiança em quem presta o serviço”. Neste ponto, Signal ganha do Riot. Para quem não sabe, o Riot teve seus servidores invadidos em abril de 2019. Vou traduzir um pedaço do comunicado oficial da Matrix sobre a invasão: “Um atacante obteve acesso aos servidores que hospedam o domínio Matrix.org. O intruso teve acesso aos bancos de dados de produção, dando-lhe, potencialmente, acesso a dados não criptografados de mensagens, hashes de senhas e tokens de acesso. Como precaução, se você é um usuário de matrix.org, você deve trocar sua senha agora”. Nem tudo o que reluz é ouro, o Riot já resolveu o problema, mas a falha foi tão primária que deixou a comunidade de segurança com uma pulga atrás da orelha.
Ainda no caso do Riot, como qualquer um pode montar um servidor para este serviço, a Matrix avisou que a brecha de segurança não afetou estes servidores domésticos. Apesar de ideais para quem realmente precisa de privacidade e segurança num nível “paranoia”, os conhecimentos técnicos e o equipamento necessário para tudo funcionar bem tornam esta alternativa restrita somente aos geeks, aos nerds da informática, a um grupo muito restrito, difícil de encontrar mesmo entre ativistas/militantes.
Signal, portanto, ainda é a alternativa mais confiável. O único problema é a necessidade de fornecer número de telefone, e nisto o Riot realmente garante maior privacidade mesmo; mas como o artigo aponta, já estão em curso soluções técnicas para reduzir este risco de segurança.
Sobre computação quântica e criptografia, realmente, agora que a Google conseguiu alcançar o nível da computação quântica com o processador Sycamore, os atuais modelos de criptografia precisam ser atualizados — atualizados, não abandonados. Para quem não entende do assunto, pode-se comparar o Sycamore com o Summit, supercomputador da IBM que era, até o Sycamore, o mais rápido do mundo: o Sycamore realizou em 200 segundos uma tarefa que o Summit levaria 10.000 anos para completar.
(A IBM contesta, mas reconhece que “uma simulação ideal da mesma tarefa pode ser realizada num sistema clássico em dois dias e meio com muito maior fidelidade” — bem mais rápido que os 10 mil anos…)
Apesar de representar um salto adiante na tecnologia, o Sycamore ainda é muito primário dentro de seu próprio campo. Numa escala ontogenética, é como se fosse ainda o embrião recém-fecundado. Numa perspectiva histórica, é como se fosse o lançamento do Sputnik. A computação quântica ainda deve passar por alguns anos de desenvolvimento antes de alguma aplicação prática, talvez décadas, mas como é um campo novo ainda é cedo para estimativas.
Mas vamos supor que o Sycamore já pudesse ser usado hoje para quebrar criptografias. Assim como tem quem preveja usar o algoritmo de Shor para esta tarefa, empresas que têm na segurança seu principal produto, como a Cloudfare e Tutanota, já estão se lançando nas contramedidas. O assunto interessa igualmente a quem trabalha com criptomoedas, porque a computação quântica pode colocar em risco os padrões de criptografia do ecossistema de blockchain; empresas do setor já estão trabalhando para garantir seus modelos de negócio, já havendo inclusive criptomoedas como a Praxxis, que se dizem resistentes à computação quântica. É cedo para jogar a toalha e dizer que a criptografia — e a comunicação segura — “irá pro saco”.
Apesar do pessimismo em outros tópicos, Kuarup acertou em cheio numa coisa: se tem algo importante a dizer, diga pessoalmente. É sempre a melhor solução, inclusive para evitar os ruídos da comunicação digital, que é muito limitada.
Segurança não é ser invencível, é conhecer as falhas e ter respostas para elas. O Passa Palavra está de parabéns com essa série.
A série é bastante didática sobre as questões que se propôs tratar,mas um problema que valeria a pena abordar adiante seria porque os “esquerdistas” são tão relapsos quanto às questões de segurança/privacidade digital, e mais: Por que, àqueles que mais necessitam de segurança+privacidade e muitas vezes de anonimato, seguem usando Google, Facebook, Instagram, Twitter e correlatos,quando existem alternativas sólidas?
Parafraseando o PP, que dia sua estupidez vai embora?
Não encontro justificativas racionais para ver ativistas no whatsapp, organizações e coletivos no Facebook ou Instagram. Só posso deduzir que são objetos do mesmo fetiche que imaginam estar destruindo, ou pouco realistas quanto às condições de vigilância.
Ótimo texto 0101001!