Pass-ta-key : la cryptographie des passkeys a tenu. La synchronisation, non.

Depuis trois ans, on présente les passkeys comme la fin du vol d’identifiants. Cette semaine, les chercheurs d’Unit 42, le groupe de renseignement sur les menaces de Palo Alto Networks, ont publié trois techniques d’attaque qui détournent les passkeys synchronisés par le gestionnaire de mots de passe de Google. Elles s’appellent Pass-ta-key, Silver Pass-ta-key et Golden Pass-ta-key, et la dernière permet de récupérer le secret unique qui chiffre tous les passkeys d’un compte.

Avant de retirer les passkeys d’un plan de déploiement : la cryptographie n’a pas été brisée. Chacune de ces techniques exige qu’un maliciel s’exécute déjà sur la machine Windows de l’utilisateur. Ce que la recherche révèle, c’est que l’industrie a renforcé la cérémonie d’authentification et laissé comparativement molle la mécanique d’inscription, de synchronisation et de récupération qui l’entoure.

Ce qu’Unit 42 a découvert

Les trois techniques vont en s’aggravant. Chacune suppose un maliciel doté de simples privilèges d’utilisateur local : aucun exploit du noyau, aucun droit d’administrateur.

Pass-ta-key extrait la clé d’identité de l’appareil utilisée par Chrome et se sert du TPM de la machine pour signer les demandes d’authentification choisies par l’attaquant. L’assertion produite n’a pas l’indicateur « User Verified » : tout service qui prend la peine de vérifier cet indicateur la rejettera. Beaucoup ne le font pas.

Silver Pass-ta-key force l’appareil à se réinscrire et glisse une clé contrôlée par l’attaquant avant que Chrome crée sa propre clé de vérification d’utilisateur. Selon Unit 42, le service ne vérifie pas qu’une clé nouvellement enregistrée provient d’un matériel sécurisé : la clé substituée est donc acceptée comme légitime.

Golden Pass-ta-key est la plus grave. Le gestionnaire de mots de passe de Google chiffre les passkeys synchronisés au moyen d’une valeur de 32 octets appelée secret du domaine de sécurité. Ce secret est transmis brièvement à Chrome chaque fois qu’un appareil s’inscrit ou récupère l’accès, et il séjourne en clair dans la mémoire du processus. Un maliciel qui déclenche une réinscription peut le lire et déchiffrer les clés privées de tous les passkeys du compte.

Pourquoi la clé maîtresse change le calcul

Un témoin de session volé expire. Un mot de passe volé se change. Or, selon Unit 42, il n’existe actuellement aucun moyen de faire tourner ni de révoquer le secret du domaine de sécurité. S’il fuit, le remède n’est pas une réinitialisation : c’est réinscrire chaque passkey du compte, sur chaque site.

Google a déjà retiré ce secret des journaux de débogage de Chrome, où passait l’une des voies de fuite. Selon les rapports, il reste récupérable dans la mémoire du processus pendant la réinscription d’un appareil, et aucun identifiant CVE n’a été attribué à ces trois techniques.

Ce que ce n’est pas

Ce n’est pas une raison de revenir aux mots de passe. Un mot de passe s’hameçonne à grande échelle depuis n’importe où dans le monde; ces attaques exigent du code déjà en exécution sur une machine précise. La barre est nettement plus haute, et les passkeys demeurent résistants à l’hameçonnage dans le cas qui compte le plus pour vos clients : un courriel convaincant un vendredi à 16 h.

Ce n’est pas non plus une faille propre à Google. La faiblesse tient au modèle même de l’authentificateur infonuagique : un identifiant synchronisé doit être récupérable d’un appareil à l’autre, et cette récupérabilité suppose qu’un secret existe quelque part pour le reconstituer. Tout fournisseur qui synchronise des passkeys au moyen d’un compte infonuagique hérite d’une version de ce problème.

Ce que les MSP et MSSP devraient faire cette semaine

1. Vérifier l’indicateur UV du côté de la partie de confiance. Une assertion sans « User Verified » doit être refusée, pas consignée. C’est le correctif le moins coûteux et il neutralise à lui seul la première technique.
2. Traiter la compromission du terminal comme l’événement racine. Chacune de ces voies commence par un maliciel sur un poste Windows géré. La couverture EDR — et savoir quels terminaux en sont dépourvus — compte davantage ici que n’importe quel réglage de passkey.
3. Alerter sur la réinscription des passkeys. Silver et Golden exigent toutes deux de forcer un appareil à se réenregistrer. Une réinscription soudaine sur un terminal que personne n’a remplacé mérite une alerte.
4. Privilégier les identifiants liés à l’appareil pour les comptes à privilèges. Là où un identifiant ne se synchronise jamais, il n’y a aucun secret partagé à récupérer. Réservez les passkeys synchronisés à la longue traîne et gardez les comptes d’administration, de finance et d’accès à distance sur une authentification liée à l’appareil et adossée au matériel.
5. Savoir où les passkeys ne sont pas encore une option. La plupart des parcs clients comptent encore des applications patrimoniales incapables d’accepter un passkey, et ce sont ces comptes qui subissent réellement des brèches aujourd’hui.

La leçon à retenir

La recherche en authentification aboutit toujours au même constat. La cérémonie de connexion est désormais la partie la plus solide de la pile, alors les attaquants se sont déplacés vers l’inscription, la synchronisation et la récupération : les chemins conçus pour la commodité, ceux que personne ne fait la démonstration. Pass-ta-key rappelle avec justesse qu’un identifiant ne vaut que le processus qui l’a provisionné et qui peut le restaurer.

La place de KZero

KZero Passwordless a été conçu sur la prémisse que cette recherche met en évidence : le point faible est le chemin de récupération et de synchronisation, non la signature. Notre authentification sans mot de passe garde les identifiants liés à un appareil et vérifiés par biométrie, de sorte qu’aucun secret conservé dans le nuage ne permet de reconstituer les identifiants d’un utilisateur ailleurs. Notre gestionnaire de mots de passe biométrique couvre les applications patrimoniales qui ne peuvent pas encore accepter un passkey — là où commencent encore la plupart des brèches réelles — et l’audit de sécurité montre aux MSP quels identifiants de leurs clients sont faibles, réutilisés ou déjà exposés.

Nous ne prétendrons pas que cela rende sûr un terminal infecté : rien ne le fait, et un fournisseur qui affirme le contraire vous vend quelque chose. Ce que cela change, c’est que compromettre une machine ne remet pas à l’attaquant la clé de tous les identifiants de l’utilisateur. Si vous gérez l’authentification pour les entreprises d’autrui, cette différence vaut la peine d’être conçue.