Parlez de PAKE

Parlons maintenant de la sécurité des informations. Cette publication est dédiée au lancement du cours «Cryptographic Information Security» , qui débutera le 30 mai. Allons-y.

Première règle de PAKE: ne parlez jamais de PAKE. La deuxième règle de PAKE stipule que la première règle est un non-sens, car l'échange de clés authentifiées par mot de passe (rus. Échange de clés avec authentification par mot de passe) est l'une des technologies les plus utiles qui n'est pratiquement jamais utilisée nulle part. Il devrait être mis en œuvre dans la mesure du possible, mais pas si simple.




Pour comprendre pourquoi nous parlons de bêtises, regardons un vrai problème.

Supposons que je travaille avec un serveur qui stocke les mots de passe des utilisateurs. Il existe une méthode traditionnelle de stockage - hacher chaque mot de passe utilisateur et stocker le résultat dans une base de données de mots de passe. Il existe de nombreuses idées sur la façon de gérer le processus de hachage. Aujourd'hui, la recommandation la plus courante consiste à utiliser une fonction de hachage de mot de passe en mémoire (comme scrypt ou argon2 (avec un sel unique ) pour chaque mot de passe), puis de stocker le résultat haché. Il existe différentes opinions sur la fonction de hachage à utiliser et si elle peut utiliser une valeur secrète (appelée «poivre» ), mais pour l'instant nous n'en parlerons pas.

Quelle que soit l'approche que vous choisissez, toutes ces solutions ont un talon d'Achille:
Lorsque l'utilisateur revient pour accéder au site, il devra toujours envoyer son mot de passe (ouvert) au serveur pour lui permettre de faire la vérification .

Ce besoin peut entraîner des conséquences désagréables si votre serveur est compromis ou si vos développeurs font une erreur stupide. Par exemple, au début de l'année dernière, Twitter a demandé à tous ses utilisateurs (et ces 330 millions!) De changer les mots de passe - car il s'est avéré que l'entreprise stockait des mots de passe texte (non hachés).

Pour le moment, le problème de la connexion ne contredit en rien les avantages du hachage de mot de passe. Cependant, vous devez trouver une meilleure solution: une solution dans laquelle le mot de passe ne serait jamais envoyé au serveur en texte clair. L'outil cryptographique qui nous aidera à y parvenir est PAKE, et en particulier un nouveau protocole appelé OPAQUE, que nous aborderons à la fin de cet article.

Qu'est-ce que PAKE?

Le protocole PAKE, proposé pour la première fois par Bellovin et Merritt , est un type spécifique de protocole d'échange de clés . Les protocoles d'échange de clés (ou «accords de clés») sont conçus pour aider les deux parties (appelons-les client et serveur) à s'entendre sur une clé partagée à l'aide de la cryptographie à clé publique. Les premiers protocoles d'échange de clés (comme le Diffie-Hellman classique) n'étaient pas autorisés, ce qui les rendait vulnérables aux attaques telles que l' homme au milieu . Une caractéristique distinctive des protocoles PAKE est que le client s'authentifie auprès du serveur avec un mot de passe. Pour des raisons évidentes, il est supposé que le mot de passe ou son hachage est déjà connu du serveur, ce qui permet la vérification.

Si c'était tout ce dont il avait besoin, les protocoles PAKE seraient faciles à construire. Mais ce qui rend PAKE vraiment utile, c'est qu'il fournit également une protection par mot de passe client. Une garantie plus sérieuse peut être formulée comme suit: après une tentative d'entrée dans le système (réussie ou non), le client et le serveur ne doivent savoir que si le mot de passe client correspond à la valeur attendue par le serveur, et plus d'informations supplémentaires. C'est une assez bonne défense. En fait, ce n'est pas différent de ce que nous exigeons d'une preuve de divulgation zéro .

Une représentation idéalisée du protocole PAKE. L'entrée des deux côtés inclut un caractère aléatoire, qui n'est pas illustré ici. L'espion n'a pas besoin de découvrir la clé secrète partagée K, qui est elle-même aléatoire et n'est pas fonction du mot de passe.

Bien sûr, le problème évident avec PAKE est que de nombreux développeurs ne veulent pas exécuter le protocole «d'échange de clés» en premier lieu! Ils veulent juste s'assurer que l'utilisateur connaît le mot de passe.

