Fale sobre o PAKE

Agora vamos falar sobre segurança da informação. Esta publicação é dedicada ao lançamento do curso "Segurança da Informação Criptográfica" , que começará em 30 de maio. Vamos lá

Primeira regra do PAKE: nunca fale sobre o PAKE. A segunda regra do PAKE afirma que a primeira regra não faz sentido, pois o PAKE ou o Password Authenticated Key Exchange (rus. Troca de chaves com autenticação por senha) é uma das tecnologias mais úteis que praticamente nunca é usada em nenhum lugar. Deve ser implementado sempre que possível, mas não tão simples.




Para entender por que estamos falando de bobagens, vejamos um problema real.

Suponha que eu trabalhe com um servidor que armazene senhas de usuários. Existe uma maneira tradicional de armazenar - hash de cada senha de usuário e armazenamento do resultado em um banco de dados de senhas. Há muitas idéias sobre como lidar com o processo de hash. A recomendação mais comum hoje em dia é usar uma função de hash de senha com memória difícil (como scrypt ou argon2 (com um sal exclusivo ) para cada senha) e armazenar o resultado do hash. Existem opiniões diferentes sobre qual função hash usar e se ela pode usar algum valor secreto (chamado de "pimenta" ), mas, por enquanto, não falaremos sobre isso.

Independentemente da abordagem escolhida, todas essas soluções têm um calcanhar de Aquiles:
Quando o usuário retornar para entrar no site, ele ainda precisará enviar sua senha (aberta) ao servidor para que ele faça a verificação .

Essa necessidade pode levar a conseqüências desagradáveis ​​se o servidor estiver comprometido ou se os desenvolvedores cometerem algum erro estúpido. Por exemplo, no início do ano passado, o Twitter pediu a todos os seus usuários (e esses 330 milhões!) Que alterassem senhas - porque a empresa armazenava senhas de texto (sem hash).

No momento, o problema de fazer login não contradiz os benefícios do hash de senha. No entanto, você precisa encontrar uma solução melhor: aquela em que a senha nunca seja enviada ao servidor em texto não criptografado. A ferramenta criptográfica que nos ajudará a conseguir isso é o PAKE e, em particular, um novo protocolo chamado OPAQUE, que abordaremos no final deste artigo.

O que é o PAKE?

O protocolo PAKE, proposto pela primeira vez por Bellovin e Merritt , é um tipo específico de protocolo de troca de chaves . Os protocolos de troca de chaves (ou "contratos de chave") são projetados para ajudar as duas partes (vamos chamá-las de cliente e servidor) a concordar com uma chave compartilhada usando criptografia de chave pública. Os primeiros protocolos de troca de chaves (por exemplo, o clássico Diffie-Hellman ) não eram autorizados, o que os tornava vulneráveis ​​a ataques como o homem do meio . Uma característica distintiva dos protocolos PAKE é que o cliente se autentica no servidor com uma senha. Por razões óbvias, supõe-se que a senha ou seu hash já seja conhecido pelo servidor, o que permite a verificação.

Se isso fosse tudo o que era necessário, os protocolos PAKE seriam fáceis de construir. Mas o que torna o PAKE realmente útil é que ele também fornece proteção por senha do cliente. Uma garantia mais séria pode ser formulada da seguinte maneira: após uma tentativa de entrar no sistema (bem-sucedida ou malsucedida), o cliente e o servidor devem saber apenas se a senha do cliente corresponde ao valor esperado pelo servidor e não há mais informações adicionais. Esta é uma defesa muito boa. De fato, isso não é diferente do que exigimos de uma prova de divulgação zero .

Uma representação idealizada do protocolo PAKE. A entrada de ambos os lados inclui alguma aleatoriedade, que não é mostrada aqui. O bisbilhoteiro não precisa descobrir a chave secreta compartilhada K, que é aleatória e não é uma função da senha.

