Pass-ta-key : comment des malwares détournent les passkeys de Google Password Manager

C’est le constat présenté le 3 août 2026 par Unit 42, l’équipe de recherche en cybersécurité de Palo Alto Networks. Les chercheurs ont baptisé Pass-ta-key, Silver Pass-ta-key et Golden Pass-ta-key trois scénarios ciblant Google Password Manager dans Chrome sur des machines Windows équipées d’un module TPM .

Point important : ces techniques ne cassent ni WebAuthn ni la cryptographie de FIDO2. Elles s’attaquent plutôt aux mécanismes qui entourent les passkeys : confiance accordée à l’appareil, réinscription de Chrome et synchronisation des clés avec le cloud .

Trois attaques, trois niveaux de gravité

Pass-ta-key : détourner l’identité de l’appareil

Dans le scénario de base, le malware récupère sur le disque la clé d’identité de l’appareil utilisée par Chrome et protégée par le TPM. Cette information se trouve dans le fichier local passkey_enclave_state. Le logiciel malveillant la réutilise ensuite via des appels légitimes aux API cryptographiques CNG de Windows afin de signer des requêtes contrôlées par l’attaquant.

Le service d’authentification cloud de Google peut alors produire une assertion WebAuthn valide, sans qu’une invite biométrique ou un code PIN n’apparaisse sur l’ordinateur de la victime .

Cette méthode ne fonctionne toutefois que contre les sites qui ne vérifient pas correctement l’indicateur User Verified — ou UV, qui signale qu’une vérification de l’utilisateur a bien eu lieu — dans les données de l’authentificateur .

Ce que l’attaque exploite : la confiance accordée par l’authentificateur cloud à une clé d’identité stockée localement, ainsi que l’absence de contrôle du statut UV par certains sites.

Silver Pass-ta-key : contourner même la vérification de l’utilisateur

Le deuxième scénario vise les sites qui exigent effectivement la vérification de l’utilisateur. Le malware supprime ou invalide le fichier passkey_enclave_state, ce qui force Chrome à relancer la procédure d’inscription de l’appareil — une étape parfois appelée « réinscription » ou onboarding.

Pendant cette procédure, Chrome crée brièvement la clé utilisée pour la vérification de l’utilisateur dans un flux différé. L’attaquant profite de cette fenêtre pour enregistrer sa propre clé UV. Selon Unit 42, l’authentificateur cloud de Google ne vérifie pas l’attestation de cette nouvelle clé. Les assertions qu’elle signe peuvent donc être marquées comme vérifiées, avec l’indicateur UV réglé sur 1, même si la véritable vérification n’a pas été effectuée .

L’attaquant obtient ainsi un accès persistant depuis son propre appareil. Le PC de la victime n’a plus besoin de rester connecté pour que cet accès soit utilisé .

Ce que l’attaque exploite : l’absence de validation de l’attestation pendant la réinscription de l’appareil et la possibilité de supprimer le fichier d’état de l’enclave sans protection suffisante.

Golden Pass-ta-key : récupérer la clé maîtresse

Le scénario le plus grave reprend la même procédure de réinscription, puis cible la mémoire du processus Chrome. Le malware peut y rechercher le Security Domain Secret — ou SDS — une clé symétrique de 32 octets qui sert à chiffrer les clés privées de toutes les passkeys synchronisées sur le compte Google de la victime .

Un SDS récupéré permettrait de déchiffrer les clés privées déjà synchronisées, mais aussi celles qui seraient ajoutées ultérieurement. L’attaquant pourrait alors prendre le contrôle de tous les services protégés par ces passkeys, sans interaction supplémentaire de la victime .

Unit 42 avait également constaté que Chrome écrivait auparavant le SDS en clair dans la sortie chrome://device-log/FIDO. Google a retiré cette journalisation après le signalement des chercheurs, mais le problème lié à la présence du secret en mémoire pendant la procédure d’inscription demeurait au moment de la publication .

Ce que l’attaque exploite : la présence temporaire du SDS en clair dans la mémoire du processus Chrome.

Quels sites sont concernés ?

L’attaque Pass-ta-key de base peut viser tout service qui ne vérifie pas l’indicateur UV renvoyé par l’authentificateur. Unit 42 a notamment identifié eBay comme un site qui n’effectuait pas ce contrôle ; eBay a depuis corrigé le problème .

Les chercheurs ont également indiqué qu’un nombre « étonnamment élevé » de sites demandaient userVerification: "required" lors de l’enregistrement d’une passkey, sans vérifier ensuite que le bit UV était bien présent dans la réponse d’authentification .

Autrement dit, afficher une exigence de vérification côté navigateur ne suffit pas : le service doit aussi contrôler la réponse reçue côté serveur.

Que permettrait de faire un SDS volé ?

Le SDS fonctionne comme une clé maîtresse pour les passkeys synchronisées dans le compte Google. Sa compromission pourrait avoir plusieurs conséquences :

• les clés privées de toutes les passkeys déjà synchronisées pourraient être déchiffrées ; les nouvelles clés synchronisées par la suite seraient également exposées ;
• l’attaquant pourrait se connecter aux comptes protégés par ces passkeys, notamment Gmail, sans nouvelle action de la victime ;
• l’accès à Gmail pourrait lui permettre de réinitialiser les mots de passe d’autres services, étendant l’impact à des comptes qui ne reposent pas directement sur une passkey ;
• Google ne proposait pas, au moment de la publication, de mécanisme intégré permettant de renouveler ou de faire pivoter le SDS .

Les protections recommandées

Les recommandations tirées des travaux de Unit 42 et de la couverture consacrée à ces attaques sont les suivantes :

• Ajouter au moins une clé de sécurité matérielle, comme une YubiKey, en complément des passkeys synchronisées. Les identifiants liés à ce type de clé ne sont pas synchronisés dans le cloud, ne sont pas stockés dans l’état de l’enclave Chrome et ne peuvent pas être récupérés de la même manière en mémoire .
• Activer le programme Advanced Protection de Google pour les personnes particulièrement exposées — par exemple les journalistes, dirigeants, militants ou administrateurs. Le programme impose des clés de sécurité ou des passkeys liées à l’appareil et renforce les procédures de récupération du compte .
• Vérifier chaque mois la liste des appareils et des sessions associés au compte Google, puis supprimer tout accès inconnu .
• Considérer toute infection par un infostealer comme un incident affectant l’ensemble des identifiants. Après la récupération du compte, il est recommandé de réinstaller complètement le système et de réenregistrer les passkeys depuis un appareil sain .
• Pour les services en ligne, vérifier le statut UV côté serveur et utiliser userVerification: "required", plutôt que "preferred", pour les opérations sensibles .

Situation au moment de la publication

Au 3 août 2026, aucun identifiant CVE n’avait été attribué à ces scénarios. Google n’avait pas non plus confirmé publiquement si les voies Silver Pass-ta-key ou Golden Pass-ta-key feraient l’objet d’une correction directe .

La conclusion pratique est néanmoins claire : les passkeys restent conçues pour résister aux attaques cryptographiques classiques, mais leur sécurité dépend aussi de l’intégrité de l’appareil sur lequel elles sont utilisées. Un PC Windows déjà infecté peut donc devenir le maillon faible, même lorsque les clés ont été créées sur un appareil sain.