Trois attaques Pass-ta-key contournent les passkeys Google — le cloud authenticator de Chrome valide des machines compromises sans vérifier le TPM

3 août 2026. Unit 42, la branche recherche de Palo Alto Networks, publie un rapport qui fissure le discours marketing autour des passkeys. Trois attaques, collectivement baptisées Pass-ta-key, permettent à un malware déjà présent sur une machine Windows de détourner les passkeys synchronisées via Google Password Manager dans Chrome. Aucune de ces attaques ne casse la cryptographie sous-jacente. Elles exploitent un problème plus profond : le cloud authenticator de Google fait confiance à une machine compromise.

Les trois attaques ciblent l’architecture de synchronisation des passkeys de Google. Elles ne nécessitent pas de privilèges administrateur, pas d’interaction utilisateur, et — dans le cas de Golden Pass-ta-key — compromettent toutes les passkeys futures synchronisées par le compte Google de la victime.

Les trois attaques, de la moins grave à la catastrophe

Pass-ta-key : l’usurpation d’identité machine

La première attaque exploite la clé d’identité de l’appareil stockée dans le TPM (Trusted Platform Module) de Windows et gérée par Chrome. Un malware sans privilèges peut :

1. Utiliser cette clé pour signer une requête à destination du cloud authenticator de Google.
2. Se faire passer pour la machine de confiance de la victime.
3. Obtenir une assertion d’authentification signée — l’équivalent d’un jeton de connexion valide — pour le compte ciblé.

L’attaque ne nécessite ni code PIN, ni empreinte biométrique, ni déverrouillage de l’appareil. Le TPM signe la requête, Google la valide, l’attaquant reçoit l’assertion.

Limitation. L’assertion contient un drapeau User Verified indiquant si une vérification biométrique ou par code PIN a eu lieu. Si le service cible exige et valide correctement ce drapeau, l’attaque échoue.

Unit 42 a testé l’attaque avec succès contre eBay, qui exigeait la vérification utilisateur mais ne validait pas correctement le drapeau. En revanche, GitHub — qui vérifie correctement ce drapeau — a bloqué l’attaque. eBay a depuis corrigé le problème.

Silver Pass-ta-key : l’enregistrement d’une clé malveillante

La deuxième attaque va plus loin. Elle contourne totalement la vérification utilisateur en enregistrant une clé de vérification contrôlée par l’attaquant dans le cloud authenticator de Google.

Le mécanisme :

1. Le malware invalide la clé de vérification existante de Chrome ou supprime le fichier local contenant l’état des passkeys.
2. Chrome, croyant que l’appareil n’est plus enregistré, initie une réinscription auprès du cloud authenticator.
3. Pendant cette réinscription, le cloud authenticator ne vérifie pas si la nouvelle clé de vérification provient d’un matériel de confiance (le TPM).
4. L’attaquant enregistre sa propre clé de vérification, que Google accepte comme preuve que l’utilisateur a déverrouillé son appareil.

Conséquence. L’attaquant peut désormais authentifier des requêtes avec le drapeau User Verified positionné, contournant même les services qui valident correctement ce drapeau. Et une fois la clé malveillante enregistrée, l’attaquant n’a plus besoin d’accéder à la machine de la victime — il peut opérer depuis son propre système.

Golden Pass-ta-key : le vol de la clé maîtresse

C’est l’attaque la plus sévère. Elle permet d’extraire le security domain secret (SDS) — la clé maîtresse qui chiffre toutes les passkeys synchronisées du compte Google de la victime.

Le SDS est temporairement transmis à Chrome lorsqu’un appareil s’enregistre ou récupère l’accès au compte. Unit 42 a initialement découvert que Chrome exposait ce secret en clair dans ses logs internes FIDO. Google a supprimé le secret des logs après le signalement, mais le SDS est toujours envoyé à Chrome et reste temporairement accessible dans la mémoire du processus du navigateur.

L’attaque fonctionne ainsi :

1. Le malware force la réinscription de l’appareil auprès du cloud authenticator.
2. Pendant la réinscription, il extrait le SDS de la mémoire de Chrome en recherchant un motif connu.
3. Avec le SDS, l’attaquant déchiffre toutes les passkeys synchronisées du compte Google de la victime et récupère les clés privées.

