Résumé

  • RFC 9807 permet d’inscrire puis d’authentifier un utilisateur sans livrer son mot de passe au serveur ; la compromission d’un serveur unique autorise néanmoins l’inévitable attaque exhaustive hors ligne contre le compte dont le dossier et les secrets utiles ont fuité.
  • Une graine oprf_seed commune peut réunir des utilisateurs distincts dans un même périmètre de compromission ; l’isoler par client, simuler de faux comptes ou répartir l’OPRF déplace le risque sans le supprimer.

La phrase est excellente pour une démonstration : « le serveur ne connaît jamais le mot de passe ». Pour une décision d’investissement, elle est trop courte.

Elle décrit avec exactitude une propriété d’OPAQUE. Elle ne dit pas qui détient la racine servant à calculer les clés OPRF, combien d’utilisateurs dépendent de cette racine, où résident les dossiers d’inscription, ni comment une organisation remplace ces dossiers lorsqu’elle change d’algorithme ou de clé. Autrement dit, elle retire un pouvoir au serveur, mais ne dresse pas la carte du pouvoir restant.

RFC 9807, publié en juillet 2025, spécifie OPAQUE, un échange de clés authentifié par mot de passe augmenté. Le client associe une fonction pseudo-aléatoire oblivieuse, une enveloppe de récupération et un échange de clés authentifié. Le serveur obtient la preuve nécessaire à l’authentification et une clé de session partagée sans recevoir le mot de passe, même pendant l’inscription.

Il faut aussi nommer correctement l’autorité du texte. La fiche du RFC Editor et le Datatracker le classent comme RFC d’information du flux IRTF, issu du consensus du Crypto Forum Research Group. Le document précise qu’il n’est ni un produit de l’IETF ni une norme. Le rattacher à l’annuaire IETF aide le lecteur ; lui prêter une autorité Standards Track déformerait la source.

Ce que le serveur ne reçoit plus

Dans une connexion classique, TLS protège un mot de passe pendant le transport, puis le remet à l’application. La protection de TLS 1.3 n’empêche ni un journal accidentel, ni une mémoire applicative compromise, ni un point de terminaison placé au mauvais endroit. Elle protège le canal ; elle ne peut pas ordonner au destinataire d’ignorer le secret reçu.

OPAQUE change cette frontière. Dans l’OPRF décrit par RFC 9497, le serveur possède la clé de la fonction et le client présente une entrée aveuglée. Le client obtient la sortie ; le serveur n’apprend ni l’entrée ni la sortie. RFC 9807 ajoute l’étirement cryptographique et laisse le client fabriquer l’enveloppe qui protégera son matériel d’authentification.

Lors de la connexion, trois messages circulent : KE1, KE2, puis KE3. Le troisième porte l’authentification explicite du client et complète la pleine confidentialité persistante prévue par le profil. Une plateforme ne devrait donc pas compter l’émission de KE2 comme un succès. Tant que KE3 n’a pas été vérifié par ServerFinish, l’événement reste un échec. Cette distinction entre séquence cryptographique et métrique métier est déjà un test de maturité.

Le client reçoit ensuite une session_key, partagée avec le serveur, et une export_key, inaccessible au serveur. La seconde peut protéger d’autres données du client, mais seulement après authentification du pair. Aucune de ces clés ne décide si l’utilisateur a le droit d’effectuer un virement, de modifier une route ou d’accéder à un dossier. L’authentification établit un interlocuteur ; l’autorisation demeure une décision applicative distincte.

Le dictionnaire attend toujours après la brèche

L’article fondateur d’OPAQUE formule une limite incontournable. Dans un aPAKE à serveur unique, la fuite du dossier et des secrets pertinents rend possible une recherche exhaustive hors ligne du mot de passe de l’utilisateur concerné. OPAQUE empêche surtout l’attaquant de préparer à l’avance une table fondée sur une transformation prévisible. Après la compromission, chaque hypothèse doit être testée avec les éléments nouvellement obtenus.