Obviamente, o problema óbvio com o PAKE é que muitos desenvolvedores não desejam executar o protocolo de “troca de chaves” em primeiro lugar! Eles só querem garantir que o usuário saiba a senha.

O melhor do PAKE é que o caso de uso "somente login" é muito fácil de executar. Suponha que eu tenha um protocolo PAKE padrão que permita que o cliente e o servidor concordem com uma chave comum K. Se ele souber a senha correta (e somente neste caso), tudo o que precisamos implementar é uma verificação simples de que ambas as partes receberam a mesma chave. (Isso pode ser feito, por exemplo, se as partes calcularem alguma função criptográfica e verificarem os resultados.) Assim, o PAKE pode ser útil mesmo que você queira apenas verificar a senha.

SRP: PAKE, sobre o qual o próprio tempo esqueceu

O conceito PAKE parece fornecer uma vantagem óbvia de segurança em relação à abordagem ingênua que usamos hoje para entrar no servidor. E os métodos em si são antigos, no sentido de que o PAKE é conhecido desde 1992! Apesar disso, a luz nunca o viu. Por que isso está acontecendo?

Existem várias razões óbvias. O mais óbvio está relacionado às limitações da Internet: é muito mais fácil colocar um formulário de senha em uma página da Web do que implementar criptografia sofisticada em um navegador. No entanto, essa explicação não é suficiente. Mesmo aplicativos nativos raramente implementam o PAKE para operações de login. Outra explicação possível está relacionada às patentes , embora a maioria já tenha expirado. Para mim, há duas razões prováveis ​​para não ter PAKE:

• Falta de implementações PAKE de alta qualidade em idiomas populares, o que torna difícil o uso;
• Os especialistas em criptografia não transmitem mal a essência e o valor de seu trabalho; portanto, a maioria das pessoas nem sabe que o PAKE existe.

Apesar de eu ter dito que o PAKE não é usado agora, ainda existem exceções às regras.

Há um ótimo protocolo desenvolvido em 1998 por Tom Wu (que não deve ser confundido com Tim Wu), que é chamado de "SRP" (abreviação de "Secure Remote Password"). Na verdade, é apenas um PAKE de três estágios, com algumas funções adicionais que não foram implementadas nos primeiros trabalhos. Até onde eu sei, o SRP difere por ser o protocolo PAKE mais comum no mundo. Darei duas provas desta afirmação:

1. O SRP foi padronizado como TLS ciphersuite e implementado em bibliotecas como, por exemplo, o OpenSSL , embora ninguém pareça usá-lo especialmente.
2. A Apple faz amplo uso do SRP em seu iCloud Key Vault

O segundo fato em si poderia fazer do SRP um dos protocolos criptográficos mais usados ​​no mundo, o número de dispositivos que a Apple carimba é tão grande. E não há nada engraçado.

O fato de a indústria ter aceito o SRP é certamente bom, mas por outro lado, e não muito. Principalmente porque, embora qualquer endosso do PAKE seja legal, o SRP por si só não é a melhor implementação do PAKE. Eu pensei em entrar na selva de discussões sobre SRP, mas esse discurso já estava se arrastando, e discordo da história sobre um protocolo realmente bom, sobre o qual falaremos abaixo. Se você ainda está interessado na discussão sobre SRP, eu trouxe aqui .

Em vez desses detalhes desnecessários, deixe-me escrever um breve resumo dos meus pensamentos sobre SRP:

