Craquage de mots de passe préservant la confidentialité : un protocole pour la récupération sécurisée de hachages

Table des matières

1. Introduction

Malgré les efforts de l'industrie pour promouvoir des solutions sans mot de passe, ces derniers restent la forme dominante d'authentification des utilisateurs. Le stockage des hachages de mots de passe est une pratique courante, mais tester leur robustesse par craquage est gourmand en ressources. Externaliser cette tâche vers des serveurs tiers introduit des risques significatifs pour la vie privée, car le condensé de hachage et le texte clair récupéré sont tous deux exposés. Cet article présente le protocole de craquage de mots de passe préservant la confidentialité (3PC), qui permet à un client d'utiliser la puissance de calcul d'un tiers pour le craquage de hachage sans révéler le hachage cible ni le mot de passe obtenu.

2. The 3PC Protocol

Le protocole 3PC est conçu pour résoudre le problème de confiance dans le craquage de mots de passe externalisé. Son innovation fondamentale réside dans la possibilité pour un tiers d'effectuer le travail de calcul intensif sans rien apprendre sur les données réelles du client.

2.1 Core Mechanism & Predicate Function

Le protocole est construit sur le concept de chiffrement prédicatif, adapté aux fonctions de hachage. Le client n'envoie pas directement le hachage cible $H(p)$. Au lieu de cela, il envoie un ensemble d'anonymat contenant le hachage réel mélangé à $k-1$ leurres de hachage soigneusement construits. Le rôle du serveur tiers est de craquer tous les hachages de cet ensemble en utilisant un dictionnaire de mots de passe ou un ensemble de règles fourni.

La clé est la fonction prédicat $f$. Le serveur évalue un mot de passe candidat $p'$ par rapport à chaque hachage dans l'ensemble d'anonymat. La fonction est définie de telle sorte que $f(H(p'), H_i) = 1$ si et seulement si $H(p')$ correspond au hachage $H_i$ dans l'ensemble. Le serveur renvoie l'ensemble des mots de passe candidats qui satisfont $f=1$ pour tout hash dans l'ensemble, sans savoir pour quel hash spécifique (réel ou leurre) une correspondance a été trouvée.

2.2 Decoy Hash Generation & Anonymity Set

La génération de leurres plausibles est cruciale pour la sécurité. Les hachages leurres doivent être indiscernables du hachage réel pour le serveur. L'article propose de générer les leurres à partir d'une distribution correspondant à l'espace de sortie de la fonction de hachage cible (par exemple, NTLM, SHA-256). Cela garantit l'anonymat $k$ pour le hachage réel. Le client conserve déni plausible, car même le client ne peut pas prouver cryptographiquement quel hachage était la cible originale après avoir soumis l'ensemble.

3. Technical Implementation & Analysis

3.1 Fondements mathématiques

La sécurité du protocole peut être modélisée de manière probabiliste. Soit $S$ l'ensemble d'anonymat de taille $k$, contenant un hachage réel $H_r$ et $k-1$ leurres $H_{d1}...H_{d(k-1)}$. La probabilité que le serveur devine correctement le hachage réel après avoir observé l'ensemble et les résultats de craquage est au plus de $1/k$, en supposant des leurres parfaits.

La fuite d'information $\mathcal{L}$ vers le serveur peut être quantifiée à l'aide de la min-entropie : $\mathcal{L} \leq -\log_2(1/k) = \log_2(k)$ bits. Le client peut contrôler la fuite en ajustant $k$. L'évaluation de la fonction prédicat pour un candidat $p'$ sur l'ensemble des $k$ hachages peut être représentée par un vecteur : $\vec{R} = [f(H(p'), H_1), f(H(p'), H_2), ..., f(H(p'), H_k)]$. Une correspondance sur la tout position renvoie $p'$ au client.

3.2 Performance & Scalability

