Tout d'abord, le consortium OATH a publié les spécifications de deux algorithmes permettant de concevoir des tokens matériels :
- Une première spécification publiée courant 2004 concerne les générateurs de mots de passe en mode asynchrone : à chaque appui sur un bouton du token, un nouveau mot de passe est généré ;
- Une deuxième spécification, publiée il y a quelques jours à peine (d'où cette dépêche) traite d'un mode de génération de mots de passe à usage unique dépendant du temps, où chaque mot de passe possède une durée de vie de quelques secondes.
Et justement, le projet OpenToken vise à concevoir des tokens ouverts, ainsi que les outils logiciels associés, en se basant sur la dernière spécification OATH afin de garantir un fonctionnement transparent. Pour l'instant le projet est en cours de lancement et les objectifs sont ambitieux, n'hésitez donc pas à vous abonner à la liste de diffusion opentoken-devel pour contribuer.
Si le concept vous intéresse, ces informations sont présentées plus en détails dans la suite de la dépêche... Permettez-moi en préambule de revenir sur certains concepts de base.
L'accès à un système d'information se déroule traditionnellement en deux temps : on commence par s'identifier ("Je suis Pierre Tramo") et l'on s'authentifie ("Je prouve que je suis bien Pierre Tramo"). Cette authentification peut revêtir plusieurs formes, en fonction du niveau de confiance souhaité, que ce soit pour laché T Koms sur 1 SkyBl0g ou déclarer ses impôts en ligne.
Tout le monde connaît le couple "identifiant + mot de passe". Il est également possible d'imposer la présence d'un certificat (comme pour la télédéclaration des impôts en France), de prélever des données biométriques (empreinte digitale, intonation de la voix), voire de posséder une liste de mots de passe à usage unique sur un support physique.
Comme les exemples ci-dessus l'illustrent, l'authentification peut reposer sur 3 facteurs :
- Quelque-chose que l'on connaît (ex. : un mot de passe) ;
- Quelque-chose que l'on est (ex. : une donnée biométrique) ;
- Ou encore quelque-chose que l'on possède (ex. : un "token").
Le secteur de l'authentification forte par token est traditionnellement occupé par des éditeurs propriétaires qui verrouillent le marché grâce à des secrets de fabrication bien conservés, même si les concepts utilisés sont triviaux. Pour prendre un exemple, les tokens RSA (les plus utilisés au monde) imposent la présence d'un serveur commercialisé par RSA pour être utilisables. Le problème est qu'il n'y a aucune raison technique sérieuse derrière cette dépendance : le fonctionnement interne des tokens est largement connu [PDF] et développer un serveur d'authentification compatible serait aisé. Ce sont principalement des contraintes légales et contractuelles qui empêchent de proposer des alternatives libres.
Forts de ce constat, de nombreux acteurs ont décidé de travailler ensemble pour mettre en place un standard dans ce domaine, à l'exception notable de RSA qui, conscient de sa position de leader, préfère favoriser sa propre technologie propriétaire. Le consortium OATH (initiative for Open AuTHentication) a donc été créé afin de proposer un framework ouvert de référence pour l'authentification et notamment le Single Sign On. Les travaux publiés par OATH peuvent paraître bien abstraits. Ils présentent néanmoins un réel potentiel et contribuent à poser les bases d'un système de gestion d'identité ouvert et indépendant des éditeurs. Après des débuts poussifs courant 2004, l'initiative OATH commence à prendre du poids. Il a quelques jours de cela, un document rédigé par l'OATH a été remis à l'IETF. Ce document décrit une méthode de génération de mots de passe à usage unique, permettant de concevoir des tokens présentant des fonctionnalités identiques aux tokens les plus utilisés (suite de nombres en apparence aléatoires, changeants au fil du temps).
Ce standard pourrait donner naissance à une famille de tokens "ouverts" qui n'auraient pas besoin d'être adossés à un serveur propriétaire pour pouvoir fonctionner.
Beaucoup de chemin reste néanmoins à parcourir : en 2004, un premier draft publié par OATH portant sur une autre méthode de génération de mots de passe à usage unique (indépendante du temps cette fois) avait permis la création de tokens en théorie librement utilisables (puisque l'algorithme de fonctionnement du token est connu), mais liés dans la pratique aux serveurs de l'éditeur, notamment à cause du chiffrement de la clef secrète (seed) stockée dans les tokens, qui empêche de connaître cette clef pour alimenter le serveur d'authentification.
Et c'est dans cette optique qu'un petit groupe de personnes, dont votre serviteur, ont l'intention de monter un projet dont le but serait de concevoir un token complètement ouvert permettant à n'importe qui de disposer d'une solution d'authentification forte qui ne coûterait que le prix des tokens (de quelques euros à quelques dizaines d'euros selon le procédé de fabrication). Il existe aujourd'hui de nombreuses solutions d'authentification forte logicielles open-source (principalement des infrastructures de gestion de clefs, également connues sous le nom de PKI), mais aucune mettant en oeuvre des tokens physiques. Les deux systèmes (PKI et tokens) présentent leurs avantages et inconvénients qui sortent du cadre de cet article. Il n'existe à ce jour et à notre connaissance aucune solution d'authentification matérielle libre. D'autres initiatives liés à l'authentification par token ont été lancées (MyPW loue des tokens à l'unité, Verisign Labs permet d'ajouter une couche d'authentification forte sur OpenID, Paypal commercialise des tokens à bas prix), mais nulle initiative lancée par la communauté, pour la communauté.
Ce projet peut paraître simple en apparence, mais les contraintes sont multiples. Les tokens ne forment que la partie émergée de l'iceberg. En effet, la partie logicielle d'authentification mène très vite aux problématiques, complexes, d'échange sécurisé des clefs secrètes, de "provisionning" et autres domaines touchant à la gestion d'identités, sans compter les contraintes de re-synchronisation des tokens, la coordination avec l'initiative OpenID etc. L'objectif est sans doute ambitieux : produire industriellement des tokens demande une mise de fonds importante. Peut-être serait-il possible de produire des tokens artisanaux dans un premier temps pour valider le concept. Autant le dire tout de suite, le projet est assez casse gueule...
Bref, nous cherchons des gens pour discuter de la faisabilité du projet. Dans un délire d'originalité et après 7 secondes de brainstorming intense, le projet a été (temporairement) nommé OpenToken et une liste de diffusion sur Sourceforge est d'ores et déja disponible : opentoken-devel (chez) lists.sourceforge.net. Si vous y connaissez quelque-chose en authentification forte, en électronique ou si plus généralement le sujet vous intéresse, n'hésitez pas à vous inscrire pour nous faire part de vos idées, forcément géniales (anglais ou français accepté), voire trol^wajoutez un commentaire à cette dépêche, nous sommes preneurs aussi.
Si tout va bien dans quelques années il sera possible d'utiliser une solution entièrement libre pour s'authentifier avec des tokens. Ouais, on peut rêver ! :-)
Aller plus loin
- Liste de diffusion opentoken-devel (71 clics)
- [OATH] Time-based One-time Password Algorithm (76 clics)
- [OATH] OATH Challenge-Response Algorithms (41 clics)
- [OATH] Différentes specs publiées par OATH (34 clics)
# Comment nous aider
Posté par Amaury . Évalué à 10.
Si vous connaissez des projets similaires, actifs ou morts, si vous connaissez le secteur de l'auth forte, si vous avez un retour d'expérience sur le sujet, si vous pouvez nous mettre en contact avec des fabricants, des éditeurs etc, on est preneur, soit dans les commentaires de la news, soit sur la liste...
[^] # Re: Comment nous aider
Posté par Nicolas Boulay (site web personnel) . Évalué à 3.
Je connais un peu la sécurité et un peu plus l'électronique, mais difficile de commenter quand il n'y a pas de problématique posée.
Qu'elles sont vos difficultés ? Qu'elle forme électronique ont les tokens ? Est-ce des cartes a puce, des clefs usb ou rien a voir ?
"La première sécurité est la liberté"
[^] # Re: Comment nous aider
Posté par ashram4 . Évalué à 1.
[^] # Re: Comment nous aider
Posté par Amaury . Évalué à 1.
J'avais justement l'impression d'ouvrir la discussion.
Nos questions sont super ouvertes : "comment on avance ?" plutôt que "on colle le composant XZR86 ou le 2865NF ?".
Les personnes ayant envie de contribuer au projet sont donc invitées à s'inscrire à la ml...
[^] # Re: Comment nous aider
Posté par Nicolas Boulay (site web personnel) . Évalué à 2.
"La première sécurité est la liberté"
[^] # Re: Comment nous aider
Posté par Amaury . Évalué à 1.
[^] # Re: Comment nous aider
Posté par Nicolas Boulay (site web personnel) . Évalué à 3.
Par ce que réaliser ce genre de compteur avec un écran, cela représente rien en électronique. (en gros, je sais faire)
Par contre, faire la même chose en protégeant toutes les IOs, c'est une autre paire de manche. (protection de la RTC, utilisation de puce de carte a puce pour planquer la clef, utiliser sans doute un autre uP pour gérer l'affichage, etc...)
J'imagine qu'un truc le moins chére possible mais non sécurisé pourrait amorcer le projet. Déjà si la clef prive dépend du porteur et non du systèmes, il y a moins besoin de sécuriser la calculette contre les attaques hardware (en gros que chaque carte contient une clef différente, cela complique les attaques sur la clef).
"La première sécurité est la liberté"
[^] # Re: Comment nous aider
Posté par François B. . Évalué à 3.
N'est-il pas possible de penser à un truc qu'on pourrait brancher par USB sur l'ordinateur ? Bien sûr, copier un code dans une zone de texte fonctionne partout... mais pourquoi ne pas faire passer le token pour un clavier qui balancerait le code suite à l'appui sur un bouton ? Il suffirait juste de mettre le focus sur le bon champ avant d'appuyer sur ledit bouton. Je pense que même Windows est capable de gérer le branchement à chaud d'un clavier USB.
[^] # Re: Comment nous aider
Posté par jcs (site web personnel) . Évalué à 2.
Outre le fait que techniquement c'est beaucoup plus compliqué (pilotes...), brancher le token sur une machine c'est également s'exposer à un risque si la machine a été compromise : on peut par exemple imaginer un logiciel qui en toute discrétion récupère plusieurs OTP valides, ou qui tout bêtement récupère un OTP valide mais en envoie un invalide faisant croire que le service d'authentification ne fonctionne pas. Et tout ça dans le dos de l'utilisateur.
[^] # Re: Comment nous aider
Posté par François B. . Évalué à 4.
Sinon, concernant le détournement d'un code, il est tout à fait possible de faire la même chose avec un token à écran : si la machine a un cheval de Troie qui prend ce que l'utilisateur a saisi puis fait croire que la saisie n'est pas valide on arrive au même point. Et du point de vue du code malicieux, je pense qu'il est plus intéressant de laisser passer l'étape d'autentification de l'utilisateur puis accéder au ressources protégées ensuite : les codes ont une valeur limitée dans le temps, ça ne sert à rien d'en conserver pour plus tard.
[^] # Re: Comment nous aider
Posté par Sébastien Koechlin . Évalué à 3.
On peut imaginer même de supprimer le bouton. Comme l'USB est hotplug; on peut programmer le contrôleur de la clef pour se déclarer comme Clavier HID, et envoyer la séquence 2 secondes après avoir été branché. Ça évite d'avoir une pièce mécanique qui tombe en panne et qui augmente les coûts.
[^] # Re: Comment nous aider
Posté par Nicolas Boulay (site web personnel) . Évalué à 2.
Il existe des cartes à puces ayant une interface USB, il doit être possible de les utiliser, sauf si elle implémente une norme spécial.
"La première sécurité est la liberté"
[^] # Re: Comment nous aider
Posté par IsNotGood . Évalué à 1.
Je ne peux pas vous mettre en contact avec des personnes intéressées. Désolé.
Mais, avez-vous regardé du côté des gouvernements, de l'UE, des militaires, etc ?
[^] # Re: Comment nous aider
Posté par Earered . Évalué à 3.
Entre autre sur des aspects de chaîne de confiance (vérification de respects des règles de sécurité de l'émetteur de certificats, signature par une autorité de certification).
Mais aussi de signature de fichier, et de chiffrement/confidentialité des données (les aspects que l'auteur de la dépêche n'a pas voulu approfondir à raison pour ne pas alourdir son propos).
Les tokens ont d'autres avantages et inconvénient.
Personnellement, je vois l'aspect consultant nomade utilisant des terminaux chez le client qui doit s'assurer que même si le mot de passe est logger, au moins il ne pourra pas être réutiliser. Ou en cas de vol de portable, que les accès à l'intranet ne soit pas compromis (donc certificat logiciel mort, puce et usb ça réclame du matos particulier sur le portable matériel ou driver, et ne permet pas l'usage de tous les terminaux).
La défense ayant tendance à isoler son intranet (pas d'extranet), les personnes intéressés sont plutôt, enfin je pense, du secteur privé manipulant des données confidentiels, en réseau (gros), avec une pointe d'externalisation (j'ai des noms de 2 clients des safeword de Secure Computing Corporation mais je ne dénoncerais pas :p ).
Mais pour construire une entreprise la dessus (c'est p'tet pas le projet), trouver 3 clients, et leur proposer d'investir pour créer le service ça peut être une bonne idée. (pour la pépinière, je recommande Grenoble, c'est par là qu'on trouve les gens qui conçoivent les circuits et micro-processeur... quoi, comment ça on y est pas encore? allez, hop hop yaplukafaucon! ^_^).
[^] # Re: Comment nous aider
Posté par IsNotGood . Évalué à 1.
[^] # Re: Comment nous aider
Posté par Earered . Évalué à 4.
http://www.synergies-publiques.fr/rubrique.php?id_rubrique=1(...)
http://www.telecom.gouv.fr/rubriques-menu/entreprises-econom(...)
C'est orienté carte à puce (France oblige?), donc c'est un peu la "concurrence" mais certaines des réflexions s'appliquent (niveau de confiance, remise de l'objet de la main à la main, etc...).
Coté serveur, il y a peut être déjà tout ce qu'il faut
http://directory.apache.org/
Triplesec en particulier, le module pour générer les tokens proposé sur le site est un logiciel pour PDA/blackberry mais le bébé semble conçu pour fonctionner avec des tokens matériels.
A vu de nez pas de gros problèmes pour que tout ce petit monde s'entende "Programmable mobile device can use any 2-factor auth algorithm to leverage existing investments in FOB hardware" sauf que "Single use HOTP passcodes do not require time synch or phone service", à creuser.
et préparer le business plan (service de configuration, mise en place, intégration de apache directory et vente de tokens, niveau 1 d'identification, et pour plus tard organisation et vérification des papiers d'identité remise en main propre et référence PRISv2?) ^_^
Le problème semble plus s'orienter vers la construction de matériel/électronique non?
[^] # Re: Comment nous aider
Posté par Earered . Évalué à 2.
N.B. vi, je sais pour le PRIS gros crackage, c'est plus destiné aux certificats, toussa, mais bon, dans l'idée, s'inspirer des recommandations des certificats pour fournir du conseil aux entreprises qui utilise les tokens, ça peut être une idée
[^] # Re: Comment nous aider
Posté par prunille . Évalué à 2.
concernant les projets similaires, j'avais regardé triplesec passé de Safehaus à Apache. Il semble cependant être mort. L'idée que je pense la plus intéressante de mon point de vue est de produire un soft et de réutiliser le téléphone mobile : l'authent forte pourrait être libre et gratuite...
concernant le nom, OpenToken est déjà plus que largement utilisé si j'en crois Google. De plus, il l'est pour une spécification déposée (encore en draft) à l'IETF par la société PingIdentity. Ils ont autre chose à faire qu'à vous poursuivre mais personnellement, je verrai bien autre chose comme nom : ToPen par exemple.
pour ce qui est des éditeurs, il en est un auquel je pense : OpenTrust. Ils ont une vraie expertise sur la PKI et les token matériels.
Bon courage.
[^] # Re: Comment nous aider
Posté par octane . Évalué à 4.
Voici mes deux euro-cents sur l'authentification forte et les tokens matériels:
Question: comment garantir de la crypto forte?
-> première sous question: que veut on protéger?
Réponse: 3 grandes familles existent: le chiffrement, la signature, et l'authentification.
Ces trois familles reposent sur le mécanisme de clé privée / clé publique. Ce concept de clé privée /publiques est celui qui nous intéresse ici. Associé aux clés publiques, un certificat qui ajoute des informations comme l'adresse mail du possesseur de la clé publique, des dates de validité, etc..
La clé privée est privée et ne doit être connue que du possesseur de la clé. Le certificat (et la clé publique associée) sont publics, (ie diffusables partout)
Cette crypto est communément appelée PKI, et la PKI correspond à une mise en oeuvre de ces mécanismes. De très nombreuses RFC définissent ce qu'il faut faire pour construire une PKI. Dans le logiciel libre openssl a tout ce qu'il faut pour batir une PKI.
En gros:
-on génére une autorité (un couple de clé et certificat).
-On génére des couples clés privés/publics pour chacun de nos utilisateurs.
-Les certificats sont signés par l'autorité (comprendre authentifiés par l'autorité)
Puis, toute personne qui souhaite utiliser notre PKI doit agréer l'autorité, en gros faire confiance a cette autorité, et par la, faire confiance aux certificats signés par celle ci.
Donc un user peut récuperer un certificat quelquepart, vérifier son authenticité, puis l'utiliser.
Ca, c'est pour la théorie. Je passe les mécanismes de révocation de certificats, de mécanisme permettant l'authent, la signature et le chiffrement.
Bref.
Venons en au point qui nous intéresse, les cartes à puce (ou token USB).
Un point crucial concernant ces PKI concerne la clé privée. Si elle est diffusée, forcément, elle ne sert à rien.
Et survient un paradoxe: comment être persuadé que la clé privée ne fuite jamais dans aucun cas alors qu'il faut l'utiliser?
La solution réside dans l'utilisation d'une carte à puce. Une carte à puce est un ordinateur complet, et donc, la clé privée ne sort jamais de la carte à puce. Toutes les opérations crypto sont réalisées par la carte à puce, depuis le tirage des clés, jusqu'aux opérations de chiffrement/déchiffrement. La clé privée est donc parfaitement protégée, et la carte à puce elle même peut protéger des brute force en détruisant la clé au bout de trois tentatives de code PIN.
C'est donc génial (du point de vue crypto). Mais.
Mais tout n'est pas si évident. Et entre autre vient le point noir de la communication entre un programme local au PC et la carte à puce. Une norme de communication existe et s'appelle la norme PKCS#11. Les constructeurs de carte à puce fournissent donc un middleware (un driver, quoi) permettant de présenter une interface PKCS#11 à un programme du PC. Et ces middleware existent uniquement sous windows. Certains middleware ont existé sous linux (je pense au clés token USB rainbow ikey1000) mais sous la forme de blobs binaires, attachés à une certaine version de noyau.
Bref:
la solution serait effectivement d'implémenter:
-premièrement d'une couche PKCS#11
-deuxièmement du pilote spécifique pour une carte particulière
-troisièmement une couche applicative (un add-on pour openssl ? )
# OTP
Posté par Annah C. Hue (site web personnel) . Évalué à 1.
[^] # Re: OTP
Posté par Amaury . Évalué à 2.
> implémenter l'OATH.
Oui et non.
Oui car en effet c'est possible techniquement, comme d'ailleurs on peut le faire sur un PC, un PDA ou tout autre matériel avec suffisamment de puissance de calcul...
Non car tout le principe du token matériel repose sur la nécessité de posséder le bidule : le token doit être suffisamment sécurisé pour qu'on ne puisse pas récupérer la clef secrète de manière triviale (perturbations, démontage...).
Si tu peux installer le logiciel de génération de mot de passes dessus, tu peux très probablement installer un keylogger qui enregistrera les mots de passe, voire te choper un virus ou un trojan qui récupérera la clef secrète et l'enverra ailleurs (clef secrète compromise = n'importe qui peut prévoir les mots de passe à venir). Une solution logicielle sur un outil communiquant ne présente pas du tout le même niveau de sécurité qu'un token physique dédié, machine "autiste" sans possibilité de communication autre que le fait d'afficher les mots de passe générés.
Un PC / PDA / téléphone avec un soft qui tourne dessus s'apparente donc plus à du "quelque-chose que je connais" que "quelque-chose que je possède". Et ce n'est pas vraiment de l'authentification forte, quoi qu'en disent les vendeurs.
La solution serait éventuellement d'avoir une carte matérielle dans le téléphone ou le PC, chargée d'effectuer les calculs, mais même là les possibiltés d'interception sont importantes.
Au final, rien ne vaut le bon vieux token (ou la feuille de papier avec 50 mots de passe à usage unique).
[^] # Re: OTP
Posté par briaeros007 . Évalué à 2.
Ca s'apelle la carte SIM, et normalement, une partie doit être protégé des agressions physiques (ie essayer de récupérer physiquement la valeur d'un registre).
[^] # Re: OTP
Posté par Earered . Évalué à 3.
Ou les prononcer? (je pense aux aveugles qui seraient excluent des procédures / accès sécurisé de l'entreprise si une version avec casque audio n'est pas inventé.).
P.S. une idée pour les sourds et aveugles?
[^] # Re: OTP
Posté par jeffcom . Évalué à 2.
[^] # Re: OTP
Posté par Earered . Évalué à 4.
Pour les aveugles de naissance, je suppose que c'est plus pratique (et n'est pas exclusif, l'audio est un plus: prix d'un PC + gutemberg project vs livres en braille. J'ai plusieurs fois vu des aveugles avec PC dans le TGV donc je pense qu'il y a un intérêt).
Mais on ne nait pas forcément aveugle, et l'apprentissage d'un nouvel alphabet/méthode de lecture à 80 ans n'est pas forcément ce qu'il y a de plus évident (ma grand mère avait essayé). D'ou bémol.
[^] # Re: OTP
Posté par jeffcom . Évalué à 2.
[^] # Re: OTP
Posté par palm123 (site web personnel) . Évalué à 3.
Oui, le F et le S, par téléphone, c'est une catastrophe. J'ai travaillé dans un centre de support et vite pris l'habitude de dire F comme France, S comme Sierra...
En japonais, le R et le L sont proches.
Il y a un petit livre sur le japonais avec un joli dessin sur la couverture, 2 personnes se téléphonent
- avec un L comme dans Roma ?
- non, avec un R comme dans London
ウィズコロナ
[^] # Re: OTP
Posté par Pierre Jarillon (site web personnel) . Évalué à 2.
Ce n'est pas la peine d'aller chercher très loin, le basque a deux sons R :
- le R doux quand il est entre 2 voyelles (ex: hari = fil), c'est presque un L.
- le R dur dans les autres cas (ex: harri = pierre).
Un peu plus loin, il y a les antillais qui ne p'ononcent pas les è'. Un jour, j'ai demandé à un copain antillais qui avait ce type d'élocution de me prononcer "J'ai vu trois gros rats gris dans trois gros trous creux". Aussitôt il m'a répété la phrase aussi parfaitement que le ferait Audrey Pulvar au journal télévisé. Très étonné, je lui dis "Tu sais donc prononcer les R ?" et il m'a répondu "Oui je sais pa'ler en p'ononçant les è', mais ça me fatigue".
Il n'y donc pas une façon unique de présenter un mot de passe, l'écran LCD, la voix et la planchette braille sont forcément complémentaires.
[^] # Re: OTP
Posté par jcs (site web personnel) . Évalué à 2.
Cela fonctionnait pas trop mal sauf que la clé (le secret partagé) étaient stocké en clair dans mon téléphone. Une solution consiterait à le stocker dans la SIM mais je doute qu'on puisse y avoir facilement accès depuis les API disponibles au niveau du téléphone. Une autre possibilité serait de stocker une version chiffrée du secret puis de demander à l'utilisateur un mot de passe. Toutefois sur un clavier de téléphone portable c'est pas très ergonomique.
[^] # Re: OTP
Posté par Nicolas Boulay (site web personnel) . Évalué à 3.
De plus, certain téléphone ont des fonctionnalités proche de celle des cartes a puces.
"La première sécurité est la liberté"
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.