- O novo DM criptografado do Twitter(X) (XChat) afirma tecnicamente ser criptografia end-to-end, mas falhas graves de segurança como roubo de chave privada, MITM e exposição de metadados ainda persistem
- Adotou o Libsodium Box (criptografia baseada em chave secreta), mas, por não oferecer forward secrecy e usar uma proteção fraca de chave baseada em PIN de 4 dígitos, extrair a chave privada é relativamente fácil
- Usa o protocolo Juicebox para backup/recuperação de chaves, porém a segurança real depende inteiramente da confiança no backend, e como o Twitter opera diretamente todos os backends, o sharding praticamente perde o sentido
- Como não existe um procedimento out-of-band para autenticação/verificação de chave pública, o Twitter pode trocar chaves via MITM (ataque man-in-the-middle), e os metadados dos usuários continuam expostos
- Ao contrário do Signal, por enquanto há pouca proteção real de privacidade, portanto recomenda-se o Signal como mensageiro criptografado confiável
Análise do novo DM criptografado do Twitter
Contexto e resumo
- O Twitter(X) revelou a nova plataforma de mensagens criptografadas XChat, promovendo-a como desenvolvida em Rust e com uma estrutura criptográfica no estilo Bitcoin
- Porém, ao observar a implementação real, o Twitter continua com uma estrutura que permite acesso à chave privada, MITM e coleta de metadados
- Conclusão: recomenda-se usar Signal; o DM do Twitter(X) não é seguro por limitações fundamentais
Estrutura de criptografia e limitações
1. Método de criptografia
- Usa o box do Libsodium (criptografia de chave pública)
- Não oferece forward secrecy (sigilo futuro): se a chave privada vazar, todas as mensagens anteriores podem ser descriptografadas (ou seja, é mais fraco do que mensageiros modernos como o Signal)
- A implementação real usa não Rust, mas uma biblioteca em C (com binding via jni)
2. Armazenamento e recuperação de chaves (protocolo Juicebox)
- A chave privada gerada no dispositivo é armazenada com o protocolo Juicebox
- A chave é armazenada após ser criptografada com base em um PIN de 4 dígitos, e na recuperação é necessário inserir o PIN
- O servidor não conhece o PIN, mas como ele tem apenas 4 dígitos (10 mil possibilidades), pode ser quebrado rapidamente com brute force em paralelo
- Mesmo aplicando Argon2id com 16 MB de memória e 32 iterações, isso não é um grande obstáculo para um atacante real (menos de 0,2 segundo até em um notebook modesto)
3. Limitações da estrutura de distribuição de chaves (sharding)
- O Juicebox oferece suporte a distribuição entre múltiplos backends (sharding), mas o Twitter opera diretamente os 3 backends
- No fim, é preciso depender completamente da confiança no Twitter durante o processo de recuperação de chaves, sem os benefícios fundamentais de segurança do sharding
- Também não há procedimentos de verificação por hardware, como HSM ou SGX, para comunicação segura com o backend
4. Vulnerabilidades na autenticação/troca de chave pública
- A chave pública da outra parte é recebida apenas pelos servidores do Twitter, sem um meio separado de verificação (out-of-band)
- O Twitter pode, quando quiser, fornecer uma chave pública arbitrária e executar um ataque man-in-the-middle (MITM)
- A própria página oficial de suporte reconhece essa vulnerabilidade e apenas promete melhorias futuras, sem medidas concretas no momento
5. Metadados e outros problemas
- O Twitter consegue saber completamente os metadados, como quem troca mensagens com quem e quando
- Mesmo que a chave privada não seja exposta, os padrões de comunicação do usuário continuam visíveis para a empresa
Conclusão e recomendação
- Devido às limitações de projeto do DM criptografado, ele fica aquém de mensageiros já validados como o Signal em termos de segurança e privacidade reais
- Enquanto o Twitter controlar a chave pública, o keystore e todo o caminho de comunicação, não dá para considerar isso uma criptografia end-to-end genuína
- Recomenda-se fortemente o uso de mensageiros com protocolos abertos e transparentes, como o Signal
1 comentários
Comentários do Hacker News
Sou fã de tudo que Matthew Garrett escreve, mas quero insistir, de forma quase obsessiva, no ponto de que o Signal já oferece suporte a forward secrecy há muito tempo. A ideia moderna de mensageiro seguro surgiu quando o OTR (Borisov e Goldberg) foi um dos primeiros a introduzir o conceito de "perfect forward secrecy" e deniability. Vejo o Signal como o resultado de levar adiante essas ideias e também os aspectos de engenharia delas (criptografia melhor, código melhor, empacotamento melhor). O frustrante é que os novos mensageiros não estão regredindo para um nível "pré-Signal", mas para um nível de segurança anterior a 2001, ou seja, pré-moderno
Há três coisas a lembrar de vários vazamentos do passado. (1) O FBI de fato "forçou" empresas a inserir backdoors em segredo. Também houve menção de que o tribunal da FISA poderia impor multas devastadoras às empresas. (2) Grandes empresas receberam dezenas a centenas de milhões como custo de backdoor. E houve pressão por vários meios, como contratos governamentais ou licenças de exportação. No fim, dá para interpretar isso como uma política de "dinheiro ou arma". (3) No caso do julgamento da Lavabit, o FBI exigiu a entrega das chaves e, ao mesmo tempo, praticamente forçou a empresa a mentir para os clientes. Quando lembro desses casos, suspeito que a criptografia em grandes plataformas muitas vezes é deliberadamente enfraquecida por exigência do governo, ou então implementada de forma frouxa por simples descaso. Até que Patriot Act, FISC, interpretações secretas e práticas relacionadas desapareçam e os infratores sejam punidos, parto do princípio de que a criptografia dentro de um estado policial já foi comprometida pelos Five Eyes
Enquanto as pessoas continuarem instalando apps de PC pela App Store, essa situação retrógrada deve continuar
Se usam ephemeral key, mas não há forward secrecy nem histórico de interação, fico me perguntando o que exatamente isso teria de "estilo bitcoin"
Há uso de criptografia, mas no geral parece um derivado pouco interessante e quase inútil
Ou seja, não tem valor prático real
O próprio Bitcoin também não é um canal de comunicação seguro
Há o ponto de usar derivação de chave baseada em PIN. Mas isso parece mais próximo de uma implementação de backup do que da própria mensageria, então é difícil ver isso como característica essencial
Mencionam o uso de função hash
Compartilhando o link da discussão anterior:
O novo XChat "criptografado" do X também não é muito mais seguro
Ver comentário relacionado
Acho que, se for para criptografar, é melhor usar um software separado e trocar as chaves públicas pessoalmente
Pergunta: vou visitar Pequim em breve e queria saber se dá para usar o Twitter sem VPN
Tenho dúvidas sobre a expressão "Bitcoin style encryption". Pelo que entendo, o Bitcoin na prática depende mais de tecnologia de assinatura criptográfica do que de "encryption" no sentido em que normalmente usamos a palavra
Na prática, esse termo não significa nada; é só um jargão de marketing feito para soar convincente para quem não está familiarizado com a tecnologia
Vale lembrar que a fonte dessa fala em si não é alguém tecnicamente muito profundo
Esse termo foi usado porque já se esperava que causaria repercussão. Dá para interpretar como uma escolha estratégica para atrair mais atenção
Compartilhando um link de vídeo explicativo
https://www.youtube.com/watch?v=sJNK4VKeoBM
É só uma palavra da moda usada para parecer algo "valioso" e estiloso
Fico me perguntando se o verdadeiro XChat (cliente IRC) poderia processar o X-Twitter por violação de marca
http://xchat.org/
Tenho lembranças de quando eu usava IRC na época da transição do XChat para o HexChat. Mas me surpreendi ao saber que o HexChat também foi descontinuado
Notícia do fim do HexChat
Provavelmente até poderia, mas para isso o lado do XChat teria de demonstrar bem o potencial comercial em cada área em que o X estivesse infringindo, e também seria mais fácil se a marca estivesse registrada em cada jurisdição relevante. Caso contrário, seria mais difícil, na opinião do comentário
Um ponto curioso sobre a biblioteca que o Twitter usa (segundo o artigo-fonte) é que o próprio desenvolvedor escreveu na descrição da biblioteca:
"Aviso: biblioteca experimental! Não use isto em produção até que seja revisado. Há grande possibilidade de riscos e bugs"
https://github.com/ionspin/kotlin-multiplatform-libsodium
Impressiona como o poder da marca Twitter é tão forte que, mesmo depois do rebranding, ela ainda não perdeu vitalidade