Em mensageiros com criptografia de ponta a ponta (E2E), o usuário é responsável por suas chaves. Quando ele os perde, ele é forçado a redefinir sua conta.

Redefinir uma conta é perigoso. Você apaga as chaves públicas e em todas as conversas se torna um estranho criptográfico. Você precisa restaurar sua identidade e, em quase todos os casos, isso significa uma reunião pessoal e uma comparação de "números de segurança" com cada um dos contatos. Com que frequência você realmente passa por esse teste, que é a única proteção contra o MiTM?

Mesmo se você for sério sobre os números de segurança, verá muitos parceiros de bate-papo apenas uma vez por ano em uma conferência.

Mas isso acontece com pouca frequência, certo?

Com que frequência ocorre uma redefinição? Resposta: na maioria dos aplicativos de bate-papo E2E o tempo todo.

Nesses mensageiros instantâneos, você descarta a criptografia e simplesmente começa a confiar no servidor: (1) sempre que muda para um novo telefone; (2) sempre que um interlocutor mudar para um novo telefone; (3) quando redefinir as configurações de fábrica do telefone; (4) quando qualquer interlocutor fizer um reset nas configurações de fábrica; (5) sempre que você desinstalar e reinstalar o aplicativo ou (6) quando qualquer pessoa com quem você estiver falando desinstalar e reinstalar. Se você tiver dezenas de contatos, uma redefinição ocorrerá a cada poucos dias.

A redefinição ocorre com tanta regularidade que esses aplicativos fingem que isso não é um problema:

Parece que temos uma atualização de segurança! (Mas na verdade não)

É realmente TOFU?

Na criptografia, o termo TOFU ("confiança no primeiro uso") descreve um jogo de azar quando duas partes falam pela primeira vez. Em vez de se encontrar pessoalmente, o mediador é responsável por cada lado ... e, depois que as partes se apresentam, cada lado monitora cuidadosamente as chaves para garantir que nada mudou. Se a chave mudou, cada lado emite um alarme.

Se a chave do host remoto mudar no SSH em tal situação, ela não "funcionará", mas se tornará completamente beligerante:

@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@ @ WARNING: REMOTE HOST IDENTIFICATION HAS CHANGED! @ @@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@ IT IS POSSIBLE THAT SOMEONE IS DOING SOMETHING NASTY! Someone could be eavesdropping on you right now (man-in-the-middle attack)! It is also possible that a host key has just been changed. The fingerprint for the RSA key sent by the remote host is 00:11:22:33:44:55:66:77:88:99:aa:bb:cc:dd:ee:ff Please contact your system administrator. Add correct host key in /Users/rmueller/.ssh/known_hosts to get rid of this message. Offending RSA key in /Users/rmueller/.ssh/known_hosts:12 RSA host key for 8.8.8.8 has changed and you have requested strict checking. Host key verification failed.

Aqui está o comportamento correto. E lembre-se: isso não é TOFU se permitir que você trabalhe mais com um pequeno aviso. Você deve ver uma caveira gigante com ossos cruzados .

Obviamente, esses mensageiros instantâneos alegam que está tudo bem, porque o usuário é avisado. Se ele quiser, ele pode verificar os números de segurança. É por isso que não concordamos:

A verificação não é realizada porque acontece com muita frequência.
Cheque é uma merda.
Mesmo uma pesquisa superficial de nossos amigos preocupados com a segurança mostrou que ninguém está preocupado com esse teste.
Portanto, é apenas confiar no servidor e no SMS (bem, bem!) Novamente, novamente e novamente .
Finalmente, esses aplicativos não devem funcionar dessa maneira. Especialmente ao trocar de dispositivo. Um caso normal típico pode ser tratado sem problemas e com segurança, e quanto mais rara a situação, pior deve parecer. Em um minuto, mostre a solução Keybase.

Pare de chamá-lo de TOFU

Há um ataque muito eficaz. Suponha que Eve queira entrar na conversa existente de Alice e Bob e ficar entre eles. Alice e Bob estão em contato há muitos anos, há muito que passaram no TOFU.

Eve apenas faz Alice pensar que Bob comprou um telefone novo:

Bob (Eve): Ei, ei!

Alice: Ei, Bob! Parece que você tem novos números de segurança.

