En mai 2025, Matthew Miller, le développeur derrière SimpleWebAuthn, a ajouté une alerte en rouge dans son article de 2023 sur le chiffrement avec WebAuthn. Entouré d’emojis d’alarme, le message est sans équivoque : « Si vous supprimez un passkey, vous perdrez définitivement l’accès à toutes les données qu’il protège. » Aucune récupération possible. Pas de service client, pas de clé de secours. Les données restent chiffrées. Pour toujours.

Ce scénario catastrophe est le résultat d’un usage technique qui monte en puissance depuis 2023 : utiliser les passkeys non plus seulement pour s’authentifier, mais pour chiffrer des données côté client via l’extension PRF (Pseudo Random Function) de WebAuthn. Sur le papier, l’idée est élégante. En pratique, elle peut effacer les données de vos utilisateurs d’un simple clic.

Ce qu’est le PRF, sans jargon

Les passkeys reposent sur WebAuthn, le protocole du W3C qui utilise la cryptographie asymétrique pour l’authentification. Une paire de clés est générée à l’inscription : la clé privée reste sur l’appareil, la clé publique est transmise au site. Cette architecture est robuste pour l’authentification. Le problème apparaît quand on tente d’en faire davantage.

L’extension PRF a été ajoutée au brouillon de la spécification WebAuthn Level 3, dont la dernière version éditeur remonte au 25 février 2026 sur le dépôt GitHub du W3C. Elle hérite du mécanisme hmac-secret de CTAP2, le protocole de bas niveau entre navigateur et authentificateur FIDO. Son fonctionnement : le site fournit un « sel » (une suite d’octets arbitraires), l’authentificateur calcule un HMAC entre ce sel et un secret interne lié au credential, puis retourne 32 octets à haute entropie. Ces 32 octets servent à dériver une clé de chiffrement symétrique AES-256 via HKDF.

L’idée semble séduisante : une clé déterministe, haute-entropie, liée à l’origine du site, sans avoir à gérer de mot de passe supplémentaire. Depuis l’introduction du support PRF dans Chrome 116 en 2023, plusieurs tutoriels ont proposé d’implémenter du chiffrement côté client sur cette base. Certains gestionnaires de notes ou d’applications de coffre-fort expérimentaux ont commencé à explorer la piste.

Supprimez le passkey, vos données s’éteignent

Ici réside la faille structurelle. Un passkey n’est pas seulement un mécanisme d’accès : il EST la clé de chiffrement. Chaque credential WebAuthn possède un identifiant unique, généré à sa création et jamais modifiable. La sortie PRF est mathématiquement liée à cet identifiant précis.

Quand un utilisateur supprime son passkey pour en créer un nouveau, après avoir perdu son téléphone, changé d’appareil, ou simplement effacé ses identifiants par erreur, la nouvelle clé génère une sortie PRF totalement différente. Les données chiffrées avec l’ancienne clé restent cryptographiquement verrouillées. Pas corrompues, pas supprimées du serveur : parfaitement intactes sur le papier, mais illisibles en pratique. Sans exception possible.

Matthew Miller le résume sans détour dans son avertissement de mai 2025 : « Il n’existe aucun moyen de récupérer des données protégées par PRF. Elles sont perdues. Définitivement. » La spécification WebAuthn Level 3 du W3C ne définit aucun mécanisme standardisé de récupération pour ce cas de figure. La spec a été conçue pour l’authentification, pas pour la gestion du cycle de vie d’une clé de chiffrement. Ce sont deux disciplines qui n’obéissent pas aux mêmes règles.

La fragmentation des plateformes aggrave les risques

À ce problème structurel s’ajoutent des incohérences profondes entre plateformes et navigateurs. Safari n’a ajouté le support PRF qu’avec la version 17, sortie en septembre 2023. Firefox a tardé davantage. Les clés de sécurité matérielles (YubiKey et équivalents) supportent le mécanisme hmac-secret sous-jacent depuis CTAP 2.0 (2018), mais uniquement sur certains modèles et dans des conditions précises liées à la version du firmware.

La synchronisation cloud est censée propager le secret HMAC avec le passkey : iCloud Keychain et Google Password Manager s’en chargent pour les passkeys de plateforme. Mais pour les clés hardware non-synchronisables, la perte physique de la clé signifie la perte définitive de toutes les données chiffrées. Et en cas de migration d’une plateforme à une autre, le comportement peut varier selon les implémentations.

