Cher journal,
Je viens récemment de commander une Yubikey, une puce cryptographique avec interface USB vendue pour le grand public. Souvent, les puces cryptographiques sont vendues aux professionnels et sont difficiles à utiliser, surtout avec des postes sur lesquels on n'a pas de compte administrateur. D'où l'intérêt d'un produit qui a été conçu pour fonctionner partout.
Capacités techniques
Bien que les spécifications soient publiées, il n'est pas évident de comprendre ce que la puce sait faire à partir du site du constructeur. Faisons le tour rapidement.
La puce contient deux emplacements pour des clés symétriques. Elle ne sait pas faire de cryptographie asymétrique. On peut paramétrer chacun des deux emplacements pour trois usages distincts :
- Délivrer un mot de passe statique;
- Calculer et délivrer des mots de passe à usage unique;
- Calculer et délivrer des HMAC, pour s'authentifier par défi-réponse.
Dans les deux premiers cas, le token se fait passer pour un clavier auprès de l'hôte. Le jeu de caractères choisi par le constructeur est fait pour passer indifféremment avec des claviers qwerty ou azerty ; par contre, avec des bépo ça ne marche plus du tout. Le token dispose d'un bouton, qui déclenche l'action pour laquelle le token a été configuré.
Dans le troisième cas, il faut passer par un programme spécifique, dont l'exécution nécessite un compte administrateur sur ma machine. Je suppose donc que je ne pourrais pas l'utiliser sur une machine que je n'administre pas.
Pour des raisons de coût, la résistance de la puce aux tentatives d'extraction de clés (par des procédés logiques ou physiques) n'est pas optimisée. Cette résistance est pourtant la raison pour laquelle on a recours à ce genre de puces. Par ailleurs, il n'y a pas de blocage possible par code PIN. Moralité : on a de la sécurité, mais low cost.
À noter que ce résumé peut contenir quelques erreurs, en dépit du soin que j'ai apporté à sa rédaction. La seule référence fiable est le site du constructeur lui-même.
À quoi bon le mot de passe statique ?
Si le token ne sert qu'à taper un mot de passe statique et n'est pas protégé par un code PIN, je me demande ce que l'on gagne par rapport à un support de stockage classique, d'autant plus que le mot de passe a une taille donnée, avec un jeu de caractères donné.
Comment utiliser les mots de passe uniques
Il y a deux problèmes avec les mots de passe à usage unique :
- Le même secret doit être connu de l'authentifié (la puce) et du vérificateur;
- La puce ne peut contenir que deux secrets.
Cela limite beaucoup les utilisations commerciales possibles. Yubico installe une clé cryptographique différente sur chaque token qu'il vend, et se propose comme vérificateur central des mots de passe à usage unique. De même que les solutions d'authentification unique, c'est commode mais pas excellent en termes de vie privée.
Cela dit, on pourrait installer sa propre clé cryptographique et réaliser son authentification en interne sur sa propre machine Linux. Je n'ai pas encore cherché, mais c'est sans doute intéressant.
Utilisation du défi-réponse pour retrouver la clé de chiffrement du disque dur
J'ai bricolé mon Linux de manière à ce que, au démarrage, il envoie un défi statique à au token et utilise la réponse (statique aussi) comme clé de chiffrement de mon disque dur. Cela présente des petits avantages par rapport à un support de stockage externe classique :
- Je peux utiliser le même token physique indépendamment sur autant de machines que je veux.
- En cas de vol du token, il ne révèle pas d'information, même s'il n'est pas protégé par code PIN. Pendant ce temps, la carte mère de mon portable a un mot de passe qui rend difficile la lecture du défi statique à un attaquant qui accèderait pour quelque minutes à mon portable.
# Précision sur les mots de passe à usage unique
Posté par Al . Évalué à 2.
Quand je dis que « Le même secret doit être connu de l'authentifié (la puce) et du vérificateur », je me trompe de cible. En effet, il est théoriquement possible d'utiliser des enchaînements de hachages, qui font que le vérificateur ne peut pas produire lui-même des mots de passe utilisables. Pour autant que je sache, la Yubikey n'implémente pas ce type de mécanisme, mais en fait ce n'est pas ça en soi qui pose problème. Ce qui pose problème est plutôt qu'il faut avoir recours à un vérificateur centralisé.
# Le mot de passe statique
Posté par Anonyme . Évalué à 4.
Le mot de passe statique permet de répondre au critère « ce que j'ai » de l'identification forte. Par exemple, je m'en sert pour ouvrir ma base de donnée KeePassX. Je connais une partie de la phrase de déverrouillage et la Yubikey permet d'entrer le reste.
Bien sûr ce n'est pas totalement sûr puisque je stocke la configuration de la yubikey pour ne pas me retrouver à nu si je la perd ou si je la casse.
[^] # Re: Le mot de passe statique
Posté par fredix . Évalué à 8.
Tu la stocke dans keepassx ?
[^] # Re: Le mot de passe statique
Posté par Zenitram (site web personnel) . Évalué à 6.
Non : c'est "ce que je sais".
Justement, il faut que le mot de passe soit à usage unique pour être "ce que j'ai"! Car ton mot de passe statique, suffit d'un key logger sur la machine pour le chopper, pas besoin de l'accessoire qui ne fait que répéter. Pas pour rien que les clé RSA sont… avec des codes à usage unique (et surtout qui changent dans le temps, pour éviter de copier et devenir un "que je sais" utilisable pendant quelques temps).
Bref, bravo, tu as 2x "ce que je sais" (un dans ta tête et un dans une clé, mais le vecteur d'attaque reste le même : key logger) et 0x "ce que j'ai"! Tu peux en supprimer un, ça ne changera pas la sécurité de ta méthode (c'est juste un effet de fausse sécurité).
Ou alors, faut me ré-expliquer ce que tu fais, car j'ai compris de travers peut-être.
[^] # Re: Le mot de passe statique
Posté par Al . Évalué à 2.
C'est sujet à discussion. Par exemple, la carte bancaire est considérée comme « ce que j'ai », alors qu'il suffit de lire la bande magnétique. Disons que c'est un « ce que j'ai », mais pas très costaud.
Par ailleurs, j'ai l'habitude de retenir des mots de passe avec une entropie de 128 bits. C'est très casse-pied, donc, en principe, même si ça ne ferait pas un facteur d'authentification supplémentaire, il me paraîtrait sensé de faire taper une partie du mot de passe par un périphérique USB.
[^] # Re: Le mot de passe statique
Posté par jben . Évalué à 6.
Enfin moi je dirais plutot :
Je me demande toujours quel est l'interêt de placer un système robuste à coté d'un système passoire. Je veux bien que la bande soit utile pour certains pays, mais dans ce cas, pourquoi ne pas fournir deux cartes différentes ?
Enfin le numéro utilisé pour payer en ligne est aussi une belle blague niveau sécu. Et la puce de paiement sans contact ne me semble guère mieux.
[^] # Re: Le mot de passe statique
Posté par ribwund . Évalué à 2.
Par curiosité, pourquoi ? J'ai jamais regardé en détail, mais y'a pas de raison que ce soit moins sécurisé que la puce non ?
[^] # Re: Le mot de passe statique
Posté par jben . Évalué à 3. Dernière modification le 18 mars 2013 à 11:50.
Disons qu'il y a plusieurs problème pour moi :
Bref, même si la carte ne semble pas être duplicable par ce moyen, je pense qu'il n'est pas pour autant exempt de défauts.
[^] # Re: Le mot de passe statique
Posté par Philippe F (site web personnel) . Évalué à 1.
Si tu te colles à quelqu'un dans le métro, tu pourras lire sa carte NFC, mais c'est pas pour autant que tu pourras faire une transaction NFC par la suite. Chaque transaction (au moins pour les normes Visa, Mastercard et American Express) est sécurisée par une authentification avec la carte.
Par contre, c'est vulnérable à une attaque "Man in the Middle" bien que la mise en oeuvre me paraisse difficile : il faut sortir un bidule électronique connecté à la place d'une carte NFC devant le vendeur (qui doit n'y voir que du feu), il faut une liaison sans-fil haut débit avec un gus collé au vrai porteur pour suivre les exigences de timing de la carte sans-contact (le lecteur envoie des données, il faut répondre très vite), et il faut une parfaite synchronisation pour lire les infos de la carte du porteur à ce moment-là.
Il peut certainement passer de 5 cm à quelques dizaines de cm, mais pas à 3-4m. Quoiqu'on peut imaginer un lecteur avec une antenne ultra-directive. Si il met trop de patate pendant longtemps, ta carte va chauffer, voire brûler…
Ca va dépendre des applications mais de fait, dans pas mal de cas que j'ai vu sur le terrain, il est assez facile de demander des informations à la carte pour lui dire qu'elle doit s'authentifier, avant de prouver qu'on est un demandeur légitime.
[^] # Re: Le mot de passe statique
Posté par Hobgoblins Master (Mastodon) . Évalué à 2.
Certaines cartes bancaires NFC sont accessibles à plusieurs mètres et révèlent suffisamment d’information pour effectuer des paiements en ligne (toutes les infos imprimées sur la face) ou créer une bande magnétique valide.
Je n’ai pas retrouvé tous les pointeurs : http://www.cnil.fr/la-cnil/actualite/article/article/securite-des-cartes-bancaires-sans-contact-expertise-en-cours/, http://blogs.computerworld.com/19939/amazon_security_fail_pickpocket_bank_cards_with_nfc_phone_then_use_stolen_info, http://www.techrevolutions.fr/le-probleme-des-carte-bancaire-nfc.
[^] # Re: Le mot de passe statique
Posté par Juke (site web personnel) . Évalué à 3.
Non mais tu pourras relever son identité ce qui est déjà un problème en soit.
[^] # Re: Le mot de passe statique
Posté par oinkoink_daotter . Évalué à 2.
Et on en vient à des solutions délirantes du genre pouvoir acheter un petit étui blindé pour mettre ses CB et passeport pour éviter de se faire pister . Nan, mais [:flu], quoi.
[^] # Re: Le mot de passe statique
Posté par Juke (site web personnel) . Évalué à 0.
Ou eviter d'acheter une carte bleue.
[^] # Re: Le mot de passe statique
Posté par oinkoink_daotter . Évalué à 1.
si je me rappelle bien, les informations présentes sur la bande magnétique sont lisibles en NFC sans authentification. Y a un autre truc, mais je ne me rappelle plus.
[^] # Re: Le mot de passe statique
Posté par Kerro . Évalué à 2.
Je crois que c'est comme cela que fonctionnent les péages d'autoroutes.
[^] # Re: Le mot de passe statique
Posté par lolop (site web personnel) . Évalué à 1.
Dans ce cas, il suffit de se fabriquer une petite enveloppe à partir les sachets qui protègent les cartes de péages autoroute, si on ne les sort pas de leurs sachets, elles ne fonctionnent pas (dixit un collègue qui a eu le problème).
Ça marche peut-être aussi avec les sacs dans lesquels sont livrés les disques durs, cartes d'extension pour PC & Co, qui sont sensés préserver les matériels électroniques sensibles des champs électriques… si quelqu'un a un lecteur NFC et peut tester, ça peut être intéressant pour fabriquer des isolations pas chères, légères et pas encombrantes.
Python 3 - Apprendre à programmer dans l'écosystème Python → https://www.dunod.com/EAN/9782100809141
[^] # Re: Le mot de passe statique
Posté par Kerro . Évalué à 2.
Je parlais des cartes bancaires dans les péages d'autoroute. C'est la bande magnétique qui est utilisée.
[^] # Re: Le mot de passe statique
Posté par Olivier Filipe . Évalué à 1.
Si le sujet t’intéresses j'ai trouvé cette vidéo très intéressante.
[^] # Re: Le mot de passe statique
Posté par Zenitram (site web personnel) . Évalué à 3.
Quitte à troller… Ca aussi, à part cas exceptionnels (genre mot de passe de la partition chiffrée ou le trousseau de clé, dont le bloc chiffré est accessible au méchant si il vole ton ordi, et donc a tout le temps et tous les essais possibles), c'est totalement inutile : un fail2ban suffit à bloquer les attaques brutes ou dico, donc 4 chiffres (évitons quand même 0000) ou un mot de passe à rallonge à grande entropie, ça revient exactement au même.
Faux sentiment de sécurité, un simple keylogger fait toujours son effet et la complexité (casse-pied) n'apporte aucune sécurité supplémentaire (au contraire, elle fait croire à une meilleure sécurité ce qui est dangereux).
En fait, pas vraiment : avec la bande magnétique, pas de signature, pas de code PIN, donc ce n'est pas de l'authentification (allo la banque? Ce n'est pas moi, remboursez illico, merci. Non, je n'a pas d'assurance machin chose mais rien à foutre, c'est votre problème, vu que vous ne m'avez pas authentifié). Mais c'est clair que c'est idiot d'encore avoir ce genre d'outil de nos jours (vive la puce!)
[^] # Re: Le mot de passe statique
Posté par Al . Évalué à 1.
Euh non : comme tu le dis, le but d'un mot de passe fort est de se protéger contre le vol d'un disque dur externe, d'un ordinateur portable, d'une base de données de mots de passe personnelle etc. Dans pas mal de scénarios (exemple : vol d'un portable dans un café), le keylogger tant redouté est une préoccupation secondaire.
Il n'y a pas que les keyloggers et les tentatives de connexion répétées dans la vie du pirate : par exemple, on a eu des exemples récents de fuites de mots passe hachés de LinkedIn. Pour des mots de passe d'authentification qui peuvent être remplacés rapidement, on peut se donner moins d’exigences en termes d'entropie, mais il vaut mieux quand même prendre un minimum de précautions.
# Pour que cela fonctionne avec un clavier bepo
Posté par rahan . Évalué à 7.
Il suffit de rajouter ce bloc dans ton fichier
/etc/X11/xorg.conf(ou équivalent) :[^] # Re: Pour que cela fonctionne avec un clavier bepo
Posté par Thomas Debesse (site web personnel) . Évalué à 7.
En simple utilisateur tu dois pouvoir faire quelque chose du genre :
En ayant repéré préalablement le nom exact avec
xinput --list(Juste pour information, pour faire exactement la même chose que ce qu'a indiqué rahan<, avec le variant et le model, ce serait ainsi :
setxkbmap -device $(xinput list --id-only "Yubikey") us intl -model pc101`)ce commentaire est sous licence cc by 4 et précédentes
# MUSCLE + javacard
Posté par diorcety . Évalué à 2.
Loin de moi de critiquer ce système, mais pourquoi ne pas directement utiliser une javacard et d'installer l'applet M.U.S.C.L.E et ainsi d'avoir sa carte supportant la norme PKCS15? Ça demande un peu d'investissement et d'utiliser une carte au lieu d'une clé USB mais on peu faire du chiffrement asymétrique avec RSA en 2048 bits sans problème et directement utilisable par les logiciels le supportant. Ton certificat client dans Firefox et cie ou authentification pour ta session X11 avec ta carte (+ un code pin).
Il faut aussi investir dans le lecteur ou profiter de certaines régions qui vendent des lecteurs de carte pour les usagers des trams pour 5€. Le must c'est d'avoir le lecteur directement avec le pinpad dessus au moins tu ne passe pas par ton ordinateur (et un hypothétique keylogger au cas où on te pique ta carte juste après).
[^] # Re: MUSCLE + javacard
Posté par Al . Évalué à 2.
Dans ce cas, pourquoi ne pas acheter directement un périphérique USB pré-configuré pour PKCS11 ? Le site d'openSC mentionne quelques vendeurs dans son FAQ, dont un qui en vend pour moins de 50 euros. L'inconvénient prévisible du lecteur de cartes à puces, c'est qu'il faut le trimbaler. Alors que là, on a un objet de la taille d'une clé USB ordinaire, qui est en réalité puce au format SIM intégrée dans un lecteur.
Je m'empresse de préciser que je n'ai pas d'actions chez tel ou tel marchand de cartes à puces.
[^] # Re: MUSCLE + javacard
Posté par diorcety . Évalué à 1.
Effectivement. Peut importe le support c'est plus le standard qui est intéressant.
[^] # Re: MUSCLE + javacard
Posté par diorcety . Évalué à 1.
Par contre on perd l'avantage d'avoir un pinpad.
[^] # Re: MUSCLE + javacard
Posté par flan (site web personnel) . Évalué à 1.
Pas besoin de lecteur de carte à puce, cela fait très longtemps qu'on sait faire des « clefs USB » qui font de la crypto asymétriques (en général, des clefs RSA jusqu'à 2 048 bits). Ou alors je n'ai pas bien compris de quoi on parlait…
18€ chez Gooze : http://www.gooze.eu/epass-2003
[^] # Re: MUSCLE + javacard
Posté par diorcety . Évalué à 0.
Cela me va, cela utilise les mêmes standards. L'avantage de la clé USB c'est le format. L'avantage (inconvenant aussi) de la carte c'est le fait que tu peux aussi avoir le sans contact et le pinpad du lecteur, malgré le fait qu'il te faut le terminal.
[^] # Re: MUSCLE + javacard
Posté par ribwund . Évalué à 2.
Sinon y'a des chances d'avoir une clé USB qui fait de la crypto asymétrique dans pas trop longtemps: http://www.computer.org/cms/Computer.org/ComputingNow/pdfs/AuthenticationAtScale.pdf
# Masque jetable sur une clef usb de base
Posté par JGO . Évalué à 6. Dernière modification le 18 mars 2013 à 09:58.
Autre solution à base de masque jetable : tu choisis n'importe quel dispositif flash usb, sur lequel tu stockes une clef. L'ordinateur dispose d'une autre clef. Au démarrage l'ordinateur monte le dispositif usb, lit la clef distante et la clef stockée sur /boot, calcule le XOR des deux et obtient le mot de passe de chiffrement de /home.
Avantages : gratuit (tu as bien une vieille clef usb chez toi), le matériel qui n'attire pas l'attention, la clef peut être stéganographique (pas de fichier password.txt, la clef est la chaine située à certaine position du système de fichiers /dev/sdb). Avec un masque aléatoire, ni la clef ni l'ordinateur ne révèlent d'information, si un attaquant ne peut avoir accès qu'à un seul des deux.
[^] # Re: Masque jetable sur une clef usb de base
Posté par Julien L. . Évalué à 3.
Et en gardant la même idée d'utilisation d'une simple clé usb de stockage, pour l'authentification il y a pam_usb: http://pamusb.org/
[^] # Re: Masque jetable sur une clef usb de base
Posté par Al . Évalué à 1.
Astucieux ; par contre, je ne vois pas pourquoi tu combines deux données. Dans mon cas, l'intérêt du défi statique est de rendre difficile la duplication du périphérique USB, un peu comme s'il y avait un code PIN. Mais avec un périphérique intrinsèquement facile à copier, tu peux te contenter, pour une sécurité équivalente, de stocker la clé de chiffrement en clair dans le périphérique USB.
Bon, le fond du problème est que, de toutes façons, on finit toujours par faire circuler la clé principale en clair sur le bus de l'ordinateur, et que cette clé est la seule chose dont on a besoin pour déchiffrer le disque. Sinon, il faudrait du matériel spécialisé, genre TPM ou autre, mais je n'y connais rien.
[^] # Re: Masque jetable sur une clef usb de base
Posté par JGO . Évalué à 3.
Combiner les deux données protège en cas de perte du token. Tu changes le masque jetable et tu fabriques un nouveau token, et le premier perd toute utilité. Tu n'as pas besoin de réencoder les données avec un nouveau mot de passe. Quant à espionner le bus USB pour obtenir le mot stocké sur la clef, certes c'est possible mais si l'attaquant a les moyens d'en arriver là, il a probablement déjà essayé d'autres choses comme espionner directement le disque (une fois qu'il est monté par son utilisateur légitime), risque contre lequel de toute façon un système à token est impuissant.
[^] # Re: Masque jetable sur une clef usb de base
Posté par Al . Évalué à 1. Dernière modification le 19 mars 2013 à 15:19.
C'est une bonne remarque. La bonne nouvelle est que LUKS fait déjà ça par défaut : l'en-tête d'un volume LUKS a 8 emplacements pour des mots de passe ou clés avec des sels, qui servent à retrouver la clé maître. En pratique, on n'ouvre pas un volume LUKS directement avec la clé maître. (Oui, il m'arrive d'être un peu approximatif au niveau de la terminologie.)
La commande
cryptsetup luksDumppermet de voir, pour chaque emplacement actif, le champSalt.[^] # Re: Masque jetable sur une clef usb de base
Posté par JGO . Évalué à 4.
Tu peux inclure le fabricant/modèle/numéro_de_série du périphérique usb dans le calcul de la clef. Ce n'est une protection contre un attaquant vraiment motivé, mais l'auteur du journal fait remarquer que la Yubikey n'est pas non plus sécurisée contre l'extraction de mot de passe.
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.