L'article soutient que le principal goulot d'étranglement n'est pas les opérations cryptographiques, mais les opérations d'entrée/sortie par seconde (IOPS) de la configuration de cassage du serveur (par exemple, la bande passante mémoire du GPU/FPGA). Comme le serveur doit tester chaque mot de passe candidat contre tous les $k$ hachages, le facteur de travail augmente linéairement en théorie ($O(k)$). Cependant, en tirant parti d'un traitement par lots efficace sur du matériel parallèle, le ralentissement effectif peut être minimisé, approchant la recherche en "temps constant" revendiquée pour des valeurs pratiques de $k$.

4. Experimental Results & Chart Description

Les auteurs ont implémenté une preuve de concept sur une architecture FPGA. Bien que les chiffres de performance spécifiques ne soient pas détaillés dans l'extrait fourni, l'article prétend démontrer la faisabilité du protocole.

5. Exemple de cas d'étude du cadre d'analyse

Scénario : Un testeur d'intrusion indépendant (Client) récupère un hash NTLM sur le système d'un client. La politique de mot de passe est connue : mélange alphanumérique de 9 caractères. Le testeur ne dispose pas de la puissance de calcul GPU nécessaire pour le casser dans un délai raisonnable.

Application du Protocole 3PC :

1. Configuration du Client : Le testeur définit un paramètre de confidentialité, par exemple $k=100$. Le hachage NTLM réel est $H_{real}$. Le logiciel du client génère 99 hachages NTLM leurres cryptographiquement plausibles, créant ainsi l'ensemble d'anonymat $S$.
2. Engagement du serveur : Le testeur envoie $S$ à un service de craquage commercial (Server) avec une demande de casser tous les hachages en utilisant un dictionnaire et des règles pour des mots de passe alphanumériques de 9 caractères.
3. Traitement par le serveur : Le serveur exécute ses outils de craquage. Pour chaque mot de passe candidat généré, il calcule son hachage NTLM et vérifie s'il correspond à l'ensemble des 100 hachages contenus dans $S$ via une opération par lots.
4. Retour du résultat : Le serveur renvoie une liste de tous les mots de passe qui ont correspondu. tout Il ne spécifie pas quel hachage dans $S$ correspond.
5. Filtrage client : Le testeur connaît le hachage original $H_{real}$. Il calcule le hachage de chaque mot de passe retourné pour identifier celui qui correspond à $H_{real}$, récupérant ainsi le mot de passe cible. Les autres mots de passe retournés correspondent à des leurres craqués et sont ignorés.

Le serveur apprend seulement que l'un des 100 hachages appartenait au testeur, mais pas lequel, et voit de nombreux mots de passe craqués sans connaître leur pertinence.

6. Core Insight & Analyst's Perspective

Idée Maîtresse : The 3PC protocol is a clever, pragmatic hack that turns a fundamental limitation of cryptography—the one-way nature of hash functions—into a privacy feature. It recognizes that in password cracking, the goal isn't to hide the processus mais pour cacher le cible et le résultat dans le bruit inhérent au processus. Il s'agit moins de cryptographie "inviolable" que d'une dissimulation stratégique de l'information, similaire dans son principe à la façon dont les réseaux de mélange comme Tor dissimulent l'origine d'un message au sein d'une foule.

Enchaînement logique : La logique est solide mais repose sur une hypothèse critique, souvent négligée : la capacité à générer des leurres parfaitement indiscernables. Si le serveur peut distinguer statistiquement les hachages réels des leurres (par exemple, sur la base de leur fréquence dans des fuites de données antérieures, ou de modèles dans la génération de hachages), le modèle de $k$-anonymat s'effondre. L'extension de l'encryption par prédicat aux fonctions de hachage proposée dans l'article est novatrice, mais la sécurité en situation réelle dépend davantage de la qualité de l'algorithme de génération de leurres que de la fonction de prédicat elle-même.