La grande chose à propos de PAKE est que le cas d'utilisation «connexion uniquement» est assez facile à exécuter. Supposons que j'ai un protocole PAKE standard qui permet au client et au serveur de se mettre d'accord sur une clé commune K. S'il connaît le mot de passe correct (et seulement dans ce cas), alors tout ce que nous devons mettre en œuvre est une simple vérification que les deux parties ont reçu la même clé. (Cela peut être fait, par exemple, si les parties l'utilisent pour calculer une fonction cryptographique et vérifier les résultats.) Ainsi, PAKE peut être utile même si vous voulez simplement vérifier le mot de passe.

SRP: PAKE, dont le temps lui-même a oublié

Le concept PAKE semble offrir un avantage de sécurité évident par rapport à l'approche naïve que nous utilisons aujourd'hui pour entrer sur le serveur. Et les méthodes elles-mêmes sont anciennes, dans le sens où PAKE est connu depuis 1992! Malgré cela, la lumière ne l'a jamais vu. Pourquoi cela se produit-il?

Il y a plusieurs raisons évidentes. Le plus évident est lié aux limites d'Internet: il est beaucoup plus facile de mettre un formulaire de mot de passe sur une page Web que d'implémenter une cryptographie sophistiquée dans un navigateur. Cependant, cette explication n'est pas suffisante. Même les applications natives implémentent rarement PAKE pour les opérations de connexion. Une autre explication possible est liée aux brevets , bien que la plupart d'entre eux aient déjà expiré. Pour moi, il y a deux raisons probables de ne pas avoir PAKE:

• Manque d'implémentations PAKE de haute qualité dans les langages populaires, ce qui rend leur utilisation difficile;
• Les spécialistes de la cryptographie ne transmettent pas mal l'essence et la valeur de leur travail, de sorte que la plupart des gens ne savent même pas que PAKE existe.

Malgré le fait que j'ai dit que PAKE n'est pas utilisé maintenant, il y a encore des exceptions aux règles.

Il y a un grand protocole développé en 1998 par Tom Wu (à ne pas confondre avec Tim Wu), qui est appelé "SRP" (abréviation de "Secure Remote Password"). En fait, ce n'est qu'un PAKE en trois étapes avec des fonctions supplémentaires qui n'ont pas été implémentées dans les toutes premières œuvres. Pour autant que je sache, SRP diffère en ce qu'il s'agit du protocole PAKE le plus courant au monde. Je vais donner deux preuves de cette affirmation:

1. SRP a été normalisé en tant que ciphersuite TLS et implémenté dans des bibliothèques telles que, par exemple, OpenSSL , bien que personne ne semble l'utiliser en particulier.
2. Apple utilise largement SRP dans son coffre-fort iCloud

Le deuxième fait en soi pourrait faire de SRP l'un des protocoles cryptographiques les plus utilisés au monde, le nombre d'appareils tamponnés par Apple est si grand. Et il n'y a rien de drôle.

Le fait que l'industrie ait accepté le PÉR est certes bon, mais d'un autre côté, et pas très. Surtout parce que même si toute approbation PAKE est cool, SRP seul n'est pas la meilleure implémentation PAKE. Je pensais entrer dans la jungle des discussions sur la SRP, mais ce discours traînait déjà, et je m'éloigne de l'histoire d'un très bon protocole, dont nous parlerons ci-dessous. Si vous êtes toujours intéressé par la discussion sur SRP, je l'ai apportée ici .

Au lieu de ces détails inutiles, permettez-moi d'écrire un bref résumé de mes réflexions sur la SRP:

1. SRP fait certaines choses correctement. Tout d'abord, contrairement aux versions antérieures de PAKE, vous n'avez pas besoin de stocker un mot de passe brut sur le serveur (ou, de manière équivalente, un hachage qui pourrait être utilisé par un attaquant au lieu d'un mot de passe). Au lieu de cela, le serveur stocke un «vérificateur», qui est une fonction unidirectionnelle du hachage de mot de passe. Cela signifie qu'une fuite de base de données de mots de passe ne permet pas à un attaquant de remplacer immédiatement un utilisateur uniquement s'il n'effectue pas d'autres attaques de dictionnaire coûteuses. (Le nom technique pour cela est PAKE «asymétrique».)
2. Il y a de meilleures nouvelles, la version actuelle de SRP (v4 v6a) n'a pas encore été piratée!
3. Cependant (ne soyez pas offensé par les développeurs), l'architecture du protocole SRP est complètement folle, et ses versions antérieures ont été piratées plusieurs fois - c'est pourquoi nous avons maintenant la version 6a. De plus, la «preuve de sécurité» dans l'article de recherche original ne prouve en fait rien .
4. SRP est actuellement basé sur l'arithmétique entière (finale), et pour diverses raisons (voir la clause 3 ci-dessus), son architecture ne peut clairement pas être transférée sur une courbe elliptique. Cela nécessite plus de bande passante et de calcul, donc SRP ne peut pas tirer parti des nombreuses améliorations de performances que nous avons développées dans des modules complémentaires comme Curve25519 .
5. SRP est vulnérable aux attaques de pré-calcul car il transmet le sel de l'utilisateur à tout attaquant qui peut initier une session SRP. Cela signifie que je peux demander votre sel au serveur et créer un dictionnaire de hachages de mots de passe potentiels avant que le serveur ne soit compromis.
6. Malgré toutes ces lacunes, SRP est extrêmement simple et est également livré avec du code de travail. De plus, OpenSSL dispose d'un code de travail qui s'intègre même à TLS, ce qui le rend relativement facile à implémenter.

De tous ces points, ce dernier est presque certainement responsable du degré (relativement) élevé de succès commercial atteint par SRP par rapport aux autres protocoles PAKE. Il n'est pas parfait, mais réel. C'est ce que je voulais transmettre aux experts en sécurité cryptographique.

OPAQUE: PAKE nouvelle génération

Lorsque j'ai commencé à penser à PAKE il y a quelques mois, je n'ai pas pu m'empêcher de noter que la plupart des implémentations existantes fonctionnaient plutôt mal. Soit ils ont eu des problèmes, comme dans SRP, soit obligé l'utilisateur à stocker le mot de passe (ou mot de passe effectif) sur le serveur, soit le «sel» a été montré à l'attaquant, donnant la possibilité de mener l'attaque avant le calcul.

Puis, au début de l'année dernière, Jarecki, Kravczyk et Xu ont révélé au monde un nouveau protocole appelé OPAQUE . Il présente un certain nombre d'avantages importants:

1. Il peut être implémenté même en cas de problèmes de Diffie-Hellman et de logarithmes discrets. Cela signifie que, contrairement à SRP, il peut être facilement instancié en utilisant des courbes elliptiques efficaces.
2. Encore mieux: OPAQUE ne révèle pas de sel à un attaquant. Il résout ce problème en utilisant «PRF oublieux» pour combiner le sel avec le mot de passe afin que le client ne reçoive pas le sel et le serveur ne reçoive pas le mot de passe.
3. OPAQUE fonctionne avec n'importe quelle fonction de hachage de mot de passe. Étant donné que tout le travail de hachage est effectué sur le client, OPAQUE peut réellement décharger le serveur, libérant le service en ligne, par exemple, pour utiliser des paramètres de sécurité extrêmement volumineux, par exemple, configurer scrypt avec beaucoup de RAM .
4. En termes de nombre de messages et d'exposant, OPAQUE n'est pas très différent de SRP. Mais comme il peut être implémenté avec des paramètres plus efficaces, il est susceptible de fonctionner beaucoup plus efficacement.
5. Contrairement à SRP, OPAQUE possède des preuves de sécurité raisonnables (dans un modèle très solide).

Il existe même un projet de proposition Internet pour OPAQUE, que vous pouvez lire ici. Malheureusement, pour le moment, je ne sais rien de la qualité de l'implémentation du code, sauf qu'il existe déjà plusieurs implémentations potentielles. J'espère que ce problème disparaîtra bientôt.
Le protocole OPAQUE à part entière est répertorié ci-dessous. Dans le reste de cette section, je vais vous expliquer comment cela fonctionne.

Problème 1: Garder le sel secret. Comme je l'ai mentionné ci-dessus, le principal problème avec les versions antérieures de PAKE est la nécessité de transférer le sel du serveur vers le client (toujours non authentifié). Cela permet à un attaquant de mener des attaques avant de calculer où il peut générer un dictionnaire basé sur les données reçues.

Le problème ici est que le sel est généralement transmis à une fonction de hachage (par exemple scrypt) avec le mot de passe. Intuitivement, quelqu'un doit calculer cette fonction. S'il s'agit d'un serveur, le serveur devrait voir un mot de passe, ce qui tue toute signification. S'il s'agit d'un client, il a besoin de sel.

Théoriquement, vous pouvez contourner ce problème en calculant la fonction de hachage de mot de passe à l'aide du protocole de calcul sécurisé à deux parties (2PC) . Dans la pratique, de telles solutions seront presque certainement inefficaces, principalement parce que les fonctions de hachage de mot de passe sont complexes et prennent du temps. Cela augmentera considérablement la complexité de tout système 2PC.

OPAQUE contourne cela comme suit. Il laisse un hachage de mot de passe côté client, mais ne le montre pas. Au lieu de cela, il utilise un protocole bidirectionnel spécial appelé PRF oublieux pour calculer un autre sel (appelons-le salt2) afin que le client puisse utiliser salt2 dans la fonction de hachage mais ne puisse pas accéder au sel d'origine.

Cela fonctionne comme ceci:

Le serveur stocke le «sel» et le client a le mot de passe. Sel2 = PRF (sel, mot de passe), ceci est calculé entre le client et le serveur en utilisant un protocole dans lequel le client ne reconnaîtra jamais le sel et le serveur connaîtra le mot de passe. Le client reçoit salt2K = PasswordHash (salt2, mot de passe) - et tout cela est pris en compte sur le client.

L'implémentation réelle de PRF oublieux peut être effectuée en utilisant plusieurs éléments de groupe et exposants. Encore mieux, si le client entre le mauvais mot de passe, le protocole reçoit alors une valeur fictive "salt2", qui ne dit rien sur la valeur réelle de salt.

Problème 2: Preuve que le client a reçu la bonne clé K. Bien sûr, au moment où le client a reçu la clé K, mais le serveur n'a aucune idée de ce que c'est. Le serveur ne sait pas non plus s'il s'agit de la bonne clé.

La solution OPAQUE est basée sur l'ancienne idée de Gentry, Mackenzie et Ramzan . Lorsqu'un utilisateur se connecte pour la première fois au serveur, le serveur génère une clé publique et privée fiable pour le protocole d'accord sécurisé (par exemple, HMQV) et crypte la clé privée reçue sous K avec la clé publique du serveur. Le chiffrement authentifié (et la clé publique) résultant est stocké dans la base de données de mots de passe.

C = Chiffrer (K, clé secrète client | clé publique du serveur)


Version complète du protocole OPAQUE, extrait de l' article .

Lorsque le client souhaite s'authentifier à l'aide du protocole OPAQUE, le serveur lui envoie le code C stocké. Si le client a entré le mot de passe correct dans la première phase, il peut obtenir K et déchiffrer ce chiffre. Sinon, c'est inutile. À l'aide d'une clé secrète câblée, il peut désormais exécuter un protocole d'accord standard avec une clé authentifiée pour terminer la prise de contact. (Le serveur vérifie l'entrée des clients en les comparant à sa copie de la clé publique du client, et le client fait de même.)

Maintenant, mettons tout cela ensemble. Toutes ces étapes peuvent être combinées en un seul protocole, qui a le même nombre d'étapes que SRP. Si vous ne faites pas attention aux étapes de vérification, cela ressemblera au protocole ci-dessus. En principe, l'idée n'est que dans deux messages: l'un du client et le second est renvoyé au serveur.

Le dernier aspect du travail d'OPAQUE est qu'il dispose de bonnes preuves de sécurité qui nous indiquent que le protocole résultant peut être considéré comme sûr si nous prenons un ou plusieurs logarithmes discrets dans un modèle Oracle aléatoire, ce qui est une hypothèse standard, qui apparemment , se déroule dans les paramètres avec lesquels nous travaillons.

Conclusion

Donc, en bref, nous avons une technologie fiable qui peut rendre le processus d'utilisation des mots de passe beaucoup plus facile, et peut également nous permettre de les gérer plus efficacement - avec beaucoup de paramètres de hachage et beaucoup de charge de travail côté client. Pourquoi cela n'est-il pas utilisé partout? Peut-être qu'au cours des prochaines années, tout changera. Le temps nous le dira.

Selon la tradition établie, nous attendons vos commentaires et vous invitons à visiter la journée portes ouvertes , qui sera organisée le 27 mai par notre professeur, la cryptanalyste Elena Kirshanova .