1. O SRP faz algumas coisas corretamente. Primeiro, ao contrário das versões anteriores do PAKE, você não precisa armazenar a senha bruta no servidor (ou, equivalente, um hash que poderia ser usado por um invasor em vez de uma senha). Em vez disso, o servidor armazena um "verificador", que é uma função unidirecional do hash da senha. Isso significa que um vazamento no banco de dados de senhas não permite que um invasor substitua imediatamente um usuário se ele não realizar mais ataques de dicionário dispendiosos. (O nome técnico para isso é PAKE "assimétrico".)
2. Há notícias melhores, a versão atual do SRP (v4 v6a) ainda não foi invadida!
3. No entanto (não se ofenda com os desenvolvedores), a arquitetura do protocolo SRP é completamente louca e suas versões anteriores foram hackeadas várias vezes - e é por isso que agora temos a versão 6a. Além disso, a "prova de segurança" no artigo de pesquisa original não prova nada .
4. Atualmente, o SRP é baseado em aritmética inteira (final) e, por várias razões (veja a seção 3 acima), sua arquitetura claramente não pode ser transferida para uma curva elíptica. Isso requer mais largura de banda e computação; portanto, o SRP não pode tirar proveito das muitas melhorias de desempenho que desenvolvemos em complementos como o Curve25519 .
5. O SRP é vulnerável a ataques de pré-computação, porque passa o sal do usuário para qualquer invasor que possa iniciar uma sessão SRP. Isso significa que posso solicitar o seu servidor e criar um dicionário de possíveis hashes de senha antes que o servidor seja comprometido.
6. Apesar de todas essas deficiências, o SRP é extremamente simples e também vem com código de trabalho. Além disso, o OpenSSL possui um código de trabalho que até se integra ao TLS, o que facilita a implementação.

De todos esses pontos, o último é quase certamente responsável pelo (relativamente) alto grau de sucesso comercial que o SRP alcançou em relação a outros protocolos PAKE. Ele não é perfeito, mas real. Era isso que eu queria transmitir aos especialistas em segurança criptográfica.

OPAQUE: PAKE nova geração

Quando comecei a pensar no PAKE, há alguns meses, não pude deixar de notar que a maioria das implementações existentes teve um desempenho ruim. Eles tiveram problemas, como no SRP, exigiram que o usuário armazenasse a senha (ou senha efetiva) no servidor ou o "salt" foi mostrado ao invasor, dando a oportunidade de realizar o ataque antes do cálculo.

Então, no início do ano passado, Jarecki, Kravczyk e Xu revelaram ao mundo um novo protocolo chamado OPAQUE . Tem várias vantagens significativas:

1. Pode ser implementado mesmo se houver problemas de Diffie-Hellman e logaritmos discretos. Isso significa que, ao contrário do SRP, ele pode ser facilmente instanciado usando curvas elípticas eficazes.
2. Ainda melhor: OPAQUE não revela sal para um atacante. Ele resolve esse problema usando o "PRF esquecido" para combinar o salt com a senha, para que o cliente não receba o salt e o servidor não receba a senha.
3. OPAQUE trabalha com qualquer função de hash de senha. Como todo o trabalho de hash é realizado no cliente, o OPAQUE pode realmente retirar a carga do servidor, liberando o serviço online, por exemplo, para usar configurações de segurança extremamente volumosas, por exemplo, configurar o scrypt com muita RAM .
4. Em termos de contagem de mensagens e expoente, OPAQUE não é muito diferente do SRP. Mas, como pode ser implementado com parâmetros mais eficientes, é provável que funcione com muito mais eficiência.
5. Diferente do SRP, o OPAQUE possui evidências razoáveis ​​de segurança (em um modelo muito forte).

Existe até uma proposta preliminar da Internet para o OPAQUE, que você pode ler aqui. Infelizmente, no momento não sei nada sobre a qualidade da implementação do código, exceto que já existem várias implementações em potencial. Espero que esse problema seja resolvido em breve.
O protocolo OPAQUE completo está listado abaixo. No restante desta seção, vou falar sobre como isso funciona.

Problema 1: Manter o sal em segredo. Como mencionei acima, o principal problema com as versões anteriores do PAKE é a necessidade de transferir sal do servidor para o cliente (ainda não autenticado). Isso permite que um invasor realize ataques antes da computação, onde pode gerar um dicionário com base nos dados recebidos.

