Skip to main content
O X Chat é criptografado de ponta a ponta: as mensagens de um usuário, em texto simples, existem apenas em seus dispositivos. Esta página explica como isso funciona.
Esta página é informativa. Você não precisa desse conhecimento para desenvolver (o Chat XDK executa cada operação aqui descrita para você).

O panorama geral

Vamos examinar todo o fluxo, desde a criação da conta até o envio e recebimento de mensagens.
1

Criação da conta

Aqui o Chat XDK gera dois pares de chaves no seu dispositivo:
  • um par de chaves de identidade, para receber segredos
  • um par de chaves de assinatura, para provar autoria
As metades privadas vão para o backup seguro de chaves, que detalhamos mais adiante. O importante aqui é que elas só podem ser recuperadas com o seu código de acesso; o X não consegue recuperá-las.As metades públicas são publicadas no backend do X através da API de chave pública, com uma assinatura amarrando as chaves de identidade e de assinatura entre si.
2

Criação da conversa

Para enviar uma mensagem a você, um remetente gera uma nova chave de conversa, uma chave simétrica que criptografará as mensagens.Ele busca sua chave pública no backend do X, verifica a assinatura sobre ela e criptografa a chave de conversa para a sua chave de identidade.Esta é uma propriedade crucial da criptografia de chave pública: qualquer pessoa pode criptografar para sua chave pública; apenas sua chave privada pode descriptografar, e somente você a detém. Portanto, o X pode armazenar e entregar a cópia criptografada, mas nunca abri-la. (Para os esquemas exatos utilizados, veja o glossário.)Por que não simplesmente criptografar as mensagens diretamente para sua chave pública? Velocidade: a criptografia de chave pública é muito mais custosa do que a criptografia de chave simétrica, então trocar uma chave permite melhor eficiência para as mensagens subsequentes.
3

Troca de mensagens

Quando alguém envia uma mensagem para você, você receberá a chave de conversa, criptografada com sua chave pública de identidade, e as mensagens criptografadas com a chave de conversa.Você usa sua chave privada de identidade para descriptografar a chave de conversa (novamente, apenas você detém essa chave) e, em seguida, usa a chave de conversa resultante para descriptografar as mensagens.De tempos em tempos, as chaves em uma conversa são rotacionadas (uma nova chave simétrica é compartilhada), por diferentes motivos. Portanto, cada chave de conversa tem uma versão, para que os participantes sempre saibam que estão usando a chave correta.
4

Assinatura

A criptografia permite que qualquer pessoa envie uma mensagem que somente você possa descriptografar. A assinatura é, em certo sentido, o oposto: permite que você (e somente você) assine uma mensagem, e que qualquer pessoa verifique a assinatura. Na prática, a chave privada é necessária para assinar, e a chave pública pode ser usada para verificar.No X Chat, todo remetente assina sua mensagem. As assinaturas provam tanto quem assinou a mensagem quanto os bytes exatos assinados, então todos os destinatários podem verificar que exatamente essa mensagem foi o que o remetente digitou. Novamente, o XDK cuida disso para você; cobrimos os detalhes em Assinaturas explicadas.

Juntando tudo

O X Chat combina três ferramentas criptográficas padrão, cada uma fazendo a única tarefa que faz bem:
  1. Uma chave de conversa criptografa mensagens: simétrica, rápida o suficiente para todo o tráfego de mensagens e mídia.
  2. Um par de chaves de identidade entrega chaves de conversa a cada participante sem que mais ninguém (incluindo o X) as veja.
  3. Um par de chaves de assinatura prova autoria: cada mensagem carrega uma assinatura que os destinatários verificam.
O X transporta e armazena apenas texto cifrado e chaves encapsuladas, nada que ele possa abrir. O XDK faz a criptografia; a Chat API registra chaves e movimenta payloads criptografados (Primeiros passos). O elenco completo:

Um exemplo prático

Vamos percorrer o que realmente acontece quando você cria um grupo com Bob e Carol.
1

Gerar a chave de conversa

O XDK gera uma nova chave de conversa aleatória. Até aqui ela existe apenas na memória do seu dispositivo.
2

Buscar e verificar as chaves dos participantes

Seu app busca as chaves públicas de Bob e Carol no backend do X e verifica a assinatura em cada uma. Se uma assinatura não confere, você para; nunca criptografe para uma chave que você não conseguiu verificar.
3

Encapsular a chave para cada participante

O XDK encapsula a chave de conversa três vezes: para a chave pública de identidade de Bob, para a de Carol e para a sua (para que seus outros dispositivos também possam lê-la).
4

Assinar a mudança

O XDK assina um payload que descreve exatamente esta mudança: o grupo, seus membros, as chaves encapsuladas. Criar um grupo requer duas assinaturas de ação; o XDK produz ambas para você.
5

Publicar

Seu app envia via POST as cópias encapsuladas e assinaturas para o X. O servidor armazena três blobs criptografados que ele não pode abrir. Em nenhum momento a chave de conversa em bruto saiu do seu dispositivo!
6

Bob lê

O XDK de Bob desencapsula sua cópia com sua chave privada de identidade, verifica que a mudança de chave veio de você e mantém a chave de conversa em bruto.
Essa é a configuração única. A partir daqui, cada mensagem segue os mesmos dois fluxos: Envio. O XDK criptografa sua mensagem com a chave de conversa atual, assina-a, e seu app envia via POST ambas ao endpoint send message. O X armazena e entrega bytes que ele não pode ler. Recebimento. O texto cifrado chega via webhooks ou um stream de atividades, ou lendo os eventos da conversa para obter o histórico. O XDK verifica primeiro a assinatura do remetente e então descriptografa com sua chave de conversa armazenada (se a chave foi rotacionada, um evento key change entrega sua nova cópia encapsulada). Se a verificação falhar, a mensagem é rejeitada. A implementação está em Primeiros passos e na referência do Chat XDK.

