YubiKey et clés FIDO2 : tout ce qu'on ne vous a pas dit

Un chercheur en sécurité perd sa YubiKey en déplacement. Il n’a qu’une seule clé. 47 comptes sont verrouillés. Trois semaines à récupérer les accès un par un, via des procédures de recovery plus ou moins pénibles. “Je pensais qu’une seule clé suffisait.” C’est le cas le plus fréquent que je vois : acheter une YubiKey, l’enregistrer sur quelques comptes, et ne jamais penser au scénario de perte.

Le piège habituel

Acheter une YubiKey n’est pas une stratégie de sécurité. La clé est un outil. La stratégie, c’est le déploiement — combien de clés, sur quels comptes, où est la backup, comment gérer la perte, comment gérer le cycle de vie.

La configuration la plus fréquente que je vois : une seule YubiKey, enregistrée sur deux ou trois comptes importants (Google, GitHub), et des méthodes de recovery non sécurisées toujours actives en parallèle (SMS, email de récupération non protégé). Dans ce cas, la YubiKey est utile à la marge mais ne change pas radicalement l’exposition. Pire : si la méthode de recovery est un SMS sur un numéro mobile non protégé, l’attaquant peut bypasser la YubiKey via un SIM swap.

La règle de base : chaque compte critique doit avoir deux clés hardware enregistrées, et les méthodes de recovery alternatives doivent être au moins aussi sécurisées que la clé principale.

Les protocoles expliqués sans jargon

Une YubiKey peut fonctionner selon plusieurs protocoles différents. Comprendre lequel est utilisé pour quel compte change ce que vous pouvez faire avec.

FIDO2 / WebAuthn

C’est le protocole principal, celui que vous devriez utiliser en priorité. Il offre une protection contre le phishing qui n’existe dans aucun autre facteur d’authentification.

Voici pourquoi : quand vous enregistrez une clé FIDO2 sur un site, la clé crée une paire de clés cryptographiques liée au domaine exact du site (accounts.google.com, par exemple). Lors d’une tentative de connexion, la clé vérifie que le domaine demandant l’authentification correspond exactement au domaine d’enregistrement. Une page de phishing sur accounts-google.com ou google.com.phishing.example ne correspond pas — la clé refuse de s’authentifier. Aucun token TOTP, aucun SMS ne fait ça.

Clés résidentes (discoverable credentials) : variante où la credential est stockée sur la clé elle-même, pas seulement chez le service. Permet de se connecter sur une nouvelle machine sans entrer d’username, juste en touchant la clé. Plus pratique, mais la mémoire de la clé est limitée (YubiKey 5 : 25 clés résidentes).

WebAuthn est la spécification W3C qui standardise l’interface browser côté client. FIDO2 est l’ensemble des protocoles. Dans la pratique, les termes sont souvent interchangeables quand on parle d’authentification hardware dans un browser.

OTP (TOTP, HOTP, Yubico OTP)

La YubiKey peut générer des codes OTP à usage unique. Utile pour les sites qui ne supportent pas encore FIDO2 mais acceptent une app d’authentification.

Slot 1 et Slot 2 sur YubiKey : deux emplacements configurables pour des credentials OTP. Slot 1 est activé par défaut avec Yubico OTP (un appui court génère un OTP long). Slot 2 est configurable.

Le TOTP via YubiKey Authenticator est utile si vous voulez centraliser vos TOTP sur la clé hardware plutôt que dans une app mobile — les codes sont générés sur la clé et ne quittent jamais la clé.

PIV (Personal Identity Verification)

PIV est le standard de carte à puce pour l’authentification par certificats x.509. Il est utilisé dans :

• L’authentification SSH avec certificats (alternative aux clés SSH, avec révocation possible)
• Les environnements d’entreprise qui utilisent des smartcards (Windows Hello for Business, par exemple)
• La signature de documents avec certificat qualifié

Si vous utilisez ssh-agent avec une YubiKey en mode PIV, votre clé privée SSH ne quitte jamais la YubiKey. La signing operation se fait sur la clé, pas sur la machine hôte. Si votre laptop est compromis, l’attaquant ne peut pas exfiltrer votre clé SSH.

OpenPGP

La YubiKey peut stocker et utiliser des clés PGP pour :

• La signature de commits Git (git config --global commit.gpgsign true)
• Le chiffrement et la signature d’emails (Thunderbird + Enigmail)
• Le déchiffrement de fichiers PGP

La clé privée PGP est générée sur la YubiKey (ou importée) et ne peut pas en être exportée ensuite. C’est le même principe que PIV : les opérations cryptographiques se font sur la clé, pas sur la machine.

Choisir son modèle

YubiKey 5 NFC

Le modèle de référence. USB-A + NFC. Fonctionne avec la quasi-totalité des ordinateurs (USB-A est encore très présent) et avec les smartphones (NFC). Supporte tous les protocoles (FIDO2, OTP, PIV, OpenPGP). C’est le modèle que je recommande pour un premier déploiement.

YubiKey 5C NFC

USB-C + NFC. Indispensable si votre laptop n’a que des ports USB-C (MacBook Pro récents, laptops ultrabooks). Mêmes capacités que le 5 NFC.

YubiKey 5 Nano / 5C Nano

Format ultra-compact qui reste branché en permanence dans le port USB. Pratique pour un usage au bureau — vous ne le débranchez pas. Inconvénient : facile d’oublier de le retirer avant de donner la machine à quelqu’un, ou il reste dans le laptop volé.

YubiKey Bio

