Cifragem de Ponta a Ponta Sem Compromisso

Nota: Este artigo descreve a arquitetura e design de Mandraki. Algumas recursos discutidas estão sendo lançadas progressivamente e podem ainda não estar disponíveis em todos os planos.

Cifragem de ponta a ponta é uma daquelas recursos que é fácil prometer e difícil entregar apropriadamente. Muitas plataformas de colaboração afirmam oferecer E2EE, mas os detalhes das suas implementações variam enormemente — e os detalhes são onde a segurança vive ou morre.

Este artigo explica como Mandraki implementa cifragem de ponta a ponta, as escolhas de protocolo que fizemos, e os compromissos sobre os quais somos transparentes.

O que cifragem de ponta a ponta realmente significa

Num sistema com cifragem de ponta a ponta, mensagens e mídia são cifradas no dispositivo do remetente e só podem ser desencriptadas nos dispositivos dos destinatários. O servidor que retransmite os dados vê apenas texto cifrado. Não pode ler o conteúdo, mesmo que seja obrigado a fazê-lo por uma ordem judicial, um funcionário trapaceiro, ou uma falha de segurança.

Isto é fundamentalmente diferente de cifragem de transporte (TLS), que protege dados em trânsito entre um cliente e um servidor mas deixa o servidor com acesso a texto simples. É também diferente de cifragem em repouso, que protege dados em disco mas deixa a camada da aplicação com acesso a texto simples durante processamento.

E2EE verdadeiro significa que o servidor não é de confiança por design. É um retransmissor, não um leitor.

O protocolo MLS para mensagens

Para mensagens cifradas, utilizamos o protocolo Messaging Layer Security (MLS), padronizado como RFC 9420 pelo IETF. MLS foi desenhado especificamente para cenários de mensagens em grupo e oferece várias vantagens sobre abordagens mais antigas.

MLS utiliza uma estrutura de acordo de chave baseada em árvore chamada TreeKEM, que permite que um grupo de participantes estabeleça um segredo partilhado eficientemente. Quando um membro adere ou sai de um grupo, o material de chave é atualizado através de uma mensagem Commit que avança a época do grupo. Isto fornece sigilo prospetivo — comprometer as chaves de um membro num ponto no tempo não revela mensagens de épocas anteriores — e segurança pós-compromisso — o grupo recupera segurança após um compromisso assim que o material de chave do membro afetado é rodado.

Cada dispositivo de utilizador carrega pacotes de chaves MLS para o servidor. Estes são pacotes criptográficos de uso único que permitem que outros dispositivos os adicionem a um grupo sem necessitar do dispositivo estar online naquele momento. Quando um pacote de chaves é consumido, o dispositivo deve carregar frescos. O servidor armazena e distribui estes pacotes mas nunca tem acesso ao material de chave privada que contêm.

Os grupos MLS em Mandraki mapeiam para canais e fios de mensagens diretas. Quando envia uma mensagem num canal cifrado, o seu cliente cifra-a utilizando a chave de época atual do grupo. O servidor recebe texto cifrado, armazena-o, e distribui-o aos membros do grupo. Os seus clientes desencriptam-no localmente.

Cifragem SFrame para mídia

Cifrar mídia em tempo real — áudio e vídeo numa chamada em grupo — apresenta desafios diferentes dos de mensagens. A tolerância de latência é medida em milissegundos, não segundos. As taxas de dados são ordens de magnitude superiores. E a mídia passa através de uma Unidade de Encaminhamento Seletivo (SFU), que precisa de encaminhar pacotes para os participantes certos sem conseguir ver o conteúdo.

Utilizamos SFrame (RFC 9605) para cifragem de mídia, aplicado via WebRTC Encoded Transform API. Esta API permite que código JavaScript intercete frames de mídia codificados após codificação mas antes de pacotização, cifre-os, e passe o texto cifrado para a camada de transporte. Na extremidade recetora, os frames são desencriptados após reassembly mas antes de descodificação.

A vantagem chave do SFrame numa arquitetura SFU é que o SFU pode ainda realizar a sua função de encaminhamento — encaminhar pacotes de um participante para outros, tomar decisões adaptativas à largura de banda sobre quais camadas encaminhar — sem nunca ter acesso à mídia de texto simples. O SFU vê frames cifrados e encaminha-os como blobs opacos.

Os compromissos sobre os quais somos honestos

Cifragem de ponta a ponta não é gratuita. Introduz constrangimentos reais que acreditamos que vale a pena reconhecer.

Pesquisa do lado do servidor não é possível em conteúdo E2EE. Se as mensagens são cifradas com chaves que o servidor não detém, o servidor não pode indexá-las para pesquisa. Mandraki aborda isto ao manter um índice de pesquisa cifrado local no cliente utilizando IndexedDB. Isto fornece pesquisa por dispositivo mas não suporta pesquisa de histórico entre dispositivos para mensagens recebidas antes de um dispositivo ser adicionado ao grupo.

Recursos de IA do lado do servidor são mutuamente exclusivos com E2EE. As nossas funcionalidades de transcrição e resumo de IA requerem acesso do lado do servidor a áudio de texto simples. Uma chamada ou canal não pode ter ambas E2EE e recursos de IA ativados simultaneamente. Isto é reforçado arquitetonicamente, não apenas por política. As organizações escolhem ao nível de chamada ou canal qual modelo preferem.

Novos dispositivos veem mensagens apenas a partir do ponto de adesão em frente. Quando adiciona um novo dispositivo à sua conta, pode desencriptar mensagens a partir do momento em que adere ao grupo MLS em frente. As mensagens históricas cifradas sob épocas anteriores não são acessíveis no novo dispositivo. Isto é uma propriedade fundamental do sigilo prospetivo. Estamos a explorar mecanismos de cópia de segurança segura que permitiriam aos utilizadores exportar histórico de mensagens cifradas para um novo dispositivo, mas isto permanece um trabalho em progresso.

Gestão de chaves adiciona complexidade. Cada dispositivo deve manter material de chave, carregar pacotes de chaves frescos, e processar atualizações de estado de grupo. Investimos esforço de engenharia significativo em tornar isto invisível aos utilizadores. O objetivo é que cifragem não seja algo que configure ou pense — acontece simplesmente.

E2EE e cifragem do lado do servidor coexistem

Vale a pena notar que a camada E2EE de Mandraki e a nossa cifragem do lado do servidor de envelope (a hierarquia de chave de três camadas descrita na nossa arquitetura de segurança) servem propósitos complementares. A cifragem do lado do servidor protege dados em repouso na nossa infraestrutura — se um disco é roubado ou uma cópia de segurança de base de dados é comprometida, os dados são ilegíveis sem as chaves de cifragem. E2EE vai mais longe ao assegurar que o servidor nunca vê texto simples em primeiro lugar.

Para organizações que ativam E2EE, ambas as camadas estão ativas simultaneamente. Os dados são cifrados de ponta a ponta pelos clientes e também cifrados em repouso no servidor. Cinto e suspensórios.

Acreditamos que cifragem de ponta a ponta deve ser a predefinição para comunicações sensíveis, não um complemento premium ou uma caixa de seleção que a maioria dos utilizadores nunca encontra. Mandraki torna-a direta de ativar, transparente nas suas limitações, e robusta na sua implementação.