Autre piège redoutable : le paramètre userVerification dans l’appel WebAuthn doit rester rigoureusement identique à chaque session. Selon la spécification CTAP de la FIDO Alliance, les authentificateurs maintiennent deux secrets HMAC internes distincts — l’un utilisé avec vérification biométrique ou PIN, l’autre sans. Un changement de ce paramètre entre deux sessions produit une sortie PRF différente, sans aucun message d’erreur explicite. Les données chiffrées deviennent silencieusement inaccessibles.

Ce que les développeurs font souvent mal

Plusieurs erreurs d’implémentation reviennent systématiquement dans les projets qui utilisent PRF pour du chiffrement côté client.

La première : traiter la suppression d’un passkey comme un « changement de mot de passe ». Les utilisateurs s’attendent à retrouver leurs données après une réinitialisation de compte, exactement comme ils le feraient avec un nouveau mot de passe. Ce n’est pas le cas avec PRF. Supprimer un passkey, c’est plus proche de détruire physiquement la seule copie d’une clé USB chiffrée que de changer un code secret.

La deuxième : ne pas prévoir de mécanisme de récupération. Aucun gestionnaire de mots de passe grand public, Bitwarden, 1Password ou Dashlane, ne repose uniquement sur PRF pour chiffrer ses données. La raison est simple : ces entreprises savent que les utilisateurs perdent régulièrement leurs appareils et s’attendent à récupérer l’accès depuis un autre terminal.

La troisième : ignorer les variations de comportement entre plateformes lors des tests. Un système qui fonctionne sur Chrome sous macOS peut produire des sorties PRF différentes sur Firefox sous Windows, rendant les données inaccessibles aux utilisateurs qui changent de navigateur.

Les alternatives qui tiennent la route

Le chiffrement côté client basé sur un mot de passe reste la référence éprouvée. Les algorithmes modernes de dérivation de clé comme Argon2id ou scrypt transforment un secret mémorisé en clé cryptographique solide, tout en rendant les attaques par force brute prohibitivement coûteuses. C’est l’approche retenue par Bitwarden, ProtonMail et Tresorit pour leur chiffrement de bout en bout.

Pour les applications qui veulent combiner authentification sans mot de passe et chiffrement, une architecture hybride s’impose : le passkey gère l’authentification, mais la clé de chiffrement est stockée sur le serveur chiffrée avec une clé dérivée d’un secret secondaire distinct (code de récupération, PIN spécifique). Le serveur ne connaît jamais la clé de chiffrement en clair. L’utilisateur dispose d’un recours concret si son passkey disparaît.

Pour les usages professionnels nécessitant un second facteur matériel fort, les YubiKeys proposent leur propre interface de dérivation de clé par challenge-response en dehors du contexte WebAuthn, mieux adaptée à une architecture de chiffrement longue durée.

Excellent pour se connecter, risqué pour chiffrer

La FIDO Alliance le répète dans sa documentation officielle : les passkeys ont été conçus pour remplacer les mots de passe dans le flux d’authentification. Ils résistent au phishing, protègent contre les violations de bases de données d’identifiants, et simplifient l’expérience utilisateur. Selon le rapport 2024 de Verizon sur les violations de données, la généralisation des passkeys réduirait mécaniquement une grande partie des compromissions de comptes basées sur le vol de mots de passe. Ces avantages sont réels.

Mais l’authentification et le chiffrement obéissent à des logiques différentes. Un mécanisme d’authentification peut être réinitialisé sans que l’utilisateur perde l’accès à ses données historiques. Un mécanisme de chiffrement basé sur une clé unique, non. C’est cette asymétrie qui rend dangereux l’usage de PRF comme unique source d’une clé de chiffrement à long terme.

Le groupe de travail WebAuthn du W3C doit soumettre la spécification Level 3 pour recommandation officielle dans le courant de 2026. Si cette version finit par définir un profil sécurisé pour PRF en contexte de chiffrement, avec des mécanismes standardisés de rotation et de récupération de clé, cela changera l’équation. En attendant, les développeurs qui implémentent du chiffrement côté client ont tout intérêt à traiter PRF comme un composant expérimental, jamais comme la seule protection de données utilisateur.