O problema aqui é que o salt geralmente é passado para uma função hash (por exemplo, scrypt) junto com a senha. Intuitivamente, alguém precisa calcular essa função. Se for um servidor, o servidor deverá ver uma senha, que mata qualquer significado. Se este é um cliente, ele precisa de sal.

Teoricamente, você pode solucionar esse problema computando a função de hash de senha usando o protocolo de computação de duas partes seguro (2PC) . Na prática, essas soluções quase certamente serão ineficazes, principalmente porque as funções de hash de senha são complexas e demoradas. Isso aumentará incrivelmente a complexidade de qualquer sistema 2PC.

OPAQUE contorna isso da seguinte maneira. Deixa um hash de senha no lado do cliente, mas não mostra sal. Em vez disso, ele usa um protocolo bidirecional especial chamado PRF esquecido para calcular outro salt (vamos chamá-lo de salt2) para que o cliente possa usar salt2 na função hash, mas não possa acessar o salt original.

Funciona mais ou menos assim:

O servidor armazena "salt" e o cliente possui password.salt2 = PRF (salt, senha); isso é calculado entre o cliente e o servidor usando um protocolo no qual o cliente nunca reconhecerá o salt e o servidor saberá a senha. O cliente recebe salt2K = PasswordHash (salt2, senha) - e tudo isso é considerado no cliente.

A implementação real do PRF esquecido pode ser feita usando vários elementos e expoentes do grupo. Melhor ainda, se o cliente digitar a senha incorreta, o protocolo receberá um valor fictício "salt2", que não diz nada sobre o valor real do sal.

Problema 2: Prova de que o cliente recebeu a chave correta K. É claro que no momento o cliente recebeu a chave K, mas o servidor não tem idéia do que é. O servidor também não sabe se esta é a chave correta.

A solução OPAQUE é baseada na velha idéia de Gentry, Mackenzie e Ramzan . Quando um usuário faz logon no servidor, ele gera uma chave pública e privada confiável para o protocolo de contrato seguro (por exemplo, HMQV) e criptografa a chave privada recebida em K junto com a chave pública do servidor. A cifra autenticada resultante (e chave pública) é armazenada no banco de dados de senhas.

C = Criptografar (K, chave secreta do cliente | chave pública do servidor)


Versão completa do protocolo OPAQUE, trecho do artigo .

Quando o cliente deseja autenticar usando o protocolo OPAQUE, o servidor envia o código C armazenado. Se o cliente digitou a senha correta na primeira fase, ele pode obter K e descriptografar essa cifra. Caso contrário, é inútil. Usando uma chave secreta com fio, ele agora pode executar um protocolo de contrato padrão com uma chave autenticada para concluir o aperto de mão. (O servidor verifica a entrada dos clientes, comparando-os com sua cópia da chave pública do cliente, e o cliente faz o mesmo.)

Agora vamos juntar tudo. Todas essas etapas podem ser combinadas em um protocolo, que possui o mesmo número de etapas do SRP. Se você não prestar atenção às etapas de verificação, será semelhante ao protocolo acima. Em princípio, a ideia é apenas em duas mensagens: uma do cliente e a segunda é enviada de volta ao servidor.

O último aspecto do trabalho da OPAQUE é que ele possui boas evidências de segurança que nos dizem que o protocolo resultante pode ser considerado seguro se tomarmos um ou mais logaritmos discretos em um modelo aleatório da Oracle, que é uma suposição padrão, que aparentemente , ocorre nas configurações com as quais trabalhamos.

Conclusão

Portanto, em resumo, temos uma tecnologia confiável que pode facilitar o processo de uso de senhas e também permite lidar com elas de forma mais eficiente - com muitos parâmetros de hash e mais carga de trabalho no lado do cliente. Por que isso não é usado em todos os lugares? Talvez nos próximos anos tudo mude. O tempo dirá.

De acordo com a tradição estabelecida, aguardamos seus comentários e convidamos você a visitar o dia de portas abertas , que será realizado no dia 27 de maio pela nossa professora, criptoanalista Elena Kirshanova .