Meta Revela Arquitetura de Chaves de Backup do WhatsApp: Uma Análise Técnica Profunda
Meta detalha como protege as chaves de backup criptografadas de ponta a ponta do WhatsApp, utilizando HSMs distribuídos e o protocolo OPAQUE. O artigo compara essa abordagem com soluções mais simples e discute as implicações para a privacidade.
MundiX News·24 de maio de 2026·15 min de leitura·👁 4 views
No dia 1º de maio, a Meta publicou um post no Engineering at Meta intitulado "How Meta Is Strengthening End-to-End Encrypted Backups", seguido por uma continuação em 11 de maio sobre o Labyrinth 1.1, a implementação para Android. Após uma leitura atenta de ambos os artigos, consulta ao whitepaper e uma comparação com minhas próprias implementações, decidi analisar a arquitetura apresentada. Este não é um mero resumo de material de marketing, mas sim uma análise técnica aprofundada, explorando o que foi feito, por que foi feito dessa maneira, os desafios enfrentados e os compromissos escolhidos pela Meta, bem como os meus próprios.
É crucial esclarecer o escopo deste artigo. Ele não aborda o criptografia de mensagens em trânsito. Protocolos como Signal Protocol, Double Ratchet e X3DH são padrões estabelecidos e utilizados por todos os mensageiros sérios. O WhatsApp, por exemplo, licencia o Signal Protocol desde 2016. A segurança em trânsito é, portanto, uma questão resolvida. O foco deste artigo recai sobre o próximo elo na cadeia de segurança, que para a maioria dos usuários ainda está comprometido: os backups.
O cenário era o seguinte: ao enviar uma mensagem no WhatsApp, ela era criptografada no seu telefone com uma chave que apenas o destinatário possuía. A mensagem chegava ao servidor do WhatsApp de forma criptografada, impossibilitando a leitura pelo servidor. Em seguida, era transmitida para o dispositivo do destinatário e descriptografada lá. Essa funcionalidade existe desde 2016. No entanto, a história se torna menos robusta a partir daí. Diariamente, o WhatsApp realiza um backup das conversas no iCloud (para iPhones) ou no Google Drive (para Android). Até recentemente, esses backups ficavam desprotegidos nos servidores da Apple ou do Google, o que significava que Apple e Google poderiam, teoricamente, lê-los. Mediante solicitação de autoridades, esses backups eram entregues. Vários casos criminais de grande repercussão nos EUA foram resolvidos com base em backups do iCloud obtidos, contendo conversas do WhatsApp.
Isso criava uma situação paradoxal: o mensageiro oferecia criptografia de ponta a ponta (E2E), mas a segurança do sistema como um todo era falha. Um dos dois interlocutores, quase certamente, realizava um backup na nuvem, permitindo que terceiros tivessem acesso a toda a correspondência através desse backup. Em 2021, a Meta deu seu primeiro passo para resolver essa questão, introduzindo E2E para backups. Na época, li o whitepaper e considerei a abordagem peculiar, com muitas informações deixadas para depois e o componente chave (o fleet de HSMs) descrito em apenas três parágrafos, gerando pouca clareza. Esperei cinco anos por uma análise completa.
Finalmente, em maio de 2026, a Meta apresentou o quadro completo e deu um passo adicional: a distribuição over-the-air (OTA) de chaves públicas do fleet e a auditabilidade independente através da Cloudflare. Vamos analisar essa arquitetura em detalhes.
Modelo de Ameaças Fundamental
Antes de mergulhar na arquitetura, é essencial entender o que exatamente estamos protegendo e contra quem. Existem várias partes interessadas:
O Usuário: Deseja ter acesso ao seu backup após a troca de dispositivo. Se esquecer a senha, deve haver um método de recuperação, mas que não seja tão simples a ponto de permitir que outra pessoa o utilize.
O Provedor de Nuvem (Apple iCloud, Google Drive): Armazena fisicamente o blob de backup criptografado. A ameaça reside na possibilidade de tentarem descriptografar o conteúdo. Se possuírem apenas o blob criptografado sem a chave, são impotentes.
A Meta: Desempenha um papel central em toda a estrutura. A Meta gerencia a infraestrutura de verificação de chaves. Se a arquitetura for projetada de forma que a Meta possa, sozinha, recuperar a chave sem a participação do usuário, isso representa um risco. Uma boa arquitetura garante que a Meta gerencie a infraestrutura, mas não possa descriptografar o conteúdo sem o conhecimento da senha do usuário.
O Estado: A parte mais desafiadora para o projetista do sistema. Um Estado pode apresentar uma ordem judicial à Meta exigindo a entrega da chave. Se a Meta puder entregar, eventualmente o fará. Se a Meta fisicamente não puder, a exigência se torna sem sentido.
O Insider (Funcionário da Meta): Um funcionário com privilégios administrativos. É possível que ele, sozinho ou em grupo, roube as chaves? Este vetor de ataque é frequentemente subestimado.
O objetivo da arquitetura é construir um sistema onde a chave de backup seja conhecida apenas por duas partes: o usuário e o fleet de HSMs. O fleet de HSMs deve ser projetado de tal forma que nem mesmo a Meta, como organização, possa forçá-lo a entregar a chave sem a intervenção do usuário.
Construir um sistema assim é complexo. A Meta o ergueu sobre três componentes principais: o fleet de HSMs como um quorum distribuído, o protocolo OPAQUE para registro e verificação de senhas sem revelá-las, e auditoria independente através da Cloudflare. Vamos detalhar cada componente.
Fleet de HSMs: Por que um único não é suficiente
HSM significa Hardware Security Module. É um dispositivo físico que, internamente, armazena chaves criptográficas e executa operações com elas, mas nunca expõe as chaves externamente. Mesmo o acesso físico à placa não permite a leitura da chave. Internamente, geralmente possuem mecanismos anti-tampering: se houver uma tentativa de violação, as chaves são autodestruídas.
Um único HSM é poderoso, mas insuficiente. Existem vários problemas. Primeiro, um HSM pode falhar fisicamente. Se ele armazena a chave de backup de milhões de usuários e queima, isso representa um dia muito ruim. Segundo, um único HSM é um ponto único de falha e um ponto único de ataque. Se alguém obtiver acesso físico e, de alguma forma exótica, extrair as chaves (teoricamente possível através de canais laterais, ataques térmicos, etc.), terá acesso a tudo.
Por isso, a Meta utiliza não um, mas um fleet de HSMs. Geograficamente distribuído por vários data centers. A operação é replicada através de um consenso majoritário (majority-consensus), o que significa que a confirmação de uma operação requer a concordância da maioria dos nós do fleet. Isso oferece duas garantias: a falha de alguns nós não derruba o serviço, e para comprometer uma chave, é necessário comprometer simultaneamente a maioria dos nós geograficamente dispersos, o que é incomparavelmente mais difícil do que comprometer um único nó.
Cada nó do fleet possui seu próprio par de chaves. A parte pública do par é utilizada pelo cliente WhatsApp para estabelecer uma sessão segura. A parte privada nunca sai do HSM.
Surge a questão: como o cliente WhatsApp sabe que está se comunicando com o fleet de HSMs legítimo da Meta e não com um servidor falso? No WhatsApp, isso é resolvido de forma direta: as chaves públicas do fleet são hardcoded no código do aplicativo. Atualizaram o fleet, atualizam o aplicativo, lançam uma atualização pela loja. Funciona.
No entanto, para o Messenger, essa abordagem não foi adequada. O Messenger altera seus fleets de HSM com mais frequência do que os aplicativos são atualizados. Por isso, em maio de 2026, a Meta introduziu um mecanismo de distribuição OTA de chaves públicas do fleet. E é aqui que a Cloudflare entra em cena.
Cloudflare como Testemunha Independente
Quando um cliente do Messenger se conecta ao fleet de HSMs, o fleet retorna sua chave pública como parte de um "validation bundle". Este bundle é assinado pela Cloudflare e contra-assinado pela própria Meta.
A função da Cloudflare neste cenário é crucial. Se apenas a Meta assinasse o bundle, ela poderia, a seu critério, emitir um bundle com uma chave falsa e apresentá-la ao usuário. O usuário estabeleceria uma sessão segura com um HSM falso, que na verdade pertenceria à Meta ou a um governo, e entregaria sua senha. A Cloudflare, neste esquema, atua como uma testemunha independente. Ela valida independentemente que a chave pertence a uma implantação legítima, assina o bundle e mantém um log de auditoria público de todos os bundles emitidos. Qualquer pesquisador pode verificar quais chaves foram emitidas e se houve alguma substituição.
O truque arquitetural aqui é interessante. Ele não torna a Meta uma parte confiável por si só, mas adiciona uma segunda parte que não tem motivos especiais para conspirar com a Meta para realizar substituições. O log de auditoria é aberto, qualquer um pode observar, e qualquer substituição seria visível. No entanto, a arquitetura possui uma fraqueza: a própria Cloudflare. Se a Cloudflare for comprometida ou coagida a colaborar, todo o sistema falha. Sendo uma empresa americana, a Cloudflare também está sujeita às mesmas intimações que a Meta em casos de segurança nacional. Portanto, a arquitetura protege contra solicitações civis comuns e contra a Meta tentando bisbilhotar, mas não protege totalmente contra mandados FISA (Foreign Intelligence Surveillance Act).
OPAQUE: A Senha que Ninguém Conhece
A parte mais elegante de todo o sistema. A tarefa é a seguinte: o usuário deseja proteger seu backup com uma senha. Ele memorizará essa senha. Ao restaurar em um novo dispositivo, ele digitará a senha e deverá receber a chave do backup. O servidor deve verificar se a senha está correta.
A solução simples seria o servidor armazenar um hash da senha e, ao recebê-la, compará-lo. Se coincidir, ele entrega a chave. Essa é uma má solução, pois se o servidor for comprometido, o hash vaza e pode ser alvo de ataques de força bruta offline. Se o servidor for mal-intencionado, ele pode simplesmente entregar a chave sem verificação. OPAQUE resolve ambos os problemas. É um protocolo de autenticação de senha assimétrica, desenvolvido na academia em 2018 e padronizado pelo IETF em 2024. A ideia básica é simples: o usuário e o servidor realizam uma troca criptográfica, na qual o servidor verifica matematicamente o conhecimento da senha pelo usuário, mas nunca vê ou armazena a senha em si, nem mesmo um hash convencional.
Na arquitetura da Meta, isso funciona da seguinte forma: durante a configuração inicial do backup, o cliente gera uma chave de 256 bits usando um CSPRNG (Cryptographically Secure Pseudo-Random Number Generator). Essa chave precisa ser armazenada de forma que possa ser recuperada posteriormente apenas com o conhecimento da senha. O cliente inicia o registro OPAQUE com o fleet de HSMs: a senha é inserida, valores efêmeros são gerados, um registro especial associado ao dispositivo é armazenado no HSM. A senha em si desaparece, o cliente não a transmite abertamente, e o HSM não a vê.
Ao restaurar em um novo dispositivo, inicia-se a autenticação OPAQUE. O cliente prova ao HSM o conhecimento da senha sem revelá-la. O HSM confirma a validade da prova e emite a chave. Se a senha estiver incorreta, a prova não converge e a chave não é emitida. Ataques de força bruta pela rede são impossíveis, pois o HSM conta as tentativas e bloqueia. Há um detalhe adicional: mesmo que alguém obtenha um dump completo da memória do HSM (o que é quase impossível, mas vamos supor), não obterá a senha e não poderá recuperar as chaves sem realizar a troca OPAQUE com o par de chaves legítimo. O atacante obterá material inútil, do qual nada pode ser extraído sem o conhecimento da senha.
OPAQUE, na minha opinião, é uma das criações mais brilhantes na criptografia aplicada da última década. Para quem deseja se aprofundar, o artigo original é "OPAQUE: An Asymmetric PAKE Protocol Secure Against Pre-Computation Attacks", de Jarecki, Krawczyk, Xu (2018). A padronização está no RFC 9807, de agosto de 2024.
O Que a Meta Não Revelou
Esta é uma parte crítica. Sem ela, seria apenas um comunicado de imprensa, não uma análise.
Segurança Física dos Data Centers: O whitepaper descreve o protocolo, mas não a segurança física dos data centers onde os HSMs estão localizados. Isso é compreensível, pois tais informações são confidenciais e devem permanecer assim. No entanto, isso significa que um insider com acesso físico ainda tem um potencial de ação. Não sabemos quantas pessoas podem acessar os HSMs, quais são os procedimentos de segregação de funções.
Independência da Cloudflare: A Cloudflare, como ponto de independência, só funciona se for realmente independente. Se amanhã for revelado que o CEO da Meta e o CEO da Cloudflare têm acordos privados, ou se ambas as empresas receberem simultaneamente uma ordem secreta do FBI, o esquema falhará. Esta é uma fraqueza inerente a qualquer arquitetura envolvendo duas corporações americanas.
Força da Senha do Usuário: O modelo "senha protege a chave" tem um limite fundamental. Se o usuário definir a senha como "1234", nenhuma criptografia o ajudará. O HSM bloqueia força bruta pela rede, mas se a senha for fraca e o atacante, de alguma forma, obtiver uma cópia offline do registro OPAQUE (através de um insider, de um exploit no HSM), ele poderá tentar um ataque de dicionário. A proteção aqui reside mais em restrições procedimentais do que em resistência criptográfica.
Custo da Arquitetura: A arquitetura da Meta é extremamente cara. Fleets de HSMs em múltiplos data centers, integração com a Cloudflare, auditorias, whitepapers, uma equipe constante de criptógrafos. Tudo isso custa dezenas de milhões de dólares por ano. Para uma grande corporação com um bilhão de usuários, o retorno sobre o investimento se justifica. Para um desenvolvedor solo ou uma equipe pequena, é inviável implementar diretamente.
É neste ponto que faz sentido comparar com a forma como eu resolvo a mesma tarefa.
Como Funciona no ONEMIX
Algumas introduções: ONEMIX é um mensageiro que estou desenvolvendo como desenvolvedor solo. Cliente React Native, backend FastAPI, E2E via Double Ratchet, chamadas de voz e vídeo via WebRTC com LiveKit. Não sou a Meta. Não tenho milhões de dólares para fleets de HSMs em Chicago, Dublin e Singapura com replicação por consenso majoritário. Tenho um servidor alugado e, em perspectiva, um servidor físico na Rússia.
Portanto, minha arquitetura de backup se baseia em um princípio fundamental diferente: não "protegemos bem a chave do servidor", mas sim "não temos a chave do servidor". Isso é chamado de arquitetura server-blind, e os compromissos são exatamente os opostos.
Especificamente: o backup é criptografado no dispositivo do usuário com uma chave de 256 bits gerada localmente. A chave não é enviada a lugar algum. Nem para o servidor, nem para terceiros. O blob de backup criptografado é enviado ao servidor sem a chave. O servidor vê apenas um monte de bytes criptografados e fisicamente não pode fazer nada com ele.
A restauração funciona através de uma recovery phrase. 24 palavras BIP-39, como em carteiras de criptomoedas. O usuário salva essa frase ao configurar pela primeira vez. Em um novo dispositivo, ele a insere novamente, e a partir dela, via PBKDF2 + HKDF, obtém a mesma chave de 256 bits com a qual o backup no servidor é descriptografado.
A abordagem tem uma vantagem óbvia e uma desvantagem igualmente óbvia. Com a vantagem, tudo está claro: eu, como operador do serviço, não posso ler as mensagens de ninguém, pois não tenho nada que possa ser interrogado. O Estado não pode vir até mim com uma ordem judicial e exigir a entrega de chaves. Não tenho nada para entregar. O protocolo OPAQUE não é necessário, pois não há nada para verificar. HSMs não são necessários, pois não há nada para armazenar.
A desvantagem é que, se o usuário perder a recovery phrase, tudo acabou. Nenhuma recuperação via pergunta secreta, nenhum "esqueceu a senha, responda sobre o nome de solteira da mãe", nenhum pedido de suporte. Os chats morrem junto com a frase.
Assim foi planejado. A Meta escolheu um compromisso: o usuário pode se recuperar através da senha, mas o preço é uma infraestrutura complexa de HSMs e Cloudflare, mais uma confiança teórica inabalável na jurisdição americana. Eu escolhi outro: o usuário é o único responsável por suas chaves, mas em troca obtém uma garantia de privacidade real, independente do meu comportamento. Qual abordagem é mais correta depende do modelo de ameaças do usuário. Para um bilhão de pessoas comuns que confundem a senha do e-mail com o PIN do cartão, a abordagem da Meta é melhor. Elas fisicamente não conseguem gerenciar uma recovery phrase. Para o público que busca a máxima garantia, a abordagem do ONEMIX é melhor, pois não há uma terceira parte em quem confiar.
Eu digo honestamente a ambos os tipos de usuários: se você precisa de um mensageiro para a vida comum com recuperação rápida, fique no WhatsApp, eles fazem bem. Se você precisa de um mensageiro para conversas que definitivamente não devem cair em mãos erradas, e você está disposto a guardar 24 palavras, visite onemix.me.
O Que Levar Desta Análise
Para mim, destaco algumas observações técnicas após ler os whitepapers e comparar com meu código:
OPAQUE Vale a Pena: Se você está construindo qualquer sistema onde o usuário deve poder recuperar algum segredo através de uma senha, e o servidor não deve ver a senha, considere o OPAQUE. O RFC 9807 é curto, e existe a biblioteca libopaque para várias linguagens. Para meus casos internos, planejo integrá-lo ao painel administrativo para parar de armazenar hashes de senhas de administradores completamente.
Arquitetura com Testemunha Independente (Cloudflare): Um truque arquitetural poderoso. A Cloudflare inicialmente não se propõe a ser uma parte certificadora independente, mas de fato se torna uma. Esse padrão pode ser usado em qualquer sistema onde duas partes não confiam totalmente uma na outra. Adicionar uma terceira parte que não tem interesse em conspirar torna o esquema muito mais robusto. Estou pensando em algo semelhante para meu servidor de chaves — ainda não implementado, mas a direção é clara.
HSMs Não Apenas para Fintech: Na minha visão, HSMs até recentemente eram associados apenas ao processamento bancário e centros de certificação. A Meta demonstra que, para mensageiros com um bilhão de usuários, eles também são um compromisso razoável. Para escalas menores, existem HSMs de software, como o SoftHSM, que oferecem parte das mesmas garantias sem os custos de capital em hardware.
Server-Blind como Alternativa: Se você pode se dar ao luxo de dizer ao usuário "guarde sua própria recovery phrase", pode construir um sistema fundamentalmente mais simples e seguro do que qualquer fluxo com HSM. Não serve para todos. Bitcoin, MetaMask, Session são construídos dessa forma.
E2E em Trânsito sem E2E em Backup é Metade da Solução: Se seu Double Ratchet funciona perfeitamente, mas o backup é enviado para o armazenamento em nuvem em texto plano, seu E2E funciona apenas entre os dois telefones. Nas pontas, há vazamentos. Backups e armazenamento devem ser tratados com o mesmo nível de seriedade que o trânsito, caso contrário, todo o trabalho em criptografia de trânsito é anulado.
O post da Meta em si é curto, mas o whitepaper referenciado vale a pena para dedicar uma noite. Especialmente se você está construindo algo próprio na área de privacidade e comunicação segura.
Estou construindo há mais de um ano. No meu blog no Habr, publico análises sobre partes específicas do ONEMIX (Double Ratchet, cache de mensagens, escolha da stack para chamadas), e isso, em geral, é um whitepaper aberto em prestações, como o da Meta, mas muito menor. Responderei a perguntas nos comentários e reajo com interesse às críticas de criptógrafos.
No dia 1º de maio, a Meta publicou um post no Engineering at Meta intitulado "How Meta Is Strengthening End-to-End Encrypted Backups", seguido por uma continuação em 11 de maio sobre o Labyrinth 1.1, a implementação para Android. Após uma leitura atenta de ambos os artigos, consulta ao whitepaper e uma comparação com minhas próprias implementações, decidi analisar a arquitetura apresentada. Este não é um mero resumo de material de marketing, mas sim uma análise técnica aprofundada, explorando o que foi feito, por que foi feito dessa maneira, os desafios enfrentados e os compromissos escolhidos pela Meta, bem como os meus próprios.
É crucial esclarecer o escopo deste artigo. Ele não aborda o criptografia de mensagens em trânsito. Protocolos como Signal Protocol, Double Ratchet e X3DH são padrões estabelecidos e utilizados por todos os mensageiros sérios. O WhatsApp, por exemplo, licencia o Signal Protocol desde 2016. A segurança em trânsito é, portanto, uma questão resolvida. O foco deste artigo recai sobre o próximo elo na cadeia de segurança, que para a maioria dos usuários ainda está comprometido: os backups.
O cenário era o seguinte: ao enviar uma mensagem no WhatsApp, ela era criptografada no seu telefone com uma chave que apenas o destinatário possuía. A mensagem chegava ao servidor do WhatsApp de forma criptografada, impossibilitando a leitura pelo servidor. Em seguida, era transmitida para o dispositivo do destinatário e descriptografada lá. Essa funcionalidade existe desde 2016. No entanto, a história se torna menos robusta a partir daí. Diariamente, o WhatsApp realiza um backup das conversas no iCloud (para iPhones) ou no Google Drive (para Android). Até recentemente, esses backups ficavam desprotegidos nos servidores da Apple ou do Google, o que significava que Apple e Google poderiam, teoricamente, lê-los. Mediante solicitação de autoridades, esses backups eram entregues. Vários casos criminais de grande repercussão nos EUA foram resolvidos com base em backups do iCloud obtidos, contendo conversas do WhatsApp.
Isso criava uma situação paradoxal: o mensageiro oferecia criptografia de ponta a ponta (E2E), mas a segurança do sistema como um todo era falha. Um dos dois interlocutores, quase certamente, realizava um backup na nuvem, permitindo que terceiros tivessem acesso a toda a correspondência através desse backup. Em 2021, a Meta deu seu primeiro passo para resolver essa questão, introduzindo E2E para backups. Na época, li o whitepaper e considerei a abordagem peculiar, com muitas informações deixadas para depois e o componente chave (o fleet de HSMs) descrito em apenas três parágrafos, gerando pouca clareza. Esperei cinco anos por uma análise completa.
Finalmente, em maio de 2026, a Meta apresentou o quadro completo e deu um passo adicional: a distribuição over-the-air (OTA) de chaves públicas do fleet e a auditabilidade independente através da Cloudflare. Vamos analisar essa arquitetura em detalhes.
Modelo de Ameaças Fundamental
Antes de mergulhar na arquitetura, é essencial entender o que exatamente estamos protegendo e contra quem. Existem várias partes interessadas:
O Usuário: Deseja ter acesso ao seu backup após a troca de dispositivo. Se esquecer a senha, deve haver um método de recuperação, mas que não seja tão simples a ponto de permitir que outra pessoa o utilize.
O Provedor de Nuvem (Apple iCloud, Google Drive): Armazena fisicamente o blob de backup criptografado. A ameaça reside na possibilidade de tentarem descriptografar o conteúdo. Se possuírem apenas o blob criptografado sem a chave, são impotentes.
A Meta: Desempenha um papel central em toda a estrutura. A Meta gerencia a infraestrutura de verificação de chaves. Se a arquitetura for projetada de forma que a Meta possa, sozinha, recuperar a chave sem a participação do usuário, isso representa um risco. Uma boa arquitetura garante que a Meta gerencie a infraestrutura, mas não possa descriptografar o conteúdo sem o conhecimento da senha do usuário.
O Estado: A parte mais desafiadora para o projetista do sistema. Um Estado pode apresentar uma ordem judicial à Meta exigindo a entrega da chave. Se a Meta puder entregar, eventualmente o fará. Se a Meta fisicamente não puder, a exigência se torna sem sentido.
O Insider (Funcionário da Meta): Um funcionário com privilégios administrativos. É possível que ele, sozinho ou em grupo, roube as chaves? Este vetor de ataque é frequentemente subestimado.
O objetivo da arquitetura é construir um sistema onde a chave de backup seja conhecida apenas por duas partes: o usuário e o fleet de HSMs. O fleet de HSMs deve ser projetado de tal forma que nem mesmo a Meta, como organização, possa forçá-lo a entregar a chave sem a intervenção do usuário.
Construir um sistema assim é complexo. A Meta o ergueu sobre três componentes principais: o fleet de HSMs como um quorum distribuído, o protocolo OPAQUE para registro e verificação de senhas sem revelá-las, e auditoria independente através da Cloudflare. Vamos detalhar cada componente.
Fleet de HSMs: Por que um único não é suficiente
HSM significa Hardware Security Module. É um dispositivo físico que, internamente, armazena chaves criptográficas e executa operações com elas, mas nunca expõe as chaves externamente. Mesmo o acesso físico à placa não permite a leitura da chave. Internamente, geralmente possuem mecanismos anti-tampering: se houver uma tentativa de violação, as chaves são autodestruídas.
Um único HSM é poderoso, mas insuficiente. Existem vários problemas. Primeiro, um HSM pode falhar fisicamente. Se ele armazena a chave de backup de milhões de usuários e queima, isso representa um dia muito ruim. Segundo, um único HSM é um ponto único de falha e um ponto único de ataque. Se alguém obtiver acesso físico e, de alguma forma exótica, extrair as chaves (teoricamente possível através de canais laterais, ataques térmicos, etc.), terá acesso a tudo.
Por isso, a Meta utiliza não um, mas um fleet de HSMs. Geograficamente distribuído por vários data centers. A operação é replicada através de um consenso majoritário (majority-consensus), o que significa que a confirmação de uma operação requer a concordância da maioria dos nós do fleet. Isso oferece duas garantias: a falha de alguns nós não derruba o serviço, e para comprometer uma chave, é necessário comprometer simultaneamente a maioria dos nós geograficamente dispersos, o que é incomparavelmente mais difícil do que comprometer um único nó.
Cada nó do fleet possui seu próprio par de chaves. A parte pública do par é utilizada pelo cliente WhatsApp para estabelecer uma sessão segura. A parte privada nunca sai do HSM.
Surge a questão: como o cliente WhatsApp sabe que está se comunicando com o fleet de HSMs legítimo da Meta e não com um servidor falso? No WhatsApp, isso é resolvido de forma direta: as chaves públicas do fleet são hardcoded no código do aplicativo. Atualizaram o fleet, atualizam o aplicativo, lançam uma atualização pela loja. Funciona.
No entanto, para o Messenger, essa abordagem não foi adequada. O Messenger altera seus fleets de HSM com mais frequência do que os aplicativos são atualizados. Por isso, em maio de 2026, a Meta introduziu um mecanismo de distribuição OTA de chaves públicas do fleet. E é aqui que a Cloudflare entra em cena.
Cloudflare como Testemunha Independente
Quando um cliente do Messenger se conecta ao fleet de HSMs, o fleet retorna sua chave pública como parte de um "validation bundle". Este bundle é assinado pela Cloudflare e contra-assinado pela própria Meta.
A função da Cloudflare neste cenário é crucial. Se apenas a Meta assinasse o bundle, ela poderia, a seu critério, emitir um bundle com uma chave falsa e apresentá-la ao usuário. O usuário estabeleceria uma sessão segura com um HSM falso, que na verdade pertenceria à Meta ou a um governo, e entregaria sua senha. A Cloudflare, neste esquema, atua como uma testemunha independente. Ela valida independentemente que a chave pertence a uma implantação legítima, assina o bundle e mantém um log de auditoria público de todos os bundles emitidos. Qualquer pesquisador pode verificar quais chaves foram emitidas e se houve alguma substituição.
O truque arquitetural aqui é interessante. Ele não torna a Meta uma parte confiável por si só, mas adiciona uma segunda parte que não tem motivos especiais para conspirar com a Meta para realizar substituições. O log de auditoria é aberto, qualquer um pode observar, e qualquer substituição seria visível. No entanto, a arquitetura possui uma fraqueza: a própria Cloudflare. Se a Cloudflare for comprometida ou coagida a colaborar, todo o sistema falha. Sendo uma empresa americana, a Cloudflare também está sujeita às mesmas intimações que a Meta em casos de segurança nacional. Portanto, a arquitetura protege contra solicitações civis comuns e contra a Meta tentando bisbilhotar, mas não protege totalmente contra mandados FISA (Foreign Intelligence Surveillance Act).
OPAQUE: A Senha que Ninguém Conhece
A parte mais elegante de todo o sistema. A tarefa é a seguinte: o usuário deseja proteger seu backup com uma senha. Ele memorizará essa senha. Ao restaurar em um novo dispositivo, ele digitará a senha e deverá receber a chave do backup. O servidor deve verificar se a senha está correta.
A solução simples seria o servidor armazenar um hash da senha e, ao recebê-la, compará-lo. Se coincidir, ele entrega a chave. Essa é uma má solução, pois se o servidor for comprometido, o hash vaza e pode ser alvo de ataques de força bruta offline. Se o servidor for mal-intencionado, ele pode simplesmente entregar a chave sem verificação. OPAQUE resolve ambos os problemas. É um protocolo de autenticação de senha assimétrica, desenvolvido na academia em 2018 e padronizado pelo IETF em 2024. A ideia básica é simples: o usuário e o servidor realizam uma troca criptográfica, na qual o servidor verifica matematicamente o conhecimento da senha pelo usuário, mas nunca vê ou armazena a senha em si, nem mesmo um hash convencional.
Na arquitetura da Meta, isso funciona da seguinte forma: durante a configuração inicial do backup, o cliente gera uma chave de 256 bits usando um CSPRNG (Cryptographically Secure Pseudo-Random Number Generator). Essa chave precisa ser armazenada de forma que possa ser recuperada posteriormente apenas com o conhecimento da senha. O cliente inicia o registro OPAQUE com o fleet de HSMs: a senha é inserida, valores efêmeros são gerados, um registro especial associado ao dispositivo é armazenado no HSM. A senha em si desaparece, o cliente não a transmite abertamente, e o HSM não a vê.
Ao restaurar em um novo dispositivo, inicia-se a autenticação OPAQUE. O cliente prova ao HSM o conhecimento da senha sem revelá-la. O HSM confirma a validade da prova e emite a chave. Se a senha estiver incorreta, a prova não converge e a chave não é emitida. Ataques de força bruta pela rede são impossíveis, pois o HSM conta as tentativas e bloqueia. Há um detalhe adicional: mesmo que alguém obtenha um dump completo da memória do HSM (o que é quase impossível, mas vamos supor), não obterá a senha e não poderá recuperar as chaves sem realizar a troca OPAQUE com o par de chaves legítimo. O atacante obterá material inútil, do qual nada pode ser extraído sem o conhecimento da senha.
OPAQUE, na minha opinião, é uma das criações mais brilhantes na criptografia aplicada da última década. Para quem deseja se aprofundar, o artigo original é "OPAQUE: An Asymmetric PAKE Protocol Secure Against Pre-Computation Attacks", de Jarecki, Krawczyk, Xu (2018). A padronização está no RFC 9807, de agosto de 2024.
O Que a Meta Não Revelou
Esta é uma parte crítica. Sem ela, seria apenas um comunicado de imprensa, não uma análise.
Segurança Física dos Data Centers: O whitepaper descreve o protocolo, mas não a segurança física dos data centers onde os HSMs estão localizados. Isso é compreensível, pois tais informações são confidenciais e devem permanecer assim. No entanto, isso significa que um insider com acesso físico ainda tem um potencial de ação. Não sabemos quantas pessoas podem acessar os HSMs, quais são os procedimentos de segregação de funções.
Independência da Cloudflare: A Cloudflare, como ponto de independência, só funciona se for realmente independente. Se amanhã for revelado que o CEO da Meta e o CEO da Cloudflare têm acordos privados, ou se ambas as empresas receberem simultaneamente uma ordem secreta do FBI, o esquema falhará. Esta é uma fraqueza inerente a qualquer arquitetura envolvendo duas corporações americanas.
Força da Senha do Usuário: O modelo "senha protege a chave" tem um limite fundamental. Se o usuário definir a senha como "1234", nenhuma criptografia o ajudará. O HSM bloqueia força bruta pela rede, mas se a senha for fraca e o atacante, de alguma forma, obtiver uma cópia offline do registro OPAQUE (através de um insider, de um exploit no HSM), ele poderá tentar um ataque de dicionário. A proteção aqui reside mais em restrições procedimentais do que em resistência criptográfica.
Custo da Arquitetura: A arquitetura da Meta é extremamente cara. Fleets de HSMs em múltiplos data centers, integração com a Cloudflare, auditorias, whitepapers, uma equipe constante de criptógrafos. Tudo isso custa dezenas de milhões de dólares por ano. Para uma grande corporação com um bilhão de usuários, o retorno sobre o investimento se justifica. Para um desenvolvedor solo ou uma equipe pequena, é inviável implementar diretamente.
É neste ponto que faz sentido comparar com a forma como eu resolvo a mesma tarefa.
Como Funciona no ONEMIX
Algumas introduções: ONEMIX é um mensageiro que estou desenvolvendo como desenvolvedor solo. Cliente React Native, backend FastAPI, E2E via Double Ratchet, chamadas de voz e vídeo via WebRTC com LiveKit. Não sou a Meta. Não tenho milhões de dólares para fleets de HSMs em Chicago, Dublin e Singapura com replicação por consenso majoritário. Tenho um servidor alugado e, em perspectiva, um servidor físico na Rússia.
Portanto, minha arquitetura de backup se baseia em um princípio fundamental diferente: não "protegemos bem a chave do servidor", mas sim "não temos a chave do servidor". Isso é chamado de arquitetura server-blind, e os compromissos são exatamente os opostos.
Especificamente: o backup é criptografado no dispositivo do usuário com uma chave de 256 bits gerada localmente. A chave não é enviada a lugar algum. Nem para o servidor, nem para terceiros. O blob de backup criptografado é enviado ao servidor sem a chave. O servidor vê apenas um monte de bytes criptografados e fisicamente não pode fazer nada com ele.
A restauração funciona através de uma recovery phrase. 24 palavras BIP-39, como em carteiras de criptomoedas. O usuário salva essa frase ao configurar pela primeira vez. Em um novo dispositivo, ele a insere novamente, e a partir dela, via PBKDF2 + HKDF, obtém a mesma chave de 256 bits com a qual o backup no servidor é descriptografado.
A abordagem tem uma vantagem óbvia e uma desvantagem igualmente óbvia. Com a vantagem, tudo está claro: eu, como operador do serviço, não posso ler as mensagens de ninguém, pois não tenho nada que possa ser interrogado. O Estado não pode vir até mim com uma ordem judicial e exigir a entrega de chaves. Não tenho nada para entregar. O protocolo OPAQUE não é necessário, pois não há nada para verificar. HSMs não são necessários, pois não há nada para armazenar.
A desvantagem é que, se o usuário perder a recovery phrase, tudo acabou. Nenhuma recuperação via pergunta secreta, nenhum "esqueceu a senha, responda sobre o nome de solteira da mãe", nenhum pedido de suporte. Os chats morrem junto com a frase.
Assim foi planejado. A Meta escolheu um compromisso: o usuário pode se recuperar através da senha, mas o preço é uma infraestrutura complexa de HSMs e Cloudflare, mais uma confiança teórica inabalável na jurisdição americana. Eu escolhi outro: o usuário é o único responsável por suas chaves, mas em troca obtém uma garantia de privacidade real, independente do meu comportamento. Qual abordagem é mais correta depende do modelo de ameaças do usuário. Para um bilhão de pessoas comuns que confundem a senha do e-mail com o PIN do cartão, a abordagem da Meta é melhor. Elas fisicamente não conseguem gerenciar uma recovery phrase. Para o público que busca a máxima garantia, a abordagem do ONEMIX é melhor, pois não há uma terceira parte em quem confiar.
Eu digo honestamente a ambos os tipos de usuários: se você precisa de um mensageiro para a vida comum com recuperação rápida, fique no WhatsApp, eles fazem bem. Se você precisa de um mensageiro para conversas que definitivamente não devem cair em mãos erradas, e você está disposto a guardar 24 palavras, visite onemix.me.
O Que Levar Desta Análise
Para mim, destaco algumas observações técnicas após ler os whitepapers e comparar com meu código:
OPAQUE Vale a Pena: Se você está construindo qualquer sistema onde o usuário deve poder recuperar algum segredo através de uma senha, e o servidor não deve ver a senha, considere o OPAQUE. O RFC 9807 é curto, e existe a biblioteca libopaque para várias linguagens. Para meus casos internos, planejo integrá-lo ao painel administrativo para parar de armazenar hashes de senhas de administradores completamente.
Arquitetura com Testemunha Independente (Cloudflare): Um truque arquitetural poderoso. A Cloudflare inicialmente não se propõe a ser uma parte certificadora independente, mas de fato se torna uma. Esse padrão pode ser usado em qualquer sistema onde duas partes não confiam totalmente uma na outra. Adicionar uma terceira parte que não tem interesse em conspirar torna o esquema muito mais robusto. Estou pensando em algo semelhante para meu servidor de chaves — ainda não implementado, mas a direção é clara.
HSMs Não Apenas para Fintech: Na minha visão, HSMs até recentemente eram associados apenas ao processamento bancário e centros de certificação. A Meta demonstra que, para mensageiros com um bilhão de usuários, eles também são um compromisso razoável. Para escalas menores, existem HSMs de software, como o SoftHSM, que oferecem parte das mesmas garantias sem os custos de capital em hardware.
Server-Blind como Alternativa: Se você pode se dar ao luxo de dizer ao usuário "guarde sua própria recovery phrase", pode construir um sistema fundamentalmente mais simples e seguro do que qualquer fluxo com HSM. Não serve para todos. Bitcoin, MetaMask, Session são construídos dessa forma.
E2E em Trânsito sem E2E em Backup é Metade da Solução: Se seu Double Ratchet funciona perfeitamente, mas o backup é enviado para o armazenamento em nuvem em texto plano, seu E2E funciona apenas entre os dois telefones. Nas pontas, há vazamentos. Backups e armazenamento devem ser tratados com o mesmo nível de seriedade que o trânsito, caso contrário, todo o trabalho em criptografia de trânsito é anulado.
O post da Meta em si é curto, mas o whitepaper referenciado vale a pena para dedicar uma noite. Especialmente se você está construindo algo próprio na área de privacidade e comunicação segura.
Estou construindo há mais de um ano. No meu blog no Habr, publico análises sobre partes específicas do ONEMIX (Double Ratchet, cache de mensagens, escolha da stack para chamadas), e isso, em geral, é um whitepaper aberto em prestações, como o da Meta, mas muito menor. Responderei a perguntas nos comentários e reajo com interesse às críticas de criptógrafos.
