Brevet FR3026875A1 — publié le 20160408

Domaine de l'invention La présente invention concerne le domaine de l'authentification sécurisée. Elle concerne plus particulièrement un procédé de configuration d'un 5 périphérique de type terminal mobile pour une telle authentification. Etat de la technique Les entreprises disposent aujourd'hui généralement d'une architecture basée sur des comptes utilisateurs. Chaque collaborateur de 10 l'entreprise se connecte à son compte via une saisie d'un couple login/mot de passe. Lorsque le collaborateur est en déplacement des mécanismes permettent à ce dernier de se connecter d'un poste de travail distant, par exemple un activant un réseau privé virtuel (VPN). 15 Dans la mesure où les couples login/mot de passe sont parfois faciles à découvrir, dans un contexte actuel de recrudescence des actes de cyberpiratage et d'intrusion dans les systèmes d'information des systèmes d'information des entreprises par des personnes mal intentionné, il a été proposé des méthodes de sécurisation avancée. 20 En particulier, les méthodes dites d'authentification forte reposent sur la combinaison de deux facteurs d'identification, en général l'un étant ce que l'utilisateur connaît (un code, une phrase secrète, etc.) et l'autre ce que l'utilisateur détient (une carte à puce, une clé physique, un appareil, etc.) ou ce qu'il est (biométrie, etc.). Par exemple il est courant lors d'une 25 transaction sur internet de demander un identifiant bancaire et un code reçu par SMS (ce que l'utilisateur détient : un téléphone portable). Ainsi, voler une carte bancaire n'est plus suffisant pour en faire une utilisation frauduleuse. Dans le cadre d'une entreprise, l'authentification forte utilise 30 massivement le concept du mot de passe à usage unique, ou OTP (« OneTime Password ») reposant le plus souvent sur l'utilisation d'un petit terminal personnel, appelé « security token », qui est capable de générer des OTPs. Le collaborateur qui souhaite se connecter à son compte doit, outre son couple login/mot de passe, saisir l'OTP qui s'affiche sur le token pour se connecter. Ainsi, un tiers qui aurait intercepté le couple login/mot de passe d'un collaborateur ne pourrait pas se connecter à moins d'avoir physiquement dérobé le token. Alternativement au token, l'OTP peut être généré grâce à une carte à puce spéciale, par une application fonctionnant sur un smartphone, ou envoyé par SMS. Chacune de ces technologies apporte satisfaction, mais la plupart 10 des systèmes à authentification forte présentent la contrainte rigide qu'est la détention d'un objet spécifique (en particulier token ou smartphone). Et cet objet peut être perdu ou déchargé. De plus, les changements d'usages actuels induisent la modification des périphériques propres à l'utilisateur (smartphone, tablette tactile, PC 15 portable, etc.). Il est nécessaire de permettre à un utilisateur de s'authentifier depuis n'importe lequel de ses périphériques, soit directement au travers du périphérique (site WebNPN), soit en se servant du périphérique pour accéder à un autre environnement (OTP généré sur le téléphone pour ouvrir le VPN sur le PC). 20 Il serait ainsi souhaitable de disposer d'une solution évoluée de gestion des authentifications via OTP prenant en compte ces nouveaux usages et de permettant de gérer une pluralité de périphériques pour un utilisateur tout en renforçant la sécurité de l'authentification primaire. 25 Résumé de l'invention Selon un premier aspect, l'invention concerne un procédé de configuration d'un périphérique de type terminal connecté à un réseau afin de permettre une authentification forte d'un utilisateur grâce à un serveur 30 via ledit périphérique, ledit serveur étant également connecté au réseau, caractérisé en ce qu'il comprend les étapes suivantes : - Connexion sécurisée d'un poste client au serveur ; - Sur une interface utilisateur du poste client, saisie d'informations d'identification du périphérique ; - Génération par le serveur d'une clé sécrète d'authentification associée au périphérique permettant la génération algorithmique de mots de passe à usage unique (OTP) ; - Génération par le serveur et affichage sur ladite interface utilisateur du poste client d'un code d'activation ; - Chargement sur ledit périphérique d'une application via le réseau, et saisie par l'utilisateur du code d'activation dans l'application ; - Vérification par le périphérique du code d'activation auprès du serveur, et chargement d'au moins ladite clé sécrète d'authentification via le réseau, de sorte à permettre la génération par le périphérique desdits mots de passe à usage unique (OTP). Selon d'autres caractéristiques avantageuses et non limitatives du procédé selon le premier aspect : - le procédé comprend également suite à la vérification du code d'activation par le périphérique le chargement d'un compteur d'OTPs, ledit compteur d'OTPs étant incrémenté à chaque nouvelle génération d'un mot de passe à usage unique (OTP) par le périphérique, la clé sécrète d'authentification associée au périphérique étant révoquée si le compteur d'OTPs atteint un seuil donné ; - le procédé comprend également suite à la vérification du code d'activation par le périphérique le chargement de paramètres de gestion d'un code d'identification personnel (PIN), le procédé comprenant ensuite la définition par l'utilisateur d'un code d'identification personnel (PIN) conforme auxdits paramètres, la saisie dudit code d'identification personnel (PIN) défini étant demandée à l'utilisateur pour authentification à chaque nouvelle génération d'un mot de passe à usage unique (OTP) par le périphérique. Selon un deuxième aspect, l'invention concerne un procédé de configuration d'un périphérique de type terminal connecté à un réseau afin de permettre une authentification forte d'un utilisateur à un serveur via ledit périphérique, ledit serveur étant également connecté au réseau, caractérisé en ce qu'il comprend les étapes suivantes : - Connexion sécurisée d'un poste client au serveur ; - Sur une interface utilisateur du poste client, saisie d'informations d'identification du périphérique et définition d'un code d'identification personnel (PIN) ; - Génération par le serveur d'une clé sécrète d'authentification associée au périphérique permettant la génération algorithmique de mots de passe à usage unique (OTP) ; - Stockage de ladite clé sécrète d'authentification sur des moyens de stockage du serveur, de sorte à permettre la génération et l'envoi par le serveur desdits mots de passe à usage unique (OTP) dans un message via le réseau en cas d'envoi du code d'identification personnel (PIN) au serveur depuis le périphérique. Selon d'autres caractéristiques avantageuses et non limitatives du procédé selon le premier aspect ou le deuxième aspect : - Le procédé comprend la génération par le serveur d'un compteur 20 d'erreurs associé au terminal, ledit compteur d'erreur étant incrémenté à chaque tentative d'authentification erronée via le périphérique, l'utilisateur étant bloqué si le compteur d'erreurs atteint un seuil donné ; - la génération du mot de passe à usage unique (OTP) est une réponse à un challenge transmis par le serveur et affiché par le périphérique ; 25 - le procédé comprend également la configuration d'un périphérique de type dispositif portable autonome ou carte à puce, afin de permettre une authentification forte d'un utilisateur grâce à un serveur via ledit périphérique, le périphérique étant directement connecté au serveur via une liaison sécurisée, ladite configuration comprenant les étapes suivantes : 30 - Connexion sécurisée d'un poste client au serveur ; - Sur une interface utilisateur du poste client, saisie d'informations d'identification du périphérique ; - Génération par le serveur d'une clé sécrète d'authentification associée au périphérique permettant la génération algorithmique de mots de passe à usage unique (OTP), et chargement de ladite clé secrète sur le périphérique ; - Le procédé est mis en oeuvre plusieurs fois de sorte à configurer une pluralité de périphériques afin de permettre une authentification forte d'un utilisateur grâce à un serveur via chacun desdits périphérique ; - Le procédé comprend également suite à la vérification du code d'activation par le périphérique le chargement de paramètres de taille de mot de passe à usage unique (OTP), le serveur définissant cette taille de mot de passe à usage unique (OTP) en fonction du nombre de périphériques configurés pour l'utilisateur. Brève description des dessins D'autres caractéristiques, buts et avantages de la présente invention apparaîtront mieux à la lecture de la description qui va suivre d'un mode de réalisation préférentiel. Cette description sera donnée en référence aux dessins annexés, sur lesquels : - la figure 1 est un schéma d'une architecture pour la mise en oeuvre des procédés selon l'invention; - les figures 2 à 6 sont des vues d'interfaces utilisées dans certains modes de réalisation de l'invention. Description détaillée de formes de réalisation préférées Architecture En référence à la figure 1, les présents procédés sont des procédés de configuration d'un périphérique 1 a, lb de type terminal afin de permettre une authentification forte d'un utilisateur. Le périphérique 1 a, lb est un terminal (en particulier un terminal mobile), c'est-à-dire un équipement connecté à un réseau 10 (en particulier le réseau internet) disposant de ses propres moyens de traitement de données, de stockage de données, et d'une interface. Il est adapté pour se connecter au réseau 10 via une liaison filaire (Ethernet) ou sans-fil (par exemple via un réseau de communication mobile). Il s'agit typiquement d'un smartphone, d'une tablette tactile, ou de tout autre appareil personnel de l'utilisateur. Par « configuration », on entend la préparation sécurisée du périphérique 1 a, lb de sorte à ce que ce dernier puisse être utilisé ultérieurement à des fins d'authentification forte de son utilisateur. Il s'agit en d'autres termes d'une initialisation. La telle configuration d'un périphérique 1a, lb est appelée « l'enrôlement » du périphérique 1a, lb. Un périphérique la, lb enrôlé est apte à servir dans une authentification forte Par authentification forte on entend une certification (à deux niveaux : un niveau via login/mot de passe, et un niveau via la possession du périphérique 1 a, 1 b) de l'identité d'un utilisateur du périphérique 1 a, lb tentant de se connecter à un serveur sécurisé 4 (ce dernier est par exemple le serveur de données d'une entreprise, un serveur de messagerie électronique, etc.). Par serveur 4, on désignera tout système d'information d'une entreprise pour lequel l'accès doit être contrôlé. L'équipement via lequel l'utilisateur peut être un poste de travail 2 20 (par exemple un PC) ou le périphérique lui-même (cas du terminal 1b sur la figure 1). Les deux cas seront décrits par la suite. Un serveur d'authentification 3 est également présent et connecté au réseau 10. On comprendra que le serveur 4 peut être confondu avec ce dernier. Il s'agit typiquement d'un serveur Radius en « back-end ». Le 25 serveur 3 est l'équipement qui valide ou non l'authentification d'un équipement 2, lb et par conséquent son autorisation ou non d'accès au serveur 4 et ses contenus. Ce serveur 3 peut également gérer avec d'autres préférences réseau (VPN, pare-feu, etc.). 30 Multi-périphériques La présente invention propose des procédés permettant à un utilisateur de s'authentifier d'une pluralité de façon grâce à l'un ou l'autre de ses périphériques la, lb, et ce d'une façon très flexible sans que la sécurité ne soit affectée. Plus précisément, les présents procédés permettent facilement « l'enrôlement » d'un ou plusieurs périphériques, y compris de façon temporaire, via un mécanisme centralisé autour du serveur 3, ainsi que le cas échéant la révocation de ces enrôlements. Ce mécanisme d'enrôlement peut être fait automatiquement et en masse, ce qui est pratique dans une cas d'un grande entreprise qui peut avoir de nombreux collaborateurs équipés d'un téléphone mobile personnel. En effet, dans l'art antérieur, un périphérique pouvait être utilisé pour une authentification forte, mais de façon figée (par exemple un smartphone devait être configuré en boutique). Cas 1 - Application sur terminal Dans ce premier mode de réalisation, le procédé de configuration du périphérique 1 a, lb (qui est ici de façon préférée de type smartphone, amis qui peut être également un PC par exemple) afin de permettre une authentification forte d'un utilisateur grâce au serveur 3 via ledit périphérique 1 a, lb commence par une étape de connexion sécurisée d'un poste client 2 au serveur 3. Cette étape est indispensable pour garantir que l'utilisateur qui tente de réaliser un enrôlement (et donc qui tente de modifier des droits d'accès) est bien un utilisateur autorisé. Le poste client 2 est par exemple un ordinateur physiquement présent dans le réseau local de l'entreprise. Ce poste 2 peut également servir d'interface pour contrôler le serveur 3 et les périphériques (voir plus loin). Dans le présent procédé, sur une interface utilisateur du poste client 30 2, des informations d'identification du périphérique 1 a, lb sont alors saisies. La figure 2 représente une interface qui peut être utilisée. Les informations permettant d'identifier le périphérique 1 a, lb peuvent être de nombreuses formes et consistent pas exemple en un numéro de téléphone, un code IMEI, une adresse MAC, etc. De façon préférée, le serveur 3 peut stocker une base de données de périphériques 1 a, 1 b, chacun étant associé à un nom où un identifiant unique permettant de le sélectionner facilement (acas de la figure 2). Le serveur 3 génère alors (par exemple grâce à un certificat) une clé sécrète d'authentification associée au périphérique 1a, 1 b permettant la génération algorithmique de mots de passe à usage unique OTP. Par clé secrète, on entend des données secrètes sur lesquelles peuvent reposer l'obtention d'OTP (par exemple un algorithme, des codes, voire directement une liste d'OTPs précalculés). Par « associée au périphérique », on entend qu'elle est spécifique de ce dernier et unique. Le serveur 3 génère également et affiche sur ladite interface utilisateur du poste client 2 d'un code d'activation. Dans l'exemple de la 15 figure 2, ce code est XA5T QCH7 6K2U. De façon parallèle, l'utilisateur charge (c'est-à-dire télécharge et installe) sur ledit périphérique 1a, 1 b une application dédiée (via le réseau 10), et saisit le code d'activation dans l'application (ainsi que d'autres données permettant par exemple de sélectionner le serveur 3). L'obtention 20 de l'application peut être libre (via un store), ou déclenchée spécifiquement grâce aux données permettant l'identification du périphérique 1 a, 1 b, pour plus de sécurité. Il est à noter que l'application peut avoir déjà été téléchargée et utilisée (par exemple en cas de ré-enrôlement, voir plus loin), et dans ce cas les données qui pourrait y être présentes (une ancienne clé 25 secrète, etc.) sont effacées. Ensuite, le périphérique 1a, 1 b vérifie le code d'activation auprès du serveur 3 (ce dernier reçoit le code saisi, et compare avec le code attendu pour ce périphérique 1 a, lb). La vérification comprend également la comparaison de données du périphérique 1 a, lb avec les informations 30 permettant d'identifier le périphérique 1 a, lb: en d'autres termes, le serveur 3 doit recevoir le bon code d'activation de la part du bon périphérique 1 a, lb, pour éviter toute possibilité d'usurpation. La figure 3 montre un exemple d'interface de l'application. En cas de vérification positive, le serveur 3 autorise le transfert sur une mémoire du périphérique la, lb (via l'application) de données sensible 5 pour l'authentification : - au moins la clé secrète, mais le cas échéant également ; - un compteur d'OTPs; - des paramètres de gestion d'un code d'identification personnel (PIN), et voire encore, 10 - l'identifiant unique du périphérique 1 a, lb dans le serveur 3, - la taille de l'OTP (on reparlera de ce paramètre plus loin). La présence de la clé sécrète d'authentification permet la génération par le périphérique 1 a, lb desdits mots de passe à usage unique OTP, et 15 donc son utilisation en authentification forte. Si un compteur d'OTPs est également chargé, ce dernier est incrémenté à chaque nouvelle génération d'un mot de passe à usage unique OTP par le périphérique 1 a, 1 b, la clé sécrète d'authentification associée au périphérique 1 a, lb étant révoquée si le compteur d'OTPs 20 atteint un seuil donné. Le périphérique 1 a, lb peut alors être ré-enrôlé et recevoir une nouvelle clé secrète et un (compteur d'OTPs remis à zéro). Le ré-enrôlement comprend l'ensemble des étapes décrites préalablement à l'exception du chargement de l'application. Si des paramètres de gestion d'un code d'identification personnel 25 (PIN), en d'autres termes une « politique de PIN », sont chargées, le procédé comprend ensuite la définition par l'utilisateur d'un code PIN conforme auxdits paramètres, la saisie dudit code d'identification personnel PIN défini étant demandée à l'utilisateur pour authentification à chaque nouvelle génération d'un mot de passe à usage unique OTP par le 30 périphérique 1 a, 1b, pour plus de sécurité. A ce stade, l'utilisateur peut utiliser son périphérique 1 a, lb pour authentification forte. Dès lors qu'il appuie sur « générer » (sous réserve qu'il ait par exemple saisi son PIN), un OTP lui est affiché (voir figure 4). Cet OTP lui permet en complément de son couple login/mot de passe de s'authentifier directement sur le périphérique (cas du terminal lb), par exemple via un copier-coller (avantageusement un bouton dans l'interface permet de faire le « copier »), soit sur un autre équipement (par exemple le poste client 2 si c'est un ordinateur portable en déplacement) via une saisie de l'OTP (cas du terminal la). Le présent procédé est ici très avantageux en ce qu'il permet facilement de transformer n'importe quel terminal mobile en périphérique d'authentification rapidement, efficacement, et avec une sécurité totale. Il est d'ailleurs à noter que ce mode de réalisation présente l'avantage de ne pas nécessiter de connexion du périphérique 1 a, lb au 15 serveur 3 pour générer des OTPs. On peut ainsi faire ceci dans un environnement où un terminal mobile ne capterait pas. Cas 2- e-mail/SMS 20 Dans ce deuxième mode de réalisation, on se passe de la nécessité d'une application, en utilisant un e-mail ou un SMS (ou d'autres moyens de messagerie). Un vieux téléphone ou un PC tiers peut alors servir de périphérique 1 a, 1 b. Un tel mode de réalisation est parfaitement adapté à un enrôlement temporaire, ou pour un accès de secours, mais nécessite 25 une connexion du périphérique 1 a, lb au réseau 10 lors de l'authentification, comme on le verra. Il peut être prévu qu'un utilisateur ne soit autorisé à enrôler qu'un seul périphérique en mode e-mail/SMS. Il est à noter que les deux modes de réalisation ne sont en rien exclusifs : un utilisateur peut enrôler plusieurs périphériques avec des 30 mécanismes différents, le présent procédé permet une telle souplesse. Le procédé commence alors comme dans le premier mode de réalisation : une connexion sécurisée d'un poste client 2 au serveur 3 est établie, et sur une interface utilisateur du poste client 2, l'utilisateur saisit des informations d'identification du périphérique I a, I b. De plus, il définit un code d'identification personnel PIN. Similairement à ce qui a été décrit avant, le serveur 3 génère une clé 5 sécrète d'authentification associée au périphérique 1a, 1 b permettant la génération algorithmique de mots de passe à usage unique OTP. Mais cette fois, la clé secrète n'est pas transférée via le réseau 10, mais conservée sur des moyens de stockage du serveur 3, de sorte à permettre la génération et l'envoi par le serveur 3 desdits mots de passe à 10 usage unique OTP dans un message via le réseau 10 en cas d'envoi du code d'identification personnel PIN au serveur 3 depuis le périphérique I a, I b. Plus précisément, l'utilisateur qui veut s'authentifier envoie au serveur 3 un message depuis le périphérique 1a, 1 b, message comportant 15 le PIN. Le serveur 3 extrait du message des données identifiant le périphérique (par exemple le numéro de téléphone si c'est un SMS) et le code PIN et le compare avec celui attendu. Comme dans le précédent mode de réalisation, le serveur 3 doit recevoir le bon code PIN de la part du bon périphérique la, lb, pour éviter toute possibilité d'usurpation. 20 Si c'est le cas le serveur 3 génère lui-même l'OTP et le transfère par retour de message. L'utilisateur peut alors s'authentifier. Cas 3- Périphérique de type carte, clé USB, etc. 25 Comme expliqué, le présent procédé permet l'enrôlement de plusieurs périphériques I a, lb de type terminal. Mais de surcroit, il permet également l'enrôlement de périphériques « traditionnels » 1 c tels que des cartes à puce (par exemple des CPS, carte de professionnel de santé), des dispositifs portables autonomes (dispositifs ayant l'aspect d'une calculette 30 avec une interface de sortie pouvant afficher un OTP), des token USB, etc. Il peut être également prévu qu'un utilisateur ne soit autorisé à enrôler qu'un seul périphérique de ce type. Cet enrôlement d'un périphérique 1 c « en dur » est plus conventionnel. Il doit être directement connecté au serveur 3 via une liaison sécurisée. Comme dans les deux cas précédents, une connexion sécurisée 5 d'un poste client 2 au serveur 3 est établie, et sur une interface utilisateur du poste client 2, l'utilisateur saisit des informations d'identification du périphérique 1 c (par exemple un numéro de la carte CPS). Le serveur 3 génère une clé sécrète d'authentification associée au périphérique 1a, 1 b (qui est souvent une liste précalculée d'OTPs) permettant la génération 10 algorithmique de mots de passe à usage unique OTP, et la charge sur le périphérique lc. De façon générale, on retiendra que le procédé peut être mis en oeuvre plusieurs fois de sorte à configurer une pluralité de périphériques la, 1 b, 1 c (le cas échéant de type différents) afin de permettre une 15 authentification forte d'un utilisateur grâce à un serveur 3 via chacun desdits périphériques la, 1 b, lc. Mécanismes complémentaires 20 Selon un mode de réalisation préféré, l'enrôlement d'un périphérique 1 a, lb peut comprendre la génération par le serveur 3 d'un compteur d'erreurs associé au terminal 1 a, 1 b, ledit compteur d'erreur étant incrémenté à chaque tentative d'authentification erronée via le périphérique 1 a, 1 b, l'utilisateur étant bloqué si le compteur d'erreurs atteint un seuil 25 donné. Cela permet d'empêcher qu'un tiers « tente » d'utiliser frauduleusement un périphérique la, lb volé. Selon un autre mode de réalisation préféré, l'authentification utilise un mécanisme challenge/response. Dans ce cas particulier, l'OTP n'est pas un code indépendant mais la réponse à une question. Plus précisément, 30 l'utilisateur ne peut pas seulement appuyer sur un bouton générer pour obtenir l'OTP, mais doit saisir un challenge qui lui est fourni par le serveur 3 (via le poste de travail sur lequel il tente de s'authentifier). 3026 8 75 13 Le mode challenge/response peut être sélectionné lors de l'enrôlement d'un périphérique. La clé secrète générée est alors un algorithme capable de générer une réponse en fonction d'un challenge. Comme l'on voit sur la figure 5, l'interface de l'application est alors 5 légèrement changée (dans l'exemple représenté sur les figures 3 à 5, il y a deux onglets) et permet alors la saisie du challenge. De façon similaire à ce qui a été expliqué avant dès lors que la clé secrète est chargée sur le périphérique 1 a, lb et est manipulée via l'application, le mécanisme challenge/response peut être mis en oeuvre même en l'absence de 10 connexion du périphérique 1 a, lb au réseau 10. Selon encore un mode de réalisation préféré, la taille de l'OTP (paramètre optionnel fourni à l'application, voir avant) est fonction du nombre de périphériques la, lb, lc enrôlés pour l'utilisateur. En effet, quand on calcule le risque d'une attaque par force brute, il 15 faut aussi prendre en compte la marge, le nombre de périphériques et le nombre de tentatives (i.e. le seuil de l'éventuel compteur d'erreur). Or, un OTP de 8 caractères (hexa) représente une entropie de 24*8 = 232, un OTP de 12 caractères (hexa) représente une entropie de 24*12 = 248, et un OTP de 16 caractères (hexa) représente une entropie de 24'16 = 264. 20 Et le secret utilisé dans la création de l'OTP a typiquement une entropie suffisante pour générer une clé de 112 bits. En supposant que l'algorithme utilisé (par exemple MD5) permet de répartir équitablement les résultats, dans les trois cas de longueur ci-dessus on est en dessous de la limite de la clé de 112 bits mais on voit bien que le 25 niveau de sécurité est bien supérieur pour un OTP de 16 caractères que pour un OTP de 8 caractères. Mais si l'OTP doit être entré à la main sur un périphérique différent de celui qui a généré l'OTP (ce qui implique une saisie manuelle, et non un copier-coller), celui de 8 caractères sera plus facile à utiliser. 30 Par exemple, pour un utilisateur ayant dix périphériques, une marge de vingt et cinq tentatives, une attaque en force brut avec un OTP à 8 caractères représente une chance sur 232 / (10 * 20 * 5) soit une chance sur plus de 4 millions mais une chance sur 264 / (10 * 20 * 5) soit une chance sur plus de 18 millions de milliards avec un OTP à 16 caractères. En fonction du nombre de terminaux (et des autres paramètres tels que le seuil d'erreurs), sera choisi la plus petite taille d'OTP permettant une protection telle que la probabilité de succès d'une attaque en force brute soit inférieure à un seuil donné (par exemple une chance sur 1 milliard). Gestion des périphériques De façon préférée, l'utilisateur (ou un administrateur) peut gérer le périphérique 1 a, 1 b, 1 c sur une interface utilisateur du poste client 2 connecté de façon sécurisée au serveur 3. La figure 6 montre un profil fictif d'utilisateur et les périphériques la, lb, lc qui lui sont associés. Dans l'exemple, l'utilisateur a enrôlé quatre périphériques la, lb, lc : - une carte sur laquelle il reste 189 OTPs précalculés ; - un premier périphérique à authentification par application, la taille de l'OTP associée est 16 caractères ; - un premier périphérique à authentification par application, la taille de l'OTP associée est 8 caractères ; - un périphérique à authentification par e-mail. Cette interface permet de lister les périphériques la, lb, lc et de les gérer : ils peuvent être facilement révoqués, ré-enrôlés, leurs préférences 25 modifiées, etc. La durée des enrôlements temporaires peut être gérée. Pour chaque périphérique peuvent être accessibles des données telles que les d'informations d'identification du périphérique associées, où des statistiques telles que la date de la dernière connexion réussie/échouée, l'état des compteurs d'OTPs/d'erreurs associés, le nom 30 du certificat etc. L'accès global du compte au serveur 3 peut être également contrôlé. REVENDICATIONS1. Procédé de configuration d'un périphérique (1a, 1 b) de type terminal connecté à un réseau (10) afin de permettre une authentification 5 forte d'un utilisateur grâce à un serveur (3) via ledit périphérique (1a, lb), ledit serveur (3) étant également connecté au réseau (10), caractérisé en ce qu'il comprend les étapes suivantes : - Connexion sécurisée d'un poste client (2) au serveur (3) ; - Sur une interface utilisateur du poste client (2), saisie d'informations 10 d'identification du périphérique (1a, 1 b) ; - Génération par le serveur (3) d'une clé sécrète d'authentification associée au périphérique (1a, 1 b) permettant la génération algorithmique de mots de passe à usage unique (OTP) ; - Génération par le serveur (3) et affichage sur ladite interface 15 utilisateur du poste client (2) d'un code d'activation ; - Chargement sur ledit périphérique (1a, 1 b) d'une application via le réseau (10), et saisie par l'utilisateur du code d'activation dans l'application ; - Vérification par le périphérique (1a, 1 b) du code d'activation auprès 20 du serveur (3), et chargement d'au moins ladite clé sécrète d'authentification via le réseau (10), de sorte à permettre la génération par le périphérique (1a, 1 b) desdits mots de passe à usage unique (OTP). 25 2. Procédé selon la revendication 1, comprenant également suite à la vérification du code d'activation par le périphérique (1a, 1 b) le chargement d'un compteur d'OTPs, ledit compteur d'OTPs étant incrémenté à chaque nouvelle génération d'un mot de passe à usage unique (OTP) par le périphérique (1a, lb), la clé sécrète d'authentification associée au 30 périphérique (1a, 1 b) étant révoquée si le compteur d'OTPs atteint un seuil donné. 3. Procédé selon l'une des revendications 1 et 2, comprenant également suite à la vérification du code d'activation par le périphérique (1a, 1 b) le chargement de paramètres de gestion d'un code d'identification personnel (PIN), le procédé comprenant ensuite la définition par l'utilisateur d'un code d'identification personnel (PIN) conforme auxdits paramètres, la saisie dudit code d'identification personnel (PIN) défini étant demandée à l'utilisateur pour authentification à chaque nouvelle génération d'un mot de passe à usage unique (OTP) par le périphérique (1a, lb). 4. Procédé de configuration d'un périphérique (1a, 1 b) de type terminal connecté à un réseau (10) afin de permettre une authentification forte d'un utilisateur à un serveur (3) via ledit périphérique, ledit serveur (3) étant également connecté au réseau (10), caractérisé en ce qu'il comprend les étapes suivantes : - Connexion sécurisée d'un poste client (2) au serveur (3) ; - Sur une interface utilisateur du poste client (2), saisie d'informations d'identification du périphérique (1a, 1 b) et définition d'un code d'identification personnel (PIN) ; - Génération par le serveur (3) d'une clé sécrète d'authentification associée au périphérique (1a, 1 b) permettant la génération algorithmique de mots de passe à usage unique (OTP) ; - Stockage de ladite clé sécrète d'authentification sur des moyens de stockage du serveur (3), de sorte à permettre la génération et l'envoi par le serveur (3) desdits mots de passe à usage unique (OTP) dans un message via le réseau (10) en cas d'envoi du code d'identification personnel (PIN) au serveur (3) depuis le périphérique (1a, lb). 5. Procédé selon l'une des revendications 1 à 4, comprenant la génération par le serveur (3) d'un compteur d'erreurs associé au terminal 30 (1a, lb), ledit compteur d'erreur étant incrémenté à chaque tentative d'authentification erronée via le périphérique (1a, lb), l'utilisateur étant bloqué si le compteur d'erreurs atteint un seuil donné. 6. Procédé selon l'une des revendications 1 à 5, dans lequel la génération du mot de passe à usage unique (OTP) est une réponse à un challenge transmis par le serveur (3) et affiché par le périphérique (1a, lb). 5 7. Procédé selon l'une des revendications 1 à 6, comprenant également la configuration d'un périphérique (1c) de type dispositif portable autonome ou carte à puce, afin de permettre une authentification forte d'un utilisateur grâce à un serveur (3) via ledit périphérique (1c), le périphérique 10 (1c) étant directement connecté au serveur (3) via une liaison sécurisée, ladite configuration comprenant les étapes suivantes : - Connexion sécurisée d'un poste client (2) au serveur (3) ; - Sur une interface utilisateur du poste client (2), saisie d'informations d'identification du périphérique (1c) ; 15 - Génération par le serveur (3) d'une clé sécrète d'authentification associée au périphérique (1c) permettant la génération algorithmique de mots de passe à usage unique (OTP), et chargement de ladite clé secrète sur le périphérique (1c). 20 8. Procédé selon l'une des revendications 1 à 7, mis en oeuvre plusieurs fois de sorte à configurer une pluralité de périphériques (1a, 1 b, 1c) afin de permettre une authentification forte d'un utilisateur grâce à un serveur (3) via chacun desdits périphérique (1a, lb). 25 9. Procédé selon la revendication 8, comprenant également suite à la vérification du code d'activation par le périphérique (1a, 1 b) le chargement de paramètres de taille de mot de passe à usage unique (OTP), le serveur (3) définissant cette taille de mot de passe à usage unique (OTP) en fonction du nombre de périphériques (1a, 1 b, 1c) configurés pour 30 l'utilisateur.