O que a criptografia de ponta a ponta protege, e o que não protege

A criptografia de ponta a ponta (E2EE, na sigla em inglês) é uma das frases mais tranquilizadoras do software, e uma das mais mal compreendidas. O guia Surveillance Self-Defense da EFF a define com precisão: ela “garante que a informação seja transformada em uma mensagem secreta por quem a envia originalmente… e decodificada apenas por seu destinatário final”. Essa é uma garantia forte para o conteúdo da mensagem. Não é uma garantia para tudo mais em uma conversa.

O que a E2EE realmente protege: o conteúdo

Quando um aplicativo de mensagens implementa a criptografia de ponta a ponta corretamente, a empresa que administra o serviço não consegue ler as mensagens que passam pelos próprios servidores dela — só o dispositivo de quem envia e o de quem recebe têm as chaves necessárias para descriptografar. A documentação técnica publicada pelo Signal descreve os mecanismos por trás disso, incluindo o algoritmo Double Ratchet, projetado para que “chaves anteriores não possam ser calculadas a partir de chaves posteriores”: mesmo que uma chave seja exposta em algum momento, as mensagens passadas continuam protegidas, uma propriedade chamada de sigilo futuro (forward secrecy). Essa é a parte da promessa que se sustenta bem quando implementada corretamente, e representa uma diferença significativa em relação a uma mensagem de texto simples ou a um e-mail não criptografado, que qualquer servidor no caminho consegue ler.

O que ela não protege: metadados

O guia da EFF é direto sobre essa lacuna: a criptografia “esconde o conteúdo das suas mensagens, mas não quem está falando com quem, nem quando, nem com que frequência”. Os metadados — quem contatou quem, em que horário, por quanto tempo, de que local — podem ser tão reveladores quanto a própria mensagem. Saber que uma fonte ligou para um jornalista na noite anterior a uma reportagem ser publicada pode identificar essa fonte mesmo sem uma única palavra da conversa ser lida. Alguns serviços trabalham especificamente para reduzir essa exposição: o recurso “remetente lacrado” (sealed sender) do Signal é construído para que os próprios servidores da empresa não precisem saber quem enviou determinada mensagem, apenas para quem ela é entregue, embora a própria documentação do Signal sobre o recurso observe que a resistência a análises de tráfego mais avançadas — usando tempo e endereços IP — continua sendo uma área de trabalho contínuo, não um problema resolvido.

O que ela não protege: os dispositivos nas pontas

A criptografia protege os dados em trânsito entre dois dispositivos. Ela não consegue proteger dados em um dispositivo que esteja, ele mesmo, comprometido. A EFF afirma isso claramente: “se seus dispositivos nas pontas… estiverem comprometidos, suas comunicações criptografadas podem ser comprometidas”. Um aplicativo prejudicial com acesso à leitura de tela, um dispositivo desbloqueado por outra pessoa, ou uma mensagem que o destinatário escolhe capturar em uma imagem de tela ficam fora do que a criptografia consegue resolver — a mensagem foi descriptografada fielmente, exatamente como planejado, para exatamente a pessoa que deveria lê-la, que então fez algo com ela fora do controle de quem a enviou.

O que ela não protege: os backups

Uma conversa criptografada em trânsito não continua criptografada da mesma forma depois de salva. A EFF observa que, se você “armazena automaticamente backups de conversas criptografadas na nuvem”, esses backups podem não carregar a mesma proteção de ponta a ponta que a conversa ao vivo tinha — dependendo do serviço e de suas configurações de backup, um provedor de nuvem (ou qualquer um que comprometa esse provedor, ou seja legalmente obrigado a entregar seu conteúdo) poderia, em tese, ler um backup contra o qual a mensagem original estava protegida. Vale a pena verificar, uma única vez, se os backups de um aplicativo são criptografados de ponta a ponta por padrão ou apenas de forma opcional, em vez de presumir que a configuração mais forte é automática.

Por que essa distinção importa na prática

Para uma fonte ou cliente em risco, “usamos um aplicativo criptografado” não é uma resposta completa à pergunta “estamos seguros”, porque as ameaças mais importantes — ser identificado por padrões de chamadas, ter um celular apreendido e desbloqueado, ou um backup ser entregue sob ordem judicial — ficam, em grande parte, fora do que a criptografia resolve. A próxima aula retoma a peça que faz tudo isso funcionar em primeiro lugar: as chaves e senhas das quais a criptografia depende, e o que acontece quando são perdidas ou expostas.