Et ce n’est pas tout. Unit 42 prévient que l’implémentation actuelle de Google ne permet pas de révoquer ou de faire tourner le SDS. La clé maîtresse volée peut donc être utilisée pour déchiffrer les futures passkeys synchronisées par le compte compromis.

Un problème d’architecture, pas de cryptographie

Le point central du rapport Unit 42 : la cryptographie des passkeys n’est pas cassée. Les algorithmes FIDO2/WebAuthn sont solides. Le problème est architectural :

• Le cloud authenticator de Google fait confiance à la machine sans vérifier l’intégrité de la chaîne de confiance matérielle (TPM → enclave sécurisée → application).
• La réinscription d’un appareil est traitée comme un événement bénin, sans challenge supplémentaire (code PIN, biométrie, deuxième facteur).
• Le SDS transite dans la mémoire d’un processus utilisateur (Chrome) accessible par n’importe quel malware sans privilèges.

Ces trois faiblesses forment une chaîne d’exploitation cohérente : compromission de la machine → réinscription forcée → extraction du SDS → compromission permanente du compte Google.

Ce que ça signifie pour le cloud passwordless

Les passkeys sont promues par l’Alliance FIDO, Google, Apple et Microsoft comme le remplacement définitif des mots de passe. Le discours officiel : « les passkeys ne peuvent pas être hameçonnées, partagées ou volées ».

Le rapport Pass-ta-key nuance ce discours d’une manière fondamentale :

Les passkeys restent très supérieures aux mots de passe. Elles ne peuvent pas être devinées, réutilisées, ou capturées par phishing classique. Mais sur une machine compromise, l’architecture de synchronisation cloud introduit un nouveau vecteur d’attaque que les mots de passe locaux n’avaient pas : le vol de la clé maîtresse de synchronisation compromet toutes les passkeys du compte, présentes et futures.

C’est l’équivalent, pour les mots de passe, de voler le coffre-fort du gestionnaire de mots de passe — sauf qu’ici, le coffre-fort n’a pas de serrure rotative.

Recommandations d’Unit 42

Les chercheurs de Palo Alto Networks formulent quatre recommandations :

• Pour les sites web : exiger et valider correctement le drapeau User Verified. Ne pas se contenter de le demander — vérifier que le relying party l’a effectivement reçu et que l’authenticator l’a correctement positionné.
• Pour les gestionnaires de credentials (Google, Apple, Microsoft) : valider l’origine matérielle des clés de vérification lors de la réinscription d’un appareil. Une clé qui n’a pas été générée par un TPM ne doit pas être acceptée.
• Pour les gestionnaires de credentials : durcir les processus de récupération et de réinscription. Une réinscription doit déclencher une vérification hors bande (email, deuxième facteur, code PIN obligatoire).
• Pour les gestionnaires de credentials : empêcher les clés maîtresses de devenir accessibles dans la mémoire du navigateur. Le SDS ne doit jamais résider dans l’espace d’adressage d’un processus non privilégié.

Verdict

Les passkeys restent l’avenir de l’authentification, mais l’architecture de synchronisation cloud actuelle est une bombe à retardement. Les trois attaques Pass-ta-key ne cassent pas FIDO2 — elles exploitent le fait que Google traite une machine compromise comme une machine de confiance tant que le TPM signe.

Pour les RSSI : continuez à déployer les passkeys — elles éliminent le phishing de masse — mais ne traitez pas une machine Windows compromise comme un scénario négligeable. Si un employé exécute un malware sur son poste, les passkeys synchronisées via Google Password Manager sont toutes compromises. La parade immédiate : exiger les passkeys liées au matériel (device-bound) plutôt que synchronisées (synced), et forcer le drapeau User Verified sur tous les services internes.

Pour Google : la balle est dans votre camp. Golden Pass-ta-key n’est pas un bug — c’est une décision d’architecture qui expose la clé maîtresse dans la mémoire d’un processus utilisateur. Corriger ce point n’est pas optionnel.

Références

1. New Pass-ta-key attacks let malware hijack Google-synced passkeys — BleepingComputer, 3 août 2026
2. Unit 42 (Palo Alto Networks) — Pass-ta-key: Three Attacks on Google’s Synced Passkeys, août 2026
3. Google Password Manager — Passkey documentation
4. FIDO Alliance — Passkeys and device-bound credentials