Backup seguro de chaves: armazenamento distribuído de chaves

Dissemos anteriormente que suas chaves privadas são salvas no backup seguro de chaves, recuperáveis somente com seu código de acesso. Vamos ver como isso funciona, porque é a parte sobre a qual as pessoas mais se mostram céticas: como podem chaves ser copiadas em backup sem que o X seja capaz de lê-las?

O problema com o armazenamento tradicional de chaves

Como o backup seguro de chaves resolve isso

O X Chat utiliza o protocolo open-source Juicebox, que combina compartilhamento de segredo com limiar (threshold secret sharing) com proteção por código de acesso. O protocolo completo está especificado lá; a versão resumida: Armazenando (uma vez, na criação da conta). O XDK divide suas chaves privadas em partes (shares) e as distribui a três realms, serviços separados isolados uns dos outros. Todos os três são operados pelo X, então o isolamento por si só não significaria muito. É aí que entra o hardware: dois dos realms residem dentro de hardware security modules (HSMs), hardware resistente a violações que não entregará sua parte a ninguém, nem mesmo a um administrador do X com acesso total ao servidor. Uma parte sozinha não revela nada, e a recuperação requer partes de dois dos três realms, então toda recuperação possível passa por pelo menos um HSM: não há caminho apenas por software até suas chaves. O software do HSM e a key ceremony que o provisionou são publicamente documentados. Recuperando (novo dispositivo). Você digita seu código de acesso, e o XDK prova a cada realm que você o conhece. O protocolo Juicebox torna isso possível sem que o código de acesso jamais saia do seu dispositivo. Cada realm que verifica você libera sua parte de suas chaves e, quando dois dos três respondem, o XDK reconstrói suas chaves no seu dispositivo. Limites de tentativas. Cada realm permite no máximo 20 tentativas incorretas de código de acesso. Na 20ª tentativa incorreta, sua parte da chave é excluída do realm. Isso é imposto por hardware pelos HSMs e protege contra qualquer ataque de força bruta. O resultado: você pode recuperar suas chaves em um novo dispositivo com apenas seu código de acesso, nenhum realm sozinho detém o segredo inteiro, e os realms apoiados em hardware impõem seus limites até mesmo contra o próprio X.
Você não configura nada disso manualmente. O Chat XDK inclui o cliente de backup, e a configuração dos realms chega do backend do X junto com o seu registro de chave pública. O armazenamento e o desbloqueio via código de acesso são chamadas do Chat XDK; veja inicializar com chaves existentes e criar e registrar chaves. Servidores e bots frequentemente pulam o backup e usam um blob de chave exportado; proteja-o como uma senha.

Assinaturas explicadas

A assinatura de cada mensagem oferece aos destinatários duas garantias:
  1. Autenticidade: produzida pelo detentor da chave privada de assinatura do remetente
  2. Integridade: o conteúdo criptografado não foi modificado após a assinatura
Se qualquer coisa no conteúdo assinado mudar, a verificação falha. Claro, essa garantia é forte apenas na medida em que a chave de assinatura permaneça secreta, e é por isso que o armazenamento de chaves importa tanto. No seu app. O XDK assina quando você criptografa e verifica quando você descriptografa. A rejeição acontece em ambas as extremidades: o próprio X Chat rejeita eventos que não consegue verificar, e o XDK faz o mesmo no recebimento, obrigatório por padrão (desabilitar isso não é recomendado). Detalhes: Chat XDK. As assinaturas também cobrem conteúdo citado. Uma resposta embute a mensagem original assinada em bruto que ela cita; quando o Chat XDK descriptografa a resposta, ele verifica essa original embutida e compara a citação com ela, reportando o resultado como reply_preview_validation (Valid / Invalid). Um resultado Invalid significa que a citação não corresponde à original assinada — trate o material citado como não confiável, mesmo que a própria resposta seja verificada separadamente — para que nenhum participante possa atribuir palavras fabricadas a outro.

Mudanças de estado assinadas (assinaturas de ação)

Mensagens não são a única coisa assinada. Toda mudança em uma conversa (criar um grupo, adicionar membros, rotacionar uma chave) também deve carregar assinaturas de ação: o remetente assina um payload descrevendo exatamente o que a mudança faz, e a API rejeita solicitações onde estas estejam ausentes ou malformadas. O XDK as produz para você. Por que o servidor não pode verificar totalmente uma mudança de chave. O servidor nunca detém a chave de conversa em bruto (esse é o ponto), então ele não pode verificar uma assinatura sobre material que ele não pode ver. Ele verifica o que pode, que a descrição assinada corresponde à solicitação, e os destinatários fazem a verificação criptográfica de verdade quando desencapsulam a mudança de chave. Os eventos são imutáveis: um que falhe na verificação é permanentemente inválido. Veja Solução de problemas.

Propriedades de segurança

Aqui está do que o X Chat protege e, tão importante quanto, do que ele não protege.

Do que o X Chat protege

Do que o X Chat não protege, e por quê


Glossário


Próximos passos

Primeiros passos

Implemente chaves, envio e recebimento passo a passo

Referência do Chat XDK

Métodos e tipos do SDK de criptografia

Introdução

Visão geral do produto e arquitetura

Eventos em tempo real

Como eventos criptografados são entregues