Un Raspberry Pi qui se fait passer pour une YubiKey

Vous configurez votre fournisseur d’identité pour n’accepter qu’un modèle précis de clé matérielle certifiée. Le tableau de bord affiche que tout est conforme. Et pourtant, un Raspberry Pi à quelques euros vient de s’enregistrer comme une YubiKey 5 NFC. Présentée à BarbHack 2026, cette vulnérabilité de Keycloak (CVE-2026-6856, depuis corrigée) n’a rien cassé de cryptographique. Elle a simplement retiré quelque chose de la requête d’enregistrement.

Huitième volet de notre couverture de BarbHack. C’est un cas d’école sur une question qui dépasse largement Keycloak : que vérifie réellement un contrôle de conformité ?

Pourquoi les passkeys, en deux minutes

Le mot de passe cumule des défauts structurels. Un bon mot de passe est par définition difficile à mémoriser, ce qui pousse à la réutilisation. Il est vulnérable au regard par-dessus l’épaule et surtout à l’hameçonnage, puisqu’un service malveillant qui imite un service légitime récupère un secret directement rejouable. Enfin, il implique de partager un secret avec le serveur : votre sécurité dépend de la sienne.

Les passkeys renversent le modèle. Elles reposent sur la cryptographie à clé publique : le serveur ne conserve qu’une clé publique et des métadonnées, et ne détient donc plus aucun secret à se faire voler. Elles sont surtout résistantes à l’hameçonnage par construction : la clé privée signe l’origine, c’est-à-dire le domaine du service. Une signature produite pour un domaine malveillant est inutilisable sur le domaine légitime.

Le tout s’appuie sur deux standards de l’alliance FIDO : CTAP2, entre le client et l’authentificateur, et WebAuthn, entre le navigateur et le service. À l’authentification, une signature d’assertion est produite puis vérifiée avec la clé publique correspondante.

Deux familles, deux modèles de menace

• Les passkeys « Platform » stockent la clé privée sur l’appareil lui-même, déverrouillée par biométrie ou code PIN. Elles se synchronisent au sein d’un écosystème, et désormais même entre écosystèmes, ce qui règle élégamment la question de la sauvegarde. Leur faiblesse est logicielle : une vulnérabilité divulguée le 11 août 2026 a montré qu’un maliciel pouvait exfiltrer des clés privées depuis le disque et les rejouer depuis une autre machine.
• Les passkeys itinérantes stockent la clé sur un dispositif matériel distinct, qui signe lui-même et communique en USB, NFC ou Bluetooth. Sécurité supérieure, certifications à l’appui, et une conception qui empêche l’extraction de la clé privée. Leur faiblesse est l’inverse de la précédente : aucune synchronisation, donc une stratégie de sauvegarde à prévoir en cas de perte ou de vol.

Il n’y a pas de gagnant universel. Pour un service courant, une passkey « Platform » suffit et relève déjà nettement le niveau. Pour un environnement à forte exigence, on impose des passkeys itinérantes. C’est exactement ce que Keycloak permet de faire, et c’est là que l’histoire commence.

Le filtrage par AAGUID, et sa promesse

Keycloak est une solution libre de gestion d’identité et d’accès, soutenue par Red Hat, très répandue dans les administrations et les banques. Elle intègre les passkeys et propose un « Sign in with Passkey » qui remplace la saisie d’identifiant et de mot de passe.

L’alliance FIDO attribue à chaque modèle de passkey un identifiant unique, l’AAGUID. Keycloak sait n’accepter que certains AAGUID, et donc n’autoriser qu’un matériel précis. La promesse est forte : garantir que chaque authentifiant du parc repose sur du matériel certifié, et pas sur une clé logicielle recopiable. Le test de contrôle fonctionne d’ailleurs comme prévu : avec un AAGUID imposé, l’enregistrement d’un appareil non autorisé échoue.

La faille : ce que la norme vous oblige à accepter

WebAuthn prévoit plusieurs formats d’attestation, le mécanisme par lequel un authentificateur prouve ce qu’il est. Parmi eux, l’auto-attestation : la passkey signe elle-même son attestation avec sa propre clé d’usage, sans autorité tierce. C’est prévu, légitime, et utile pour des authentificateurs qui n’embarquent pas de certificat constructeur.