Bob (Eve): Sim, comprei o iPhone XS, um bom celular, muito satisfeito com ele. Vamos trocar números de segurança no RWC 2020. Ei, você tem seu endereço atual de Caroline? Quero surpreendê-la enquanto estiver em São Francisco.

Alice: Não consigo comparar, vida no Android 4! Sim, Rua Cosy 555.

Portanto, é improvável que a maioria dos mensageiros criptografados obtenha conformidade com TOFU. É mais parecido com o TADA - confie após adicionar dispositivos. Esse é um problema real, não fictício, porque cria a oportunidade de implementação maliciosa em uma conversa pré-existente. No TOFU real, quando alguém estiver interessado em sua conversa, ele não poderá se infiltrar. Com o TADA, isso é possível.

Nas conversas em grupo, a situação é ainda pior. Quanto mais pessoas no bate-papo, mais frequentemente a conta será reinstalada. Em uma empresa de apenas 20 pessoas, isso acontecerá aproximadamente a cada duas semanas, de acordo com nossa estimativa. E todas as pessoas na empresa devem conhecer essa pessoa. Pessoalmente. Caso contrário, o chat inteiro será comprometido por uma toupeira ou hacker.

Solução

Existe uma boa solução que não implique confiança em servidores de chave privada? Achamos que existe: suporte real para vários dispositivos. Isso significa que você gerencia uma cadeia de dispositivos que representam sua identidade. Quando você recebe um novo dispositivo (telefone, laptop, computador de mesa, iPad etc.), ele gera seu próprio par de chaves e o dispositivo anterior o assina. Se você perder o dispositivo, exclua-o de um dos demais. Tecnicamente, essa exclusão é um recall e, nesse caso, também há algum tipo de inversão de chave que ocorre automaticamente.

Como resultado, você não precisa confiar no servidor ou se encontrar pessoalmente quando o interlocutor ou colega recebe um novo dispositivo . Da mesma forma, você não precisa confiar no servidor ou se encontrar pessoalmente quando ele remover o dispositivo, se não foi o último. O único momento em que você precisa receber um aviso é quando alguém realmente perde o acesso a todas as suas configurações. E, neste caso, você verá um aviso sério, como deveria:

Especialmente maximamente feio

Como resultado, muito menos contas são redefinidas e reinstaladas. Historicamente, no Keybase, o número total de complementos e avaliações de dispositivos é dez vezes o número de descargas de conta (você não precisa aceitar nossa palavra, está disponível publicamente na nossa árvore Merkle). Ao contrário de outros mensageiros, podemos mostrar um aviso verdadeiramente aterrador quando você está conversando com alguém que reinstalou recentemente as chaves.

O gerenciamento de dispositivos é uma operação de engenharia complexa que refinamos várias vezes. O dispositivo existente assina as chaves públicas do novo dispositivo e criptografa todos os dados secretos importantes da chave pública do novo dispositivo. Esta operação deve ser executada rapidamente (em um segundo), pois estamos falando sobre o alcance da atenção do usuário. Como resultado, o Keybase usa uma hierarquia de chaves, para que, ao transferir 32 bytes de dados secretos de um dispositivo antigo, o novo dispositivo possa ver todos os dados criptográficos de longa duração (consulte as Perguntas frequentes abaixo para obter mais detalhes). Isso pode parecer um pouco surpreendente, mas esse é exatamente o ponto da criptografia . Ele não resolve seus problemas de gerenciamento de segredos, apenas torna o sistema mais escalável.

A imagem completa da segurança

Agora podemos formular quatro propriedades básicas de segurança para o aplicativo Keybase:

chaves secretas de longa duração nunca deixam os dispositivos nos quais são criadas
suporte completo para vários dispositivos minimiza quedas de conta
a revogação de chave não pode ser adiada ou revertida com intuito malicioso
sigilo direto usando mensagens de tempo efêmeras

Os dois primeiros parecem compreensíveis. Um terço se torna importante em um projeto em que a recuperação do dispositivo é esperada e considerada normal. O sistema deve verificar se os servidores mal-intencionados não podem atrasar as análises de dispositivos, sobre as quais escrevemos anteriormente .

Veja nosso artigo sobre mensagens efêmeras para obter mais informações sobre o quarto recurso de segurança.

Muita criptografia nova, tudo está implementado corretamente?