Strengths & Flaws: Sa force réside dans son applicabilité directe à une niche réelle et mal desservie (les testeurs d'intrusion soucieux de la confidentialité) et sa surcharge cryptographique relativement légère pour le client. Un défaut majeur, comme pour de nombreux systèmes préservant la vie privée, est le trust-but-verify Paradoxe. Le client doit faire confiance au serveur pour exécuter correctement le protocole et ne pas altérer le processus (par exemple, en enregistrant des états intermédiaires pour corréler les chronologies). Contrairement aux protocoles cryptographiques avancés comme le chiffrement complètement homomorphe (FHE), qui offre une garantie théorique plus forte mais est impraticablement lent (comme observé dans les premières implémentations telles que le travail fondateur de Gentry), le 3PC échange une sécurité cryptographique absolue contre une efficacité pratique. Il s'agit d'un compromis d'ingénierie valable, mais il doit être clairement communiqué.

Perspectives Actionnables : Pour les équipes de sécurité, ce protocole est un outil viable pour des audits de mots de passe sécurisés, en particulier lorsque la conformité (comme le RGPD) restreint le partage de hachages sensibles. La première étape immédiate est de mettre en œuvre et d'auditer le module de génération de leurres. Pour les chercheurs, la prochaine frontière est de renforcer le protocole contre les attaques actives des serveurs et de l'intégrer à d'autres technologies de protection de la vie privée (PETs). L'avenir ne consiste pas seulement à rendre le craquage privé ; il s'agit de construire une suite d'opérations de sécurité préservant la confidentialité, un peu comme l'évolution du chiffrement simple vers les preuves à divulgation nulle dans les protocoles d'authentification. Le 3PC est un premier pas prometteur dans cette direction pour la sécurité offensive.

7. Future Applications & Research Directions

• Audit de Sécurité Piloté par la Conformité : Permettre aux secteurs réglementés (finance, santé) de réaliser des tests rigoureux de robustesse des mots de passe sur les comptes des employés sans jamais exposer les hachages, même aux équipes d'audit internes, facilitant ainsi la conformité au RGPD/CCPA.
• Analyse de Hachage Fédérée : Plusieurs organisations pourraient collaborer à un effort de cassage contre un dump de mots de passe d'un acteur de menace partagé (par exemple, d'un groupe de rançongiciel) sans qu'aucun participant ne révèle ses propres hachages internes ni ne voie ceux des autres.
• Intégration avec les Services d'Alerte de Fuites de Mots de Passe : Les utilisateurs pourraient soumettre un ensemble d'anonymat dérivé de leurs hachages de mots de passe à un service comme "Have I Been Pwned" sans révéler le hachage réel, améliorant ainsi la confidentialité lors de la vérification des fuites.
• Axe de recherche - Résilience post-quantique : Étude de la sécurité du protocole dans un contexte post-quantique. Bien que les fonctions de hachage puissent être résistantes aux attaques quantiques, les mécanismes de génération de leurres et de fonction de prédicat nécessitent une analyse face à des modèles adversariaux quantiques.
• Axe de recherche - Modèles d'adversaires actifs : Il est crucial, pour une adoption réelle, d'étendre le modèle de sécurité afin de prendre en compte les serveurs activement malveillants qui s'écartent du protocole (par exemple, en introduisant des canaux cachés).

8. References

1. Bonneau, J., Herley, C., van Oorschot, P. C., & Stajano, F. (2012). The quest to replace passwords: A framework for comparative evaluation of web authentication schemes. IEEE Symposium on Security and Privacy.
2. FIDO Alliance. (2022). FIDO : L'avenir des connexions rapides, sécurisées et sans mot de passe. https://fidoalliance.org/
3. Gentry, C. (2009). A fully homomorphic encryption scheme (Thèse de doctorat, Université de Stanford). (Pour une comparaison des techniques de confidentialité computationnelle).
4. NIST. (2020). Digital Identity Guidelines (NIST Special Publication 800-63B).
5. Weir, M., Aggarwal, S., de Medeiros, B., & Glodek, B. (2009). Password cracking using probabilistic context-free grammars. IEEE Symposium on Security and Privacy.
6. Zhao, F., & Halderman, J. A. (2019). Mesurer l'impact de la robustesse des mots de passe sur les attaques par devinette.Symposium sur la sécurité USENIX.