La norme précise alors une règle : si la chaîne de certificats d’attestation (X5C) est absente, le service doit considérer qu’il s’agit d’une auto-attestation. Keycloak, via la bibliothèque qu’il utilise, suivait scrupuleusement cette règle. Mais il ne vérifiait pas une seconde chose : si l’auto-attestation devait être autorisée alors que le filtrage par AAGUID était actif.

L’exploitation tient en une phrase. On retire la chaîne de certificats de la requête d’enregistrement. Keycloak en déduit une auto-attestation, et accepte l’enregistrement sans contrôle supplémentaire, y compris avec l’AAGUID revendiqué d’un appareil sécurisé.

Démonstration à l’appui sur scène : un Raspberry Pi Pico équipé d’un micrologiciel d’émulation de clé FIDO (pico-fido) enregistré en se faisant passer pour une YubiKey 5 NFC.

L’impact, et pourquoi il est facile à sous-estimer

Soyons précis, parce que c’est ce qui rend le cas intéressant : l’authentification n’est pas contournée. Il faut toujours un authentifiant valide pour se connecter. Ce qui disparaît, c’est la garantie matérielle, c’est-à-dire précisément la raison pour laquelle on avait activé le filtrage.

Concrètement, un acteur malveillant pouvait enregistrer une passkey logicielle, la cloner et compromettre le compte, dans un environnement qui avait été conçu pour rendre cela impossible. Et pendant ce temps, l’interface d’administration continuait d’afficher un parc conforme, puisque l’AAGUID revendiqué était le bon. C’est la définition d’un angle mort : le contrôle ne tombe pas en erreur, il valide.

Signalement et correctif

Le déroulé est exemplaire et mérite d’être salué : problème signalé en mars, CVE attribuée en avril, correctif publié cinq jours plus tard dans une version de maintenance. La correction est aussi simple que la faille : si un AAGUID est configuré, l’auto-attestation est automatiquement désactivée. Les deux contrôles, jusque-là indépendants, sont enfin liés.

Ce qu’on en retient chez Humanix

• Un contrôle qui vérifie une affirmation fournie par celui qu’on contrôle n’est pas un contrôle. L’AAGUID est une métadonnée déclarée par l’authentificateur. Seule la chaîne d’attestation la transforme en preuve. Retirez la chaîne, l’affirmation demeure, la preuve disparaît, et le filtre continue de dire oui. Ce schéma se retrouve partout, bien au-delà de WebAuthn.
• Suivre la norme à la lettre ne suffit pas. Chacun des deux comportements de Keycloak était correct isolément : traiter une attestation sans X5C comme une auto-attestation, et filtrer par AAGUID. C’est leur composition qui était fautive. Quand vous implémentez un standard complexe, la vraie question n’est pas « est-ce conforme » mais « qu’est-ce que j’autorise, et qu’est-ce que je restreins, dans mon contexte ».
• Testez ce que votre filtre garantit vraiment. La vérification tient en deux essais : tenter d’enregistrer un appareil non conforme, puis recommencer en altérant la requête. Le premier échoue, ce qui rassure ; c’est le second qui vous apprend quelque chose. C’est peu coûteux, reproductible, et c’est le genre de test qui devrait accompagner toute politique d’authentification forte.
• Choisissez le type de passkey selon votre modèle de menace, pas selon la mode. Une passkey « Platform » élève déjà fortement le niveau d’un service courant, mais elle vit dans un système d’exploitation exposé aux maliciels, comme l’a rappelé la divulgation du 11 août 2026. Une passkey itinérante résiste à cela, au prix d’une vraie politique de sauvegarde et de révocation.
• « Conforme » n’est pas une propriété de sécurité. Ici, le tableau de bord disait vrai au sens des données reçues, et faux au sens de la réalité physique. C’est exactement le genre d’écart qu’on ne réduit pas avec un audit documentaire, mais en le mettant en situation : la preuve avant le verdict.

Note. Compte-rendu, à visée pédagogique, d’une conférence de BarbHack 2026 consacrée aux passkeys et à un contournement du filtrage par AAGUID dans Keycloak. La vulnérabilité a été signalée de manière responsable par l’intervenant et corrigée par l’équipe Keycloak ; assurez-vous simplement d’exécuter une version postérieure au correctif. Huitième volet de notre couverture de l’événement. Une politique d’authentification forte à mettre à l’épreuve ? Contactez-nous.