L’étirement de clé renchérit ces essais. RFC 9807 prévoit une KSF choisie par l’application et propose notamment Argon2id, documenté dans RFC 9106. Mais le calcul est effectué côté client. Plus de mémoire et de temps rendent l’attaque coûteuse ; ils rendent aussi l’authentification plus lourde sur un téléphone d’entrée de gamme, un navigateur contraint ou un appareil embarqué. La bonne valeur n’existe pas dans l’absolu. Elle doit être démontrée par des percentiles de latence, de mémoire et d’échec sur le parc réel.

OPAQUE ne fait donc pas disparaître les essais en ligne, les mots de passe faibles, le terminal compromis ou les conséquences d’une fuite serveur. Il protège la non-divulgation du mot de passe, résiste au pré-calcul dans son modèle, fournit une authentification mutuelle et limite ce qu’une divulgation ultérieure révèle des anciennes sessions. Agrandir cette promesse jusqu’à « plus de risque lié aux mots de passe » reviendrait à affaiblir une avancée réelle par une affirmation fausse.

Des clés individuelles sous une racine commune

Au démarrage, le serveur choisit une paire de clés AKE et une oprf_seed. La graine, combinée à un identifiant de justificatif unique, produit une clé OPRF différente pour chaque client. Le résultat est individualisé ; la racine peut rester collective.

C’est ici que le vocabulaire trompe facilement. Un schéma peut afficher « clé unique par utilisateur » tout en laissant une seule graine recoverable commander tous les comptes. RFC 9807 recommande une même graine lorsqu’on met en œuvre sa défense contre l’énumération, puis indique explicitement que sa fuite compromet la sécurité de tous les clients qui en dépendent.

L’étude de 2024, (Strong) aPAKE Revisited, avait analysé ce choix dans la lignée du projet. Elle montre que la graine commune ne révèle pas magiquement tous les mots de passe. La compromission du dossier d’un utilisateur expose la graine globale ; celle-ci permet de dériver la clé OPRF d’un autre compte ; une interaction bénigne avec le serveur honnête fournit alors la pièce permettant de tester hors ligne les hypothèses relatives à cet autre compte. Le RFC final cite cette analyse et en reprend la conséquence multi-utilisateur.

Une application qui ne requiert pas la protection d’énumération prescrite peut attribuer une graine indépendante à chaque client. Le périmètre commun rétrécit, mais un nouvel actif apparaît : la correspondance stable entre client et graine. Elle doit rester identique entre inscription et connexion. Une restauration incorrecte, un repli de recherche ou une réplication divergente peut trahir l’existence d’un compte ou le rendre inaccessible.

Le choix n’oppose donc pas une option « sûre » à une option « dangereuse ». Il arbitre entre confidentialité d’existence, concentration d’un secret racine, cohérence des données et complexité de reprise. La discipline de la spécification minimale et de la décision locale est pertinente : le protocole fournit une construction commune ; l’exploitant doit déclarer le risque d’énumération qui justifie son architecture de garde.

Le faux compte n’est pas une protection universelle

Pour une identité inconnue, le serveur peut renvoyer une fausse CredentialResponse. Une masking_key, créée par le client à l’inscription, chiffre la réponse de sorte qu’un observateur actif distingue difficilement compte réel et compte simulé. Les branches, erreurs et temps d’exécution doivent eux aussi rester indiscernables.

Cette défense ne couvre pas l’inscription. Le serveur réagit nécessairement différemment selon que l’identité existe déjà ; l’inscription reste donc un oracle à limiter ou à restreindre. La simulation peut aussi créer un vecteur d’abus, car la réponse du serveur peut coûter moins cher que la requête du client.

Enfin, la masking_key doit parvenir confidentiellement au serveur pendant l’inscription. Ce stade exige un canal authentifié, confidentiel et intègre. RFC 9807 cite TLS et renvoie à HPKE lorsque la confidentialité doit être construite au-dessus d’un canal déjà authentifié. Il serait contradictoire d’invoquer l’aveuglement du mot de passe pour négliger la cérémonie qui installe les secrets du compte.

