Une YubiKey est un device d’authentification USB développé et vendu par la société Yubico. Ici je ne parlerai que des YubiKey version 2 standard, firmware version 2.3.1 (aujourd’hui on en ai à la version 4). Les logiciels développés par Yubico (serveur, modules pam…) pour interagir avec sont open sources. Le matériel est solide et répond à la norme IP 67 soit une protection total contre la poussière et une résistance à une immersion dans 1m d’eau pendant 30 minutes.
Elle est détectée comme un clavier standard et, dans certains cas d’utilisation, ne nécessite pas de module spécifique. Elle supporte plusieurs méthodes/algorithmes/protocoles de sécurisation. Elle dispose de deux slot de configuration (il est possible d’avoir deux configuration simultanément dans l’appareil) et peut réagir à une stimulation physique (pression sur le bouton) ou logiciel (module de dialogue spécifique). Par exemple, l’utilisateur peut déclencher la génération d’un mot de passe à usage unique (One Time Password – OTP) via une pression sur le bouton central mais peut aussi configurer une autre action lors d’un appui prolongé sur le bouton ou lors d’une requête logiciel.
Cet article est une retranscription et une amélioration de la présentation sur les YubiKey que j’ai donnée au RMLL 2014. Il ne traite que de la configuration de la YubiKey, d’autre articles traite de la configuration du système nécessaire pour s’authentifier grâce à celle-ci.
L’outil yubikey-personalization-gui
permet de configurer la YubiKey.
Il est aussi possible d’utiliser la version en ligne de commande yubikey-personalization
mais je trouve qu’elle est assez compliquée et peux verbeuse en cas d’erreur.
Différents modes de configuration sont possible, il sont décrit dans les sections suivante.
Chaque mode correspond à un onglets de l’outil yubikey-personalization-gui
.
Problème de layout
La YubiKey est détecté comme un clavier usb par le système. Lors du branchement d’un clavier le système n’a pas connaissance de ce qui est incrit sur les touches. Lors d’un appui sur un touche le système reçoit un scancode USB qui traduit en caractère via un fichier de configuration correspondant au « layout ». Par exemple si on appuie successivement sur les touche « qwerty » d’un clavier qwerty alors que le système est configuré en « azerty », les charactère « azerty » seront affiché.
Cela peut poser problème si le layout du système est trop différent du « qwerty » qui est le layout de base d’utilisation de la YubiKey.
Pour reprendre notre exemple, si on travail sur un système configuré en « qwerty » et qu’on configure notre YubiKey pour afficher un mot de passe statique « qwerty » lors de l’appui sur le boutton. Sur un système configuré en « azerty », ce n’est pas « qwerty » qui sera affiché mais « azerty ».
Plusieurs solutions existe pour résoudre se problème. Elle sont abordées dans l’article « YubiKey : layout »
Prérequis
Avant de pouvoir configurer la YubiKey vous devez configurer votre système pour avoir les droits en écriture sur celle-ci.
Logging
À la première écriture de configuration après chaque lancement de yubikey-personalization-gui
, le logiciel propose de logger les informations relative à cette écriture et aux suivante dans un fichier configuration_log.csv
.
Ce fichier contient entre autre des paramètres secrets qui peuvent être nécessaire pour configurer le serveur d’authentification mais qu’il faut prendre soin d’effacer par la suite.
Si vous relancer yubikey-personalization-gui
et que vous choisissez d’écrire dans le même fichier les anciennes ligne de log seront conservée.
Voici un exemple de log contenant chacun des modes de configuration :
LOGGING START,21/12/2014 21:31
Yubico OTP,21/12/2014 21:31,1,ccccccbjnnkv,ebfc413bfc00,5a0f660b7edbe3e58f657a8465faa6f7,,,0,0,0,0,0,0,0,0,0,0
OATH-HOTP,21/12/2014 21:32,1,ccccbjkcbkdc,,e0b0711a7de143c1e697d75f8a0a0db7a90bb680,,,0,0,0,8,0,0,0,0,0,0
Static Password,21/12/2014 21:32,2,lgegdj,728be7784d75,822d6f00919b9f09b885b7086c354c06,,,0,0,0,0,0,0,0,0,0,0
Challenge-Response: Yubico OTP,21/12/2014 21:32,1,,056f0d17b498,6a5b585272e7e6bcc1cd2e01b5213f95,,,0,0,0,0,0,0,0,0,0,0
Challenge-Response: HMAC-SHA1,21/12/2014 21:32,2,,,0232a1b60ead0680b67c9dd505860fd454ce2dbe,,,0,0,0,0,0,0,0,0,0,0
À la première écriture après chaque lancement yubikey-personalization-gui
enregistre une ligne « LOGGING START ».
Par défaut chaque ligne de log se compose des éléments suivant :
{eventType}
(chaîne de caractères) mode de configuration
-
{timestampLocal}
(chaîne de caractères) date et heure de configuration -
{configSlot}
(1 ou 2) slote de configuration -
{pubIdTxt}
(Modhex)- Yubico OTP : Public Identity
- OATH-HOTP : OATH Token Identifier
- Static Password : Public Identity
-
{pvtIdTxt}
(Modhex)- Yubico OTP : Private Identity
- Static Password : Private Identity
- Challenge-Response - Yubico OTP : Private Identity
-
{secretKeyTxt}
(Modhex) Secret Key -
{currentAccessCodeTxt}
(décimal) mot de passe actuel de protection de la configuration interne de la YubiKey. 0 indique l’absence de mot de passe. -
{newAccessCodeTxt}
(décimal) nouveau mot de passe de protection de la configuration interne de la YubiKey. 0 indique l’absence de mot de passe. -
{oathFixedModhex1}
(booléen)- OATH-HOTP : OATH Token Identifier - OMP Modhex, rest numeric
-
{oathFixedModhex2}
(booléen)- OATH-HOTP : OATH Token Identifier - OMP Modhex + TT Modhex, rest numeric
-
{oathFixedModhex}
(booléen)- OATH-HOTP : OATH Token Identifier - All Modhex
-
{hotpDigits}
(décimal)- OATH-HOTP : HOTP Lenght
-
{oathMovingFactorSeed}
(décimal)- OATH-HOTP : Moving Factor Seed
-
{strongPw1}
(booléen)- Static Password : Upper and lower case
-
{strongPw2}
(booléen)- Static Password : Alphanumeric
-
{sendRef}
(booléen)- Static Password : Send ! as prefix
-
{chalBtnTrig}
(booléen)- Challenge-Response - Yubico OTP : Require user input
- Challenge-Response - HMAC-SHA1 : Require user input
-
{hmacLT64}
(booléen)- Challenge-Response - HMAC-SHA1 : HMAC-SHA1 Mode - Variable input
Le logging peut être configuré autrement via « Settings→Logging Settings ».
Paramètres communs
Plusieurs paramètres sont commun à chacun des mode de configurations.
Configuration Slot
Comme dit plus haut il est possible d’utiliser simultanément deux configurations de types différents ou identiques. La YubiKey possède deux slotes de configurations. La première configuration est déclenchée via un appui court sur le bouton ; la deuxième par un appui long (3 secondes). L’une ou l’autre des configuration peut aussi être déclenchée de manière logiciel (réponse à une requête venant du PC). Il n’est pas possible de configurer simultanément les deux slotes pour qu’ils soit déclenchés de manière logiciel.
Ce paramètre permet de choisir sur quel slote seront appliquées les modifications apportées.
Program Multiple YubiKeys
Permet de configurer à la chaine plusieurs YubiKeys.
Automatically program YubiKeys when inserted
Après avoir cliqué sur « Write configuration » toutes les clé insérée seront automatiquement configurée sans requête explicite de l’utilisateur. Pour stopper cette configuration automatique il faut cliquer sur « Stop ».
Si cette option est décochée, l’utilisateur devra cliquer sur « Write Configuration » pour chaque clé à configurer.
Parameter Generation Scheme
Permet de spécifier comment les paramètres seront modifiés entre chaque configuration/écriture. Certains paramètre sont spécifique à un mode de configuration.
- « Increment Identity; Randomize Secrets »
- Yubico OTP : la valeur hexadécimal de « Public Identity » est incrémentée de 1 ; « Private Identity » et « Secret Key » prennent des valeurs aléatoires.
- OATH-HOTP : « MUI » est incrémenté de 1 ; « Secret Key » prend une valeur aléatoire.
- Static Password : « Public Identity » et « Private Identity » sont incrémentés de 1 ; « Secret Key » prend une valeur aléatoire.
- Challenge-Response - Yubico OTP : « Private Identity » est incrémenté de 1 ; « Secret Key » prend une valeur aléatoire.
- « Identity from serial; Randomize Secrets »
- Yubico OTP : « Public Identity » prend la valeur du « Serial Number » de la YubiKey (en modhex) ; « Private Identity » et « Secret Key » prennent des valeurs aléatoires. Le « Serial Number » est indiqué dans le bandeau de droite de l’interface. Sa valeur décimal est imprimé en chiffre et en QRcode au dos de la YubiKey.
- « Randomize all parameters »
- Yubico OTP : « Public Identity », « Private Identity » et « Secret Key » prennent des valeurs aléatoires.
- OATH-HOTP : « MUI » et « Secret Key » prend une valeur aléatoire.
- Static Password : « Public Identity », « Private Identity » et « Secret Key » prennent des valeurs aléatoires.
- Challenge-Response - Yubico OTP : « Private Identity » et « Secret Key » prennent des valeurs aléatoires.
- « Fixed Parameters »
- Static Password : tous les paramètres restent identiques.
- « Randomize Secret »
- Challenge-Response - HMAC-SHA1 : « Secret Key » prend une valeur aléatoire.
- « Same Secret for all Keys »
- Challenge-Response - HMAC-SHA1 : « Secret Key » est le même pour toutes les clés.
Configuration Protection
Les configurations stockées dans la YubiKey peuvent être protégées par mot de passe pour les empêcher d’être écrasée (avec ou sans mot de passe ces configuration sont en écriture seul… on ne peut pas les lire).
Concernant le « Serial Number », il est indiqué dans le bandeau de droite de l’interface et sa valeur décimal est imprimé en chiffre et en QRcode au dos de la YubiKey.
Les sous paramètres sont assez explicite pour ne pas nécéssité d’autres explications.
Yubico OTP
Ce mode de configuration est déclenché par un appui sur le bouton central de la YubiKey.
Mode de configuration pré-configuré, il peut être utilisé avec les serveur d’authentification de Yubico.
L’OTP est composé d’une partie statique optionnel de taille variable (max : 16 octets) appelée « Public Identity » (ou « Public ID ») et d’une partie dynamique de 128 bits.
La partie dynamique correspond à une succession de champs d’une longueur total de 128 bits le tous chiffré avec une clé AES de 128 bits (16 octets) appelée « Secret Key ». Les champs sont les suivant :
- un identifiant privé de 6 octets appelé « Private Identity » (ou « Private ID »),
- un compteur non volatile et non circulaire de 2 octets, mais seul 15 bits sont réellement utilisés (pour assurer la compatibilité avec les anciennes versions de YubiKey), appelé « Usage Counter »,
- un compteur volatile et circulaire de 1 octet appelé « Session Usage Counter »,
- un timestamp circulaire de 3 octets, il est initialisé avec une valeur aléatoire au branchement de la YubiKey et est incrémenté à la vitesse de 8Hz,
- un champ de 2 octets dont la valeur aléatoire change à chaque génération d’OTP,
- un checksum de 2 octets s’appliquant sur tous les autres champs.
À chaque mise sous tension de la YubiKey (chaque (re)démarrage du PC, chaque branchement de la YubiKey) le champ « Usage Counter » est incrémenté et le Session Usage Counter » est réinitialisé à 0. À chaque génération d’OTP le « Session Usage Counter » est incrémenté, s’il arrive à sa valeur maximal il est remis à 0 et le « Usage Counter » est incrémenté.
Le champ le plus important pour moi est le « Usage Counter » car il est non volatile et non circulaire. Cela veut dire qu’il n’est réinitialisé qu’au moment de la configuration de la YubiKey et que s’il atteint sa valeur maximum (0x7fff) il ne revient pas à 0 et la clé devient inutilisable (il faut la reconfigurer pour pouvoir l’utiliser à nouveau). Cependant si on considère une utilisation quotidienne engendrant 5 incréments du « Usage Counter », ce qui est déjà énorme si on considère que le « Usage Counter » n’est généralement incrémenté qu’après une mise sous tension de la YubiKey. Le blocage de la clé n’interviendrai qu’au bout de 18 ans. En mode manuel cet algorithme de génération d’OTP ne pose donc pas de problème mais en mode automatique (nous verrons par la suite qu’il est possible de l’utiliser en mode « déclenchement logiciel ») un attaquant peut demander la génération d’un grand nombre d’OTP et bloquer le compteur très rapidement.
Sur le serveur d’authentification le « Public Identity » (qui est statique) permet d’identifier la clé et déterminer quel clé AES-128 (« Secret Key ») doit être utilisée pour déchiffrer la partie dynamique. La taille du « Public Identity » peut être fixée entre 0 et 128 bits ; elle est par défaut à 48 bits (6 octets). Pour s’authentifier auprès des serveurs de Yubico le « Public Identity » doit obligatoirement faire 6 octets.
Un octet étant représenté par 2 caractères, les OTP généré par cette algorithme font entre 32 et 64 caractères.
Voir l’article « YubiKey : layout » pour les problèmes de layout relatif à ce mode.
OATH-HOTP
Ce mode de configuration est déclenché par un appui sur le bouton central de la YubiKey.
« Initiative for open authentication » (OATH) est un consortium d’entreprise cherchant à promouvoir l’authentification forte au moyen de technologies open-source. « HMAC Open-Time Password Algorithm » (HOTP) est un algorithme de génération d’OTP décrit dans le RFC 4226 (description de l’argorithme en français). HOTP n’a pas besoins d’horloge, il n’a pas besoins d’heure actuelle, pour fonctionner.
Lorsque la YubiKey est configurée en mode OATH-HOTP, le compteur non volatile décrit dans la section yubico otp est utilisé mais il est cyclique (il passe automatiquement de 0xff à 0x00). Le RFC 4226 indique que le compteur utilisé par l’algorithme OATH-HOTP doit faire 8 octets, ici il n’en fait que 2 (les 16 bits sont utilisés) ; des 0 sont donc ajoutés au compteur pour lui donner la bonne taille. Le compteur est incrémenté à chaque génération d’OTP.
Le serveur d’authentification possède lui aussi un compteur, il est incrémenté à chaque authentification réussi. Le compteur de la YubiKey et du serveur doivent être synchronisé pour que l’algorithme fonctionne. Si la YubiKey génère un OTP « à vide » (sans demander d’authentification au serveur) les deux compteur se désynchronisent.
Pour remédier à ce problème le serveur possède une « fenêtre d’essais ». Si une authentification échoue avec un compteur égal à x, il essaie avec x+1, x+2… x+fenêtre. À la première authentification réussi le compteur est resynchronisé. Par défaut, dans la plupart des implémentations, la « fenêtre d’essais » est fixé à 5, il suffit donc de générer 6 OTP à vide pour bloquer toutes les authentifications. Le serveur doit être reconfiguré pour débloquer la situation.
Lorsque le compteur de la YubiKey passe de 0xff à 0x00 le serveur bloque toutes les authentifications, il s’attend à ce que le compteur soit incrémenté à 0x100. Le serveur (et aussi potentiellement la YubiKey) doivent être reconfiguré pour débloquer la situation.
Les différent paramètre de ce mode de configuration sont :
- « OATH Token Identifier » : permet d’ajouter un identifiant statique devant l’OTP
- « HOTP Length » : taille des OTP qui seront générés. La norme prévoi des OTP entre 6 et 8 chiffres pour permettre une saisi par l’utilisateur. Ici la clé écrit directement l’OTP, je conseille donc d’utiliser la taille d’OTP la plus longue.
- « Moving Factor Seed » : valeur initial du compteur
- « Secret Key » : clé secrète de 20 octets utilisée par l’algorithme
Voir l’article « YubiKey : layout » pour les problèmes de layout relatif à ce mode.
TOTP
Il est aussi possible d’utiliser l’algorithme TOTP avec une YubiKey mais cela nécessite d’utilisation d’une logiciel. À la différence de HOTP, TOTP a besoins d’avoir une horloge synchronisé avec le serveur d’authentification (et non un compteur d’authentification). La YubiKey ne possède pas d’horloge interne lui permettant de connaitre l’heure exacte (juste une horloge réinitialisé à chaque mise sous tension).
Static Password
Ce mode de configuration est déclenché par un appui sur le bouton central de la YubiKey.
Il permet d’enregistrer un mot de passe statique (qui ne change jamais) sur la YubiKey. La taille maximum du mot de passe est de 38 caractères. Cela peut être util pour protéger un système qui ne pourrait pas être configuré pour tirer parti des OTP (eg. un BIOS).
Selectionnez simplement le layout « US Keyboard » (le seul disponible actuellement) et inscrivez votre mot de passe.
Voir l’article « YubiKey : layout » pour les problèmes de layout relatif à ce mode.
Challenge-Response
Les modes de configuration suivant sont déclenchés par une requête logiciel. Généralement cette requête est envoyé par un module « Pluggable Authentication Modules » (PAM) spécialement créé pour utiliser la YubiKey.
Il est aussi possible de requérir à une validation physique de l’utilisateur. Si ce mode est utilisé et qu’une demande d’authentification est envoyée à la YubiKey le voyant lumineux au centre du bouton se met à clignoter et la réponse n’est envoyée que lorsque l’utilisateur appui sur le bouton de la YubiKey.
Pour que la clé ne réponde au requête qu’après validation de l’utilisateur (appuie sur le bouton central de la clé) vous devez avoir cocher la case « Require user input (button press) » lorsque vous configurez la clé.
Ces modes de configurations ne sont pas sujet au problèmes de layout.
Yubico OTP
À ma connaissance il n’y a pas de logiciel/site permettant d’utiliser cette configuration.
Il s’agit exactement du même algorithme que celui décrit dans la section précédente. Mais la génération de l’OTP est déclenchée suite à une requête logiciel de 6 octets. Ces octets sont utilisé pour « XORé » private ID.
Une même requête ne génère pas le même OTP.
Comme décrit précédemment ce mode utilise le usage counter et bloque la YubiKey lorsque celui-ci arrive à ça valeur maximal.
HMAC-SHA1
La fonction SHA1 est une fonction de hachage. Cela veut dire, qu’a partir d’une entrée elle génère une sortie qui permet d’identifier l’entrée et à partir de laquelle il très difficile de retrouver l’entrée. « Keyed-hash message authentication code » (HMAC) est une méthode de génération de « message authentication code » (MAC) basé sur une fonction de hachage, elle est décrite plus précisément dans le RFC 2104. HMAC-SHA1 correspond donc à la méthode HMAC utilisant la fonction de hachage SHA1.
Ce mode de génération d’OTP à la particularité de ne pas utiliser de compteur, il n’y a donc pas de risque de bloquer la YubiKey. En revanche des requêtes identique génèrent des réponses identique. Ce mode de fonctionnement est donc moins sécuritaire.
- « HMAC-SHA1 Mode » : La requête logiciel est de taille variable entre 0 et 64 octets mais il est possible de forcer l’utilisation de requêtes de 64 octets.
- « Secret Key » : clé secrète de 20 octets utilisée par l’algorithme HMAC-SHA1.
Settings
Cet onglet permet d’activer/désactiver des options de configurations non disponible dans les onglet relatif au mode de configurations détaillés précédemment. Il ne correspond pas à un mode de configuration/un algorithme !
Les valeurs par défaut de la plupart de ces configurations n’ont pas de raison d’être modifiées.
« Use numeric keypad for digits » (utilisée dans l’article « YubiKey : layout ») permet d’utiliser des scancode USB du pavé numérique pour affiché des chiffres. Si cette option n’est pas activée, et que la yubikey est configuré pour affiché le mot de passe « 123 », elle enverra les scancodes USB correspondant au touches suivante, soit « &é" » si le système est configuré en azerty.
Si cette option est activée, elle enverra les scancodes USB correspondant aux touches suivante, soit « 123 » si le système est configuré en azerty :