Articles : OpenToken : un projet de token d'authentification matérielle ouvert
Posté par Amaury (). Modéré le 21 avril 2008.
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...
![[en]](../images/en.png)
Liste de diffusion opentoken-devel (222 hits)-
[OATH] Time-based One-time Password Algorithm (212 hits)
-
[OATH] OATH Challenge-Response Algorithms (140 hits)
-
[OATH] Différentes specs publiées par OATH (162 hits)
> Lire la dépêche (30 commentaires, moyenne: 2,6).
Vous avez demandé le commentaire #924761.
Run by 
Cette page a été générée par Templeet en 0.0818s (dont 0.008 de SQL).
Cette page est peut-être conforme xhtml 1.0.
Information sur le site.
Comment nous aider
Désolé pour ce long article, j'insiste juste sur un point :
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
Si tu veux lancer une discussion sur linuxfr, il faut l'ouvrir !
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 ?
[^]Re: Comment nous aider
J'ai utilisé à de multiples reprises les Token RSA. Soit c'est un petit boitier (~ 3x5x1 cm) sans connecteurs, ni bouton. Soit une sorte de clef USB ou l'USB ne sert à rien. Sur le Token il y a un écran LCD avec 6 digits qui change toute les 30 secondes. Ce sont ces chiffres qui sont utilisés pour se connecter au VPN de la société. ça ne se recharge pas et il y a une date d'expiration sur le token.
[^]Re: Comment nous aider
> Si tu veux lancer une discussion sur linuxfr, il faut l'ouvrir !
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
disons que si le sujet est le token, on ne sait pas quel doivent être ses propriétés. Je vois bien le genre de calculette RSA mais est-ce qu'une clef usb avec un seul bouton ne suffirait pas ?
[^]Re: Comment nous aider
La dernière spec OATH est "time based", donc on ne parle pas du token calculette mais du token sans bouton, avec juste un écran et une horloge interne.
[^]Re: Comment nous aider
Et niveau sécurité de l'engin ? Il faut protéger sa source de temps ? Il faut empêcher a tout prix l'accès a la clef prive ?
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).
[^]Re: Comment nous aider
Je ne connais pas trop le domaine, mais je me suis toujours demandé pourquoi ce genre de token n'utilisait qu'un écran pour communiquer ? Je trouve ça plutôt galère de devoir systématiquement recopier un code sur le clavier, d'autant que les utilisateurs de ce genre de token sont souvent sur un portable sans pavé numérique...
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
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.
Hurd will be out in a year (or two, or next month, who knows)
-- Linus Benedict Torvalds, 1991
[^]Re: Comment nous aider
C'est en effet plus compliqué à développer, mais uniquement du côté matériel. Il n'y a pas besoin de pilote pour un clavier USB générique, enfin je pense. Faire un pseudo clavier qui crache un code lors de l'appui sur un bouton n'implique aucun changement logiciel, à mon avis.
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
Je ne vois pas trop la différence avec la saisie avec le clavier d'origine.
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
L'idée principal est de ne pas pouvoir demander un nouveau mot de passe de façon logiciel.
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.
[^]Re: Comment nous aider
> si vous pouvez nous mettre en contact avec des fabricants, des éditeurs etc
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
La sphère publique semble plutôt s'orienter vers les certificats (logiciel, carte à puce, clé usb).
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
Merci pour ces excellents éclaircissements.
[^]Re: Comment nous aider
Réflexion de l'état sur l'authentification forte, et liste de fournisseurs de certificats:
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
P.S. pas de fichier à télécharger sur apache, car la migration est récente pour triplesec: l'origine sur safehaus: http://docs.safehaus.org/display/HAUS/Home
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
Salut,
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
J'ai l'impression qu'il y a un flottement dans le texte entre le one time password et l'authentification forte. Je connais mal les one time password. Je connais mieux les PKI.
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 ? )