Trois domaines de garde

La graine OPRF, la clé privée AKE du serveur et la base de RegistrationRecord sont trois actifs. RFC 9807 explique que la clé AKE brute peut rester dans un HSM : le serveur n’a besoin que de l’opération qui calcule le secret partagé. Après fuite de la graine et des enveloppes, cette séparation peut empêcher l’usurpation du serveur. Elle n’empêche pas, à elle seule, l’attaque de dictionnaire rendue possible par les éléments OPRF et les dossiers.

La carte de contrôle doit ainsi répondre séparément : qui peut évaluer les clés OPRF et pour combien de clients ; qui peut invoquer l’opération AKE ; qui peut extraire et relier les dossiers aux identités. Trois coffres répliqués sous le même compte d’administration, dans la même sauvegarde, ne constituent pas trois frontières.

Un OPRF à seuil modifierait la première réponse. RFC 9807 note qu’il peut contraindre l’attaquant à réunir un quorum de parts ou à agir en ligne. Si les serveurs OPRF sont séparés du serveur d’authentification, les parts ne suffisent toujours pas sans les dossiers. L’article originel prévoit cette possibilité sans changement visible pour l’utilisateur. Mais le mécanisme est hors du périmètre de RFC 9807 : « compatible avec le seuil » ne prouve ni l’indépendance des gardiens, ni la survie à une panne de quorum, ni l’impossibilité pour une seule organisation de tout recomposer.

Les briques annexes — HKDF, le hachage vers les courbes de RFC 9380, les exigences PAKE de RFC 8125 — sont nécessaires. Elles ne certifient pas l’assemblage, l’aléa, le temps constant, la garde des secrets ou la réponse à incident d’un service concret.

Changer la configuration signifie réinscrire

La souplesse cryptographique paraît simple tant qu’on ne compte que les binaires. RFC 9807 rappelle que le RegistrationRecord est lié aux paramètres et à certains matériels de clé. Modifier la KSF, les algorithmes ou la clé publique du serveur exige une nouvelle inscription et un nouveau dossier. Changer le mot de passe est également une inscription fraîche avec de nouveaux aléas.

Une migration est donc une opération distribuée dans la population des utilisateurs. Déployer un serveur neuf n’actualise ni les comptes dormants, ni les clients anciens, ni les données protégées par une ancienne export_key. À grande échelle, la configuration devient une forme de dépendance : l’organisation ne peut quitter son ancien domaine de compromission sans participation des utilisateurs.

La primauté du code en fonctionnement fournit ici un test sobre. Une option « nouvelle suite activée » n’est pas une migration. Il faut voir les nouveaux dossiers, les connexions qui les utilisent, les anciens chemins qui cessent d’être acceptés et les secrets historiques rendus inutilisables. Les couches de réalité empêchent de confondre trois vérités : logiciel déployé, utilisateurs migrés, ancien risque retiré.

Le reçu durable est un registre de cohortes : comptes éligibles, nouveaux dossiers, dossiers anciens encore admis, comptes dormants, échecs de récupération, clients incapables de supporter la nouvelle KSF, dépendances à l’ancienne clé d’exportation, recours au repli et date de destruction effective de l’ancien domaine de secrets.

OPAQUE répond fortement à une question étroite : authentifier par mot de passe sans remettre ce mot de passe au serveur et sans offrir à l’attaquant un pré-calcul réutilisable. Le progrès est réel. La responsabilité commence précisément là où la formule commerciale s’arrête.

Le serveur n’a plus vu le mot de passe. L’autorité, elle, s’est déplacée vers une graine, des dossiers, des opérations privées, des réponses simulées, le budget des appareils et l’état de migration. La sécurité dépend de la visibilité et des limites imposées à ce nouvel ensemble.

Sources