Ajoute une empreinte digitale pour l’autorisation locale. La clé n’exécute une opération FIDO2 que si l’empreinte correspond — pas de simple “touch to confirm”. Utile dans les environnements partagés ou si vous voulez éviter qu’un simple appui physique sur la clé soit suffisant. Prix plus élevé, moins de protocoles supportés (FIDO2 uniquement).

Alternatives

Nitrokey : matériel open source (conçu en Allemagne), option intéressante pour les profils qui ne veulent pas dépendre d’un fabricant américain. Moins polish dans les outils de gestion, mais fonctionnellement équivalent pour FIDO2 et OpenPGP.

Google Titan Key : non programmable, supporte uniquement FIDO2. Fiable, simple, pas configurable. Option correcte si vous voulez juste du FIDO2 sans autre protocole.

La règle des trois clés

C’est le framework de déploiement que j’applique systématiquement.

Clé primaire : sur vous en permanence, utilisée au quotidien. Peut être attachée à votre porte-clés ou dans votre sac.

Clé backup : stockée dans un lieu physique sécurisé et distinct — coffre à domicile, coffre en banque, ou chez un tiers de confiance. Cette clé n’est utilisée que si la clé primaire est perdue ou défaillante.

Clé tiers (optionnel, pour profils exposés) : chez un tiers de confiance (avocat, famille de confiance, collègue) pour les situations d’urgence extrêmes — vous êtes incapacité, détenu, ou la clé backup est inaccessible.

La règle absolue : toute clé backup doit être enregistrée sur tous les comptes critiques au moment de l’achat, pas après la perte de la clé primaire. Quand vous configurez un compte avec la clé primaire, configurez aussi la backup dans la même session. Si vous perdez la primaire sans avoir enregistré la backup sur le compte, vous êtes bloqué.

Déploiement pratique : par où commencer

Étape 1 : inventaire des comptes critiques

Avant de toucher quoi que ce soit, listez vos comptes critiques dans l’ordre de criticité :

1. Votre gestionnaire de mots de passe (Bitwarden, 1Password, Dashlane) — le plus critique, c’est la clé de voûte
2. Votre email principal — vecteur de récupération pour tout le reste
3. Compte Google ou Apple ID
4. GitHub / GitLab si vous êtes développeur
5. Comptes bancaires et crypto si applicables

Étape 2 : enregistrer les deux clés sur chaque compte critique

Pour chaque compte de la liste : connectez-vous, allez dans les paramètres de sécurité / authentification à deux facteurs, enregistrez la clé primaire, puis enregistrez la clé backup. Téléchargez les recovery codes si le service en propose — stockez-les dans votre gestionnaire de mots de passe ou imprimés dans un coffre.

Ne pas désactiver les autres méthodes MFA immédiatement. Migrez progressivement sur 2-3 semaines pour vous assurer que tout fonctionne.

Étape 3 : procédure de test

Une fois la migration terminée : testez le flux de recovery depuis la clé backup sur au moins un compte. Si vous n’avez jamais testé le recovery, vous ne saurez pas si ça marche quand vous en aurez besoin.

Cycle de vie et reset

Perte de la clé primaire : les comptes sont accessibles avec la clé backup. Commandez une nouvelle clé, enregistrez-la sur tous les comptes avant de révoquer l’ancienne (si elle est révocable — toutes les clés ne le sont pas, certains sites enregistrent juste un credential par clé physique).

Reset factory : efface toutes les credentials FIDO2 résidentes, remet à zéro les compteurs OTP, efface les slots PIV et OpenPGP. Cas d’usage : revente d’une clé, clé héritée, clé potentiellement compromise. Avec ykman fido reset pour FIDO2, ykman piv reset pour PIV.

Durée de vie : les YubiKey n’ont pas d’expiration technique. Yubico recommande de les renouveler lors d’un changement de poste ou tous les 5 ans — moins par souci technique que par hygiène de déploiement (occasion de faire l’inventaire des comptes enregistrés).

Erreurs fréquentes

Une seule clé sans backup : cas le plus fréquent. Ça fonctionne tant que vous ne perdez pas la clé.

Backup enregistrée sur seulement certains comptes : vous enregistrez la backup sur Google et GitHub mais pas sur votre gestionnaire de mots de passe. Si vous perdez la primaire, vous êtes bloqué sur le gestionnaire.

Recovery codes non sauvegardés : les codes de récupération sont votre filet de sécurité final. Si vous les perdez et perdez votre clé, la récupération peut être très complexe voire impossible.

Clé primaire et backup dans le même sac : perte des deux en même temps.

Méthodes de recovery non sécurisées toujours actives : SMS de backup sur un numéro non protégé contre le SIM swap, email de récupération sans MFA. La YubiKey ne sert à rien si l’attaquant peut bypasser via un vecteur plus faible.

• N2 Acheter minimum deux clés hardware (primaire + backup)
• N2 Enregistrer les deux clés sur le gestionnaire de mots de passe en priorité
• N2 Enregistrer les deux clés sur l'email principal et les comptes critiques
• N2 Télécharger et stocker les recovery codes offline pour chaque compte critique
• N2 Stocker la clé backup dans un lieu physique distinct de la clé primaire
• N2 Faire l'inventaire des comptes FIDO2-compatibles et migrer les plus critiques
• N2 Tester le flux de recovery depuis la clé backup sur au moins un compte
• N3 Installer ykman et faire un inventaire des credentials enregistrés sur chaque clé
• N3 Désactiver les méthodes de recovery faibles (SMS) après migration complète
• N3 Enregistrer une troisième clé chez un tiers de confiance pour les profils très exposés