O Keybase nunca implementou as funções básicas de segurança e nunca a descreveu em artigos científicos. Tivemos que inventar alguns protocolos criptográficos. Felizmente, existem muitos algoritmos criptográficos prontos para uso, padronizados e amplamente utilizados para qualquer situação. Todo o nosso código de cliente está aberto . Teoricamente, qualquer pessoa pode encontrar erros de design ou implementação. Mas queríamos demonstrar a estrutura interna e contratamos a melhor empresa de auditoria de segurança para uma análise completa.

Hoje, apresentamos o relatório do Grupo NCC e somos extremamente encorajados pelos resultados. A Keybase gastou mais de US $ 100.000 em auditoria e o NCC Group contratou especialistas de alto nível em segurança e criptografia. Eles encontraram dois erros importantes em nossa implementação e os corrigimos rapidamente. Esses erros só poderiam aparecer se nossos servidores agissem maliciosamente. Podemos garantir que eles não agirão assim, mas você não tem motivos para acreditar em nós. Essa é a coisa!

Acreditamos que a equipe da NCC fez um excelente trabalho. Respeito ao tempo gasto para entender completamente nossa arquitetura e implementação. Eles encontraram erros sutis que chamaram a atenção de nossos desenvolvedores, embora recentemente tenhamos assistido essa parte da base de código repetidamente. Recomendamos que você analise o relatório aqui ou acesse nossas Perguntas frequentes.

Perguntas frequentes

Como se atreve a atacar um produto XYZ?

Já removemos referências a produtos específicos do artigo.

O que mais?

Estamos orgulhosos de que o Keybase não exija números de telefone e possa verificar criptograficamente os identificadores do Twitter, HackerNews, Reddit e Github se você conhece alguém.

E ... muito em breve ... haverá suporte para o Mastodon.

E os ataques de redirecionamento de telefone?

Muitos aplicativos são suscetíveis a redirecionar ataques. Eve entra em um quiosque em um shopping center e convence Bob, a operadora de celular, a encaminhar o número de telefone de Bob para seu dispositivo. Ou ela convence o representante por telefone. Agora, Eve pode se autenticar nos servidores de mensagens, alegando que ela é Bob. O resultado parece que nosso exemplo de Alice, Bob e Eve é maior, mas ela não precisa penetrar em nenhum servidor. Alguns aplicativos oferecem "bloqueio de registro" para se proteger contra esse ataque, mas, por padrão, são irritantes.

Ouvi o Keybase enviar algumas chaves privadas para o servidor?

Nos primeiros dias (2014 e início de 2015), o Keybase funcionava como um aplicativo da Web PGP, e o usuário podia escolher a função para armazenar suas chaves PGP privadas em nossos servidores, criptografadas com senhas (que a Keybase não sabia).

Em setembro de 2015, introduzimos o novo modelo Keybase. As chaves PGP nunca são usadas (e nunca usadas) no sistema de arquivos ou bate-papo do Keybase.

Como os bate-papos antigos aparecem instantaneamente em novos telefones?

Em alguns outros aplicativos, os novos dispositivos não veem mensagens antigas, pois a sincronização de mensagens antigas pelo servidor é contrária ao sigilo direto. O aplicativo Keybase permite que você designe certas mensagens - ou conversas inteiras - como "efêmeras". Eles são destruídos após um certo tempo e são criptografados duas vezes: uma vez usando chaves de criptografia de bate-papo de longa duração e a outra usando chaves efêmeras que mudam com frequência. Assim, as mensagens efêmeras fornecem sigilo direto e não podem ser sincronizadas entre os telefones.

As mensagens não efêmeras permanecem até que o usuário as exclua explicitamente e sincronize o E2E com os novos dispositivos no estilo Slack, apenas com criptografia! Portanto, quando você adiciona alguém a uma equipe ou adiciona um novo dispositivo para si mesmo, as mensagens são desbloqueadas.

Mais sobre sincronização no próximo parágrafo.

Conte-nos sobre PUKs!

Há dois anos, introduzimos as chaves para usuários (PUK) . A metade pública do PUK é anunciada no sigchain público dos usuários. A metade secreta é criptografada para a chave pública de cada dispositivo. Quando Alice está preparando um novo dispositivo, seu dispositivo antigo conhece a metade secreta de seu PUK e a chave pública do novo dispositivo. Ele criptografa a metade secreta do PUK para a chave pública do novo dispositivo, e o novo dispositivo baixa esse texto cifrado através do servidor. O novo dispositivo descriptografa o PUK e pode acessar imediatamente todas as mensagens de bate-papo de longa duração.

Sempre que Alice se lembra de um dispositivo, ela altera seu PUK, para que todos os seus dispositivos, exceto os mais recentes, recebam um novo PUK.

Esse esquema de sincronização é fundamentalmente diferente do sistema PGP Keybase inicial. Aqui, todas as chaves envolvidas têm 32 bytes de entropia verdadeira; elas não quebram com força bruta no caso de uma invasão do servidor. É verdade que, se o Curve25519 ou o PRNG da Go estiver quebrado, tudo quebrará. Mas a sincronização PUK não faz outras suposições criptográficas significativas.

E as conversas em grandes grupos?

Os grupos tL; dr têm suas próprias cadeias de assinaturas auditadas para alterar funções, adicionar e remover membros.

Os pesquisadores de segurança escreveram sobre ataques fantasmas de usuários em bate-papos em grupo. Se os clientes dos usuários não conseguirem verificar criptograficamente a associação ao grupo, os servidores mal-intencionados poderão incorporar spyware e moles nas conversas em grupo. O Keybase possui um sistema muito confiável na forma de uma função especial de grupos , sobre a qual iremos escrever no futuro.

Você pode falar sobre NCC-KB2018-001?

Acreditamos que esse bug é a descoberta mais significativa da auditoria do NCC. O Keybase usa ativamente estruturas de dados imutáveis para se proteger contra a ambiguidade do servidor somente de acréscimo. No caso de um bug, um servidor honesto pode começar a se esquivar: "Eu disse A antes, mas ocorreu um bug, eu quis dizer B". Mas nossos clientes têm uma política comum de não permitir ao servidor tanta flexibilidade: eles têm exceções codificadas no caso de erros.

Recentemente, também introduzimos o Sigchain V2 : esse sistema resolve os problemas de escalabilidade que não previmos corretamente na primeira versão. Agora, os clientes são mais econômicos com os dados criptográficos que eles extraem do servidor, recebendo apenas uma assinatura do final da cadeia de assinaturas, em vez da assinatura de cada link intermediário. Portanto, os clientes perderam a oportunidade de fazer ciclos em busca de um hash de assinatura específico, mas anteriormente usamos esses hashes para procurar links de cadeia inválidos nesta lista de exceções codificadas. Estávamos nos preparando para o lançamento do Sigchain V2, esquecendo esses detalhes enterrados em várias camadas de abstrações, para que o sistema simplesmente confiasse no campo a partir da resposta do servidor.

Depois que o NCC descobriu esse erro, a correção foi bastante simples: procurando exceções codificadas com um hash de link de cadeia em vez de um hash de assinatura de link de cadeia. O cliente sempre pode calcular diretamente esses hashes.

Também podemos atribuir esse erro à complexidade adicional necessária para oferecer suporte ao Sigchain V1 e Sigchain V2 simultaneamente. Clientes modernos gravam links Sigchain V2, mas todos os clientes devem suportar links herdados v1 por um tempo ilimitado. Lembre-se de que os clientes assinam links com suas chaves privadas para cada dispositivo. Não podemos coordenar todos os clientes que substituem os dados históricos em um período de tempo razoável, pois esses clientes podem simplesmente ficar offline.

Você pode falar sobre o NCC-KB2018-004?

Como em 001 (veja acima), fomos desapontados por uma certa combinação de suporte simultâneo a soluções desatualizadas e otimização, que parecia importante à medida que ganhamos mais experiência trabalhando com o sistema.

No Sigchain V2, reduzimos o tamanho das cadeias em bytes para reduzir a largura de banda necessária para procurar usuários. Essa economia é especialmente importante em telefones celulares. Assim, codificamos links de cadeia com o MessagePack , não com o JSON , o que proporciona uma boa economia. Por sua vez, os clientes assinam e verificam assinaturas nessas cadeias. Pesquisadores da NCC descobriram maneiras complicadas de criar "assinaturas" que se parecem com JSON e MessagePack ao mesmo tempo, levando a um conflito. Involuntariamente, introduzimos essa ambiguidade de decodificação durante a otimização quando trocamos os analisadores JSON do analisador Go padrão para um mais eficiente. Esse analisador rápido ignorou silenciosamente um monte de lixo antes de encontrar o JSON real, que incluía esse recurso de ataque poliglota. O erro foi corrigido pela verificação de entrada adicional .

No Sigchain V2, também aceitamos a sugestão de Adam Langley de que os assinantes precedem seus pacotes com assinaturas pelo prefixo da linha de contexto e pelo byte \0 para que os verificadores não se confundam com as intenções do assinante. No lado de verificação dessa idéia de prefixo de contexto, houve erros que podem levar a outros ataques poliglotas. Corrigimos rapidamente essa falha com uma lista de permissões .

Após corrigir os dois erros, o servidor rejeita as cargas maliciosas do ataque poliglota, portanto, a exploração dessas vulnerabilidades é possível apenas com a ajuda de um servidor comprometido.

Onde está a documentação?

https://keybase.io/docs

Nos próximos meses, dedicaremos mais tempo ao trabalho na documentação.

Você pode contar mais sobre essa declaração da NCC: “No entanto, um invasor pode se recusar a atualizar o sigchain ou reverter o sigchain de um usuário para um estado anterior, truncando os links subsequentes na cadeia”

O Keybase faz uso extensivo de estruturas de dados públicas imutáveis somente para anexos que forçam a infraestrutura do servidor a capturar uma representação verdadeira dos identificadores de usuários. Podemos garantir a recuperação de dispositivos e a remoção de membros do grupo de forma que um servidor comprometido não possa reverter. Se o servidor decidir mostrar uma exibição inconsistente, esse desvio se tornará parte do registro público imutável. Os clientes da Keybase ou um auditor de terceiros podem detectar uma incompatibilidade a qualquer momento após o ataque. Acreditamos que essas garantias excedem em muito as garantias dos produtos concorrentes e são quase ótimas, levando em consideração as limitações práticas de telefones celulares e clientes com poder de computação limitado.

Simplificando, o Keybase não pode inventar assinaturas de outra pessoa. Como qualquer servidor, ele pode armazenar dados. Mas a nossa árvore Merkle transparente foi projetada para armazená-los por um período muito curto e é sempre possível descobrir.

Como o Keybase lida com redefinições de conta?

Quando os usuários do Keybase realmente perdem todos os seus dispositivos (em vez de adicionar novos ou perder alguns), eles precisam redefinir. Depois de redefinir a conta, o usuário é basicamente novo, mas ele tem o mesmo nome de usuário. Ele não pode assinar a "instrução de redefinição" porque perdeu todas as suas chaves. Portanto, o servidor Keybase confirma a instrução não apagável na árvore Merkle, o que significa redefinir. Os clientes forçam a impossibilidade de reverter essas instruções. Em um artigo futuro, mecanismos específicos serão descritos em detalhes.

Este usuário terá que adicionar novamente as verificações de identidade (Twitter, Github, o que for) com as novas chaves.

Um servidor pode simplesmente trocar a folha da árvore Merkle de alguém para anunciar um conjunto de chaves completamente diferente?

Os autores da NCC estão considerando um servidor hostil Keybase que muda completamente a folha da árvore Merkle, substituindo o conjunto de chaves verdadeiras de Bob por um conjunto falso completamente novo. Um servidor atacante tem duas opções. Primeiro, ele pode bifurcar o estado do mundo colocando Bob em um garfo e aqueles que ele quer enganar em outro. Em segundo lugar, ele pode "trapacear" publicando uma versão da árvore Merkle com o conjunto correto de chaves Bob e outras versões com um conjunto falso. Os usuários que interagem regularmente com Bob descobrirão esse ataque, pois verificarão se as versões baixadas anteriormente do histórico de Bob são prefixos válidos das novas versões baixadas do servidor. Os validadores de terceiros que examinam todas as atualizações do Keybase também notarão esse ataque. Se você escrever um validador de Keybase de terceiros que gostamos, podemos oferecer uma recompensa significativa. Consulte max no Keybase. Caso contrário, esperamos planejar em breve a criação de um validador autônomo.

Você pode acreditar no que eu li até o fim?

Leia ou apenas role para baixo?

Base de chave e TOFU verdadeiro