Brevet FR2956272A1 — publié le 20110812

Authentification par mot de passe à usage unique La présente invention concerne les techniques d'authentification par mot de passe à usage unique. Plus particulièrement, la présente invention concerne le renouvellement de paramètres utilisés pour la génération de tels mots de passe. Les systèmes à mot de passe à usage unique sont décrits dans le document RFC2289 « A One-Time Password System ». Dans les systèmes à mot de passe à usage unique (ou systèmes « OTP »), deux équipements ont chacun connaissance d'un ensemble de paramètres pour générer des mots de passe qui sont utilisés et transmis en clair pour l'authentification du premier équipement auprès du deuxième équipement. Le premier équipement est appelé « client », au sens où ce premier équipement requiert l'authentification, et le deuxième équipement est appelé « serveur » au sens où ce deuxième équipement est sollicité par le client pour répondre à la demande d' authentification. Les paramètres pour générer les mots de passe, comportent une « graine » (« seed » dans le document RFC2289) qui est une chaîne de caractères ISO-646, un numéro de séquence par exemple compris entre 100 et 200, un mot de passe initial (ou «passphrase »), et un algorithme de génération de mots de passe (par exemple MD-5, SHA-1, ou autre). En référence à la figure 1, on décrit une authentification par mot de passe à usage unique selon le document RFC2289. Un équipement client 10 souhaitant s'authentifier auprès d'un équipement serveur 11 de type OTP commence par s'identifier au moyen d'une commande de type « login » 12. S'il reconnaît le login fourni, le serveur répond avec un message 13 comportant la « graine » précitée, et le numéro de séquence N communs aux équipements. Le message peut par ailleurs comporter une indication de l'algorithme à utiliser pour générer un mot de passe (ou « OTP »). Le client génère ensuite lors de l'étape 14 un OTP de rang N (le nombre N étant le numéro de séquence fourni par le serveur). A cet effet, le client concatène la graine et le mot de passe initial (« passphrase ») préalablement enregistré auprès du client. Le client calcule ensuite un condensé de la chaîne ainsi produite selon un algorithme tel que MD-5 ou SHA-1 par exemple. Cette opération, appelée « fonction de hachage sécurisée », est appliquée N fois. Le résultat final est l'OTP de rang N. Le client transmet l'OTP ainsi calculé au serveur dans un message 15. Le serveur qui connait le dernier OTP calculé et utilisé par le client dans une authentification précédente (c'est-à-dire le mot de passe obtenu en appliquant N+l fois la fonction de hachage sur la concaténation de la passphrase et de la graine), applique lors de l'étape 16 la fonction de hachage sécurisée une seule fois à l'OTP transmis par le client. On obtient ainsi le mot de passe de rang N+l (obtenu par application N+1 fois de la fonction de hachage). Si la valeur ainsi obtenue est égale au dernier bon OTP mémorisé, alors le client est authentifié car l'OTP qu'il a fourni montre qu'il possède le bon mot de passe initial. Le serveur mémorise le nouveau dernier bon OTP utilisé (c'est-à-dire celui obtenu par application N fois de la fonction de hachage) puis décrémente la valeur du numéro de séquence, ce qui produira, lors de l'authentification suivante, un OTP différent. De la sorte, le mot de passe initial n'est jamais transmis sur le réseau, et un même mot de passe OTP n'est jamais utilisé deux fois. Le serveur renvoie alors un message 17 de confirmation de l'authentification. Lorsque le numéro de séquence arrive à zéro suite aux décrémentations successives par le serveur, à la fois le client et le serveur ont besoin d'être réinitialisés. Le document RFC2289 prévoit que cette opération soit réalisée par un utilisateur (typiquement un administrateur du système). En effet, cette étape est très sensible puisqu'elle implique que le client et le serveur prennent connaissance des paramètres secrets pour la génération des mots de passe, en particulier le mot de passe initial. Le besoin de cette étape de réinitialisation limite donc l'utilisation des systèmes OTP à des applications où l'intervention humaine est possible. La présente invention vise notamment à offrir un système OTP permettant d'envisager une réinitialisation de machine à machine, sans intervention humaine. A cet effet, selon un premier aspect de l'invention, on propose un procédé de renouvellement de paramètres dans une authentification par mot de passe à usage unique, d'un premier équipement auprès d'un deuxième équipement, dans laquelle des mots de passe sont générés par application itérative d'un algorithme de génération de mot de passe sur un ensemble de paramètres, le deuxième équipement mettant en oeuvre les étapes suivantes de: - réception d'une requête du premier équipement pour un renouvellement de l'ensemble de paramètres ; - génération d'un nouvel ensemble de paramètres pour générer des mots de passe ; - transmission cryptée du nouvel ensemble de paramètres vers le premier équipement ; - réinitialisation du deuxième équipement avec le nouvel ensemble de paramètres générés. Ainsi, la réinitialisation des équipements est entièrement automatisée et ne nécessite pas d'intervention humaine. Contrairement à l'art antérieur où les équipements passent dans un état bloqué (numéro de séquence à zéro), l'équipement client (le premier équipement en l'occurrence) requiert une réinitialisation. Cette dernière est opérée par le serveur (le deuxième équipement en l'occurrence) qui peut générer des nouveaux paramètres de manière aléatoire et les communiquer de manière cryptée vers le client, en utilisant une clé de chiffrement commune. Par exemple, la graine utilisée pour la génération des mots de passe est utilisée comme clé de chiffrement. Dans ce cas, on veille à ce que le deuxième équipement garde la graine secrète et ne la transmette pas durant les différentes authentifications (contrairement à ce qui est proposé par le document RFC2289). Afin de générer un nouveau mot de passe initial (ou passphrase), le deuxième équipement peut utiliser l'un au moins des éléments suivants : - un ensemble de caractères aléatoires, - une adresse MAC du deuxième équipement, - un dernier mot de passe utilisé avant la réception de la requête, et - un horodatage courant auprès du deuxième équipement. Cela permet de rendre plus complexe le mot de passe initial selon des éléments particuliers et/ou en liaison avec le premier équipement. Ainsi, le mot de passe initial est rendu plus robuste à des attaques de piratage. Dans des modes de réalisation, pour la transmission du nouvel ensemble, le deuxième équipement émet vers le premier équipement une trame de données comportant : - un champ identifiant une réponse à la requête, - un champ comportant une adresse MAC du premier équipement, - un champ comportant un mot de passe à usage unique, et - un champ comportant le nouvel ensemble de paramètres crypté. Dans des modes de réalisation, après la transmission du nouvel ensemble, le deuxième équipement se met en attente d'un message de confirmation de réception de l'ensemble de paramètres par le premier équipement, et dans le cas où la réception n'est pas confirmée, le deuxième équipement bloque toute authentification du premier équipement jusqu'à être réinitialisé. Ainsi, on s'assure que l'équipement ayant reçu les nouveaux paramètres est bien le premier équipement puisqu'il a pu décrypter correctement les paramètres. Par exemple, les authentifications sont bloquées jusqu'à réinitialisation par un serveur d'authentification, ou par un administrateur. Ainsi, on peut éviter de continuer les authentifications alors qu'un piratage éventuel ou une erreur ont pu survenir. Selon un deuxième aspect de l'invention, on propose un procédé de renouvellement de paramètres dans une authentification par mot de passe à usage unique, d'un premier équipement auprès d'un deuxième équipement, dans laquelle des mots de passe sont générés par application itérative d'un algorithme de génération de mot de passe sur un ensemble de paramètres, le premier équipement mettant en oeuvre les étapes suivantes de: - transmission d'une requête vers le deuxième équipement pour un renouvellement de l'ensemble de paramètres ; - réception et décryptage du nouvel ensemble de paramètres crypté provenant du deuxième équipement ; et - réinitialisation du premier équipement avec le nouvel ensemble de paramètres décrypté. Par exemple, l'ensemble de paramètres comporte une graine gardée secrète par le premier équipement, et le premier équipement décrypte le nouvel ensemble en utilisant cette graine comme clé de chiffrement. Dans des modes de réalisation, après la réception du nouvel ensemble, le premier équipement transmet un message de confirmation de réception de l'ensemble de paramètres. Par exemple, l'ensemble de paramètres comporte un paramètre de comptage représentant un nombre d'itérations de l'algorithme de génération de mot de passe à mettre en oeuvre pour générer un mot de passe, ledit paramètre étant mis à jour à chaque génération de mot de passe, et dans lequel la requête est transmise lorsque le paramètre de comptage indique que le nombre d'itérations à mettre en oeuvre est en dessous d'un seuil. Selon d'autres aspects de l'invention, il est prévu : - des programmes d'ordinateur comportant des instructions pour la mise en oeuvre d'un procédé selon le premier aspect et/ou le deuxième aspect de l'invention lorsque le programme est exécuté par un processeur; - des supports lisibles par un ordinateur sur lequel sont enregistrés de tels programmes d'ordinateur ; - des equipements configurés pour la mise en oeuvre de procédés selon le premier aspect et/ou le deuxième aspect de l'invention ; et - un système comportant des équipements pour la mise en oeuvre d'un procédé selon le premier aspect et le deuxième aspect de l'invention. Un tel système met en oeuvre une authentification par mot de passe à usage unique, d'un premier équipement auprès d'un deuxième équipement, dans laquelle des mots de passe sont générés par application itérative d'un algorithme de génération de mot de passe sur un ensemble de paramètres, et dans lequel l'ensemble de paramètres est renouvelé auprès du deuxième équipement, le premier équipement étant configuré pour transmettre une requête vers le deuxième équipement pour un renouvellement de l'ensemble de paramètres, et pour recevoir le nouvel ensemble de paramètres crypté provenant du deuxième équipement, et le deuxième équipement étant configuré pour recevoir la requête du premier équipement pour un renouvellement de l'ensemble de paramètres, pour générer le nouvel ensemble de paramètres pour générer des mots de passe, et pour transmettre de manière cryptée le nouvel ensemble de paramètres vers le premier équipement. Par exemple, le premier équipement comporte: - une unité de communication pour envoyer et recevoir des messages pour mettre en oeuvre une authentification par mot de passe à usage unique, et - une unité de traitement pour solliciter une authentification par mot de passe à usage unique auprès d'un autre équipement, ladite unité étant configurée pour générer des mots de passe par application itérative d'un algorithme de génération de mot de passe sur un ensemble de paramètres, pour transmettre via l'unité de communication une requête vers l'autre équipement pour un renouvellement de l'ensemble de paramètres, et pour recevoir de manière cryptée via l'unité de communication le nouvel ensemble de paramètres transmis par l'autre équipement. Par exemple, le deuxième équipement comporte : - une unité de communication pour envoyer et recevoir des messages pour mettre en oeuvre une authentification par mot de passe à usage unique, et - une unité de traitement pour authentifier un autre équipement sollicitant une authentification par mot de passe à usage unique, ladite unité étant configurée pour générer des mots de passe par application itérative d'un algorithme de génération de mot de passe sur un ensemble de paramètres, pour renouveler ledit ensemble de paramètres sur réception par l'unité de communication d'une requête de l'autre équipement pour un renouvellement de l'ensemble de paramètres, et pour transmettre de manière cryptée via l'unité de communication le nouvel ensemble de paramètres vers l'autre équipement. Les avantages procurés par le procédé selon le deuxième aspect, les programmes d'ordinateur, les supports lisibles par ordinateur, les équipements, et le système, tels que succinctement exposés ci-dessus, sont au moins identiques à ceux mentionnés plus haut en liaison avec le procédés selon le premier aspect. D'autres caractéristiques et avantages de l'invention apparaîtront encore à la lecture de la description qui va suivre. Celle-ci est purement illustrative et doit être lue en regard des dessins annexés sur lesquels, en outre la figure 1 : - la figure 2 illustre l'initialisation de deux équipements selon un mode de réalisation de l'invention ; - les figures 3a et 3b illustrent des messages échangés lors de l'initialisation; - la figure 4 illustre l'authentification selon un mode de réalisation de l'invention ; - les figures 5a et 5b illustrent des messages échangés lors de l'authentification ; - la figure 6 illustre la réinitialisation des équipements selon un mode de réalisation de l'invention ; - les figures 7a, 7b, et 7c illustrent des messages échangés lors de la réinitialisation ; et - la figure 8 illustre schématiquement un système et des équipements selon un mode de réalisation de l'invention. En référence à la figure 2, on décrit l'initialisation de deux équipements 20 et 21 pour la mise en oeuvre d'un procédé d'authentification selon un mode de réalisation de l'invention. Lors de la toute première initialisation (ou lors d'une réinitialisation suite au blocage des authentifications suite à une erreur ou une tentative de piratage), l'équipement 20 et l'équipement 21 se connectent à un serveur d'authentification 22. Le serveur d' authentification génère alors lors de l'étape 23 un ensemble initial de paramètres comportant une «passphrase », ou mot de passe initial (10 à 63 caractères tirés aléatoirement), une « graine » (1 à 16 caractères alphanumériques ISO-646), un numéro de séquence (un nombre entier tiré aléatoirement entre 100 et 200), et un algorithme de génération de mots de passe (MD-5 ou SHA-1 par exemple). Dans la suite on considère que l'équipement 20 agira en tant que client dans sa relation avec l'équipement 21 qui agira donc en tant que serveur. Le premier équipement est appelé client, au sens où c'est l'équipement requérant l'authentification, et le deuxième équipement est appelé serveur dans le sens où il est sollicité par le client pour répondre à la demande d'authentification. Le serveur d'authentification transmet ensuite un message 24 vers l'équipement 20, selon un paquet de données tel que représenté sur la figure 3a. Le paquet comporte : - un champ 30 d'un octet identifiant le type de paquet transmis. Dans le présent cas, il s'agit d'un message d' initialisation qui peut être identifié par la chaîne « AUTH_INIT », - un champ 31 de 6 octets identifiant l'adresse MAC de l'équipement 20 qui par la suite communiquera avec l'équipement 21, ce champ vise à éviter toute ambigüité en cas de présence de plusieurs équipements clients, - un champ 32 de 64 octets comportant la passphrase générée, - un champ 33 d'un octet comportant une identification de l'algorithme de génération de mots de passe à utiliser, - un champ 34 de 16 octets comportant la graine générée, et - un champ 35 de 2 octets comportant le numéro de séquence généré. Le serveur d'authentification envoie également un message 25 identique au message 24 à l'équipement 21. Alternativement, le serveur d'authentification calcule un premier mot de passe à usage unique (OTP) en appliquant un nombre de fois égal au numéro de séquence l'algorithme de génération de mot de passe sur la concaténation de la passphrase et de la graine, selon la technique décrite dans le document RFC2289, puis il transmet un message 25 vers l'équipement 21. Ce message est similaire au message 24 mais à la place de comporter un champ pour la passphrase, il comporte un champ de 8 octets pour le premier OTP calculé. Ainsi, on garde la passphrase secrète même pour le serveur. Sur réception des messages 24 et 25, les équipements stockent dans des étapes 26 et 27 les paramètres reçus et passent dans l'état initialisé. Ils renvoient alors des messages 28 et 29 vers le serveur d'authentification pour confirmer l'initialisation, selon un paquet de données représenté sur la figure 3b comportant : - un champ 36 d'un octet identifiant le type de paquet transmis. Dans le présent cas, il s'agit d'un message de confirmation qui peut être identifié par la chaîne « AUTH_INIT_ACK », - un champ 37 de 6 octets identifiant l'adresse MAC de l'équipement 20, - un champ 38 d'un octet comportant la réponse à la réception des paramètres, ce champ peut être « ACK » ou « 1 » pour confirmer que l'initialisation s'est déroulée correctement, ou « NACK » ou « 0 » pour informer que l'initialisation n'a pas pu avoir lieu, et - un champ 39 d'un octet pour fournir des informations complémentaires, par exemple en cas de non- confirmation. Une fois les messages 28 et 29 envoyés, et l'initialisation confirmée, les équipements 20 et 21 se déconnectent du serveur 22. Ce processus de première initialisation est sensible, dans la mesure où des paramètres permettant de générer les OTP sont transmis vers le client et le serveur. Afin de garantir la confidentialité des échanges lors de ce processus, on peut envisager de réaliser les communications dans un flux Https. On peut prévoir d'autres modes de communication confidentielle alternatifs connus de la personne du métier. En référence à la figure 4, on décrit une authentification par mot de passe à usage unique selon un mode de réalisation de l'invention. On suppose que l'équipement client 40 et l'équipement serveur 41 ont été initialisés selon un processus tel que décrit ci-avant. Les deux équipements sont donc dans l'état initialisé, et chacun possède les paramètres nécessaires pour générer les mots de passe à partir du mot de passe initial, et le serveur connait le mot de passe généré par application N fois de l'algorithme de génération de mots de passe sur la concaténation passphrase/graine (N étant le numéro de séquence fourni lors de l'initialisation). Lors de l'étape 42, le client applique N fois l'algorithme sur la concaténation de la passphrase et de la graine. Il obtient ainsi le premier OTP. Il envoie alors un message de connexion 43 vers le serveur avec comme arguments l'adresse MAC du client et le premier OTP généré. Le message peut être envoyé selon le paquet de données représenté par la figure 5a comportant : - un champ 51 d'un octet identifiant le type de paquet transmis. Dans le présent cas, il s'agit d'un message d'authentification qui peut être identifié par la chaîne « AUTH_DATA », - un champ 52 de 6 octets identifiant l'adresse MAC de l'équipement 40, et - un champ 53 de 8 octets comportant l'OTP. L' OTP va permettre au serveur d'authentifier le client en vérifiant que l'OTP fourni correspond à l'OTP qui lui a été transmis lors de l'initialisation. Lors de l'étape 44, le serveur compare l'OTP reçu du client avec soit l'OTP reçu lors de l'initialisation s'il s'agit de la première fois que le client transmet un OTP ou soit avec le résultat de l'application (une seule fois) de l'algorithme sur le dernier OTP reçu sinon. Si l'OTP est reconnu, le serveur décrémente le numéro de séquence et stocke l'OTP reçu. Le serveur renvoie alors un message 45 de réponse pour confirmer ou non l'authentification. Ce message peut être transmis selon le paquet de données représenté par la figure 5b comportant : - un champ 54 d'un octet identifiant le type de paquet transmis. Dans le présent cas, il s'agit d'un message de confirmation qui peut être identifié par la chaîne « AUTH_DATA_ACK », - un champ 55 de 6 octets identifiant l'adresse MAC de l'équipement 40, - un champ 56 de 8 octets comportant l'OTP précédemment transmis par l'équipement 40, - un champ 57 d'un octet comportant la réponse à la réception de la requête 43, ce champ peut être « ACK » ou « 1 » pour confirmer l'authentification, ou «NACK » ou « 0 » pour informer que l'équipement 40 n'a pas été authentifié, et - un champ 58 d'un octet pour transmettre d'autres informations précisant les raisons de l'échec d'authentification par exemple. Si l'équipement 40 est authentifié, après réception du message 45, le client décrémente le numéro de séquence reçu lors de l'initialisation, et les communications entre l'équipement 40 et l'équipement 41 peuvent continuer, par exemple conformément au document RFC2289, jusqu'à ce que le numéro de séquence tombe en-dessous d'un certain seuil suite aux décrémentations successives. L'équipement 40 garde trace des messages 43 envoyés de façon à les apparier avec les messages 45 reçus en comparant les champs 53 et 56 contenant l'OTP. Si, au contraire, l'authentification a échoué, le champ 57 vaut « NACK » ou « 0 » et le champ 58 indique la raison éventuellement identifiée. L' authentification peut échouer pour différents raisons, 30 notamment : - si l'équipement 41 n'est pas initialisé, - si l'adresse MAC est inconnue, ou - si l'OTP est incorrect. Selon ces différents cas, les équipements pourront notifier l'échec à une entité de gestion distante ou passer dans un état non-initialisé qui bloque les authentifications du client auprès du serveur. A chaque nouvelle authentification, les équipements calculent l'OTP suivant et décrémentent le numéro de séquence, comme décrit dans le document RFC2289. On peut toutefois noter ici, que contrairement au document RFC2289, la graine n' est jamais échangée entre les équipements. Elle reste donc secrète. Comme on le verra par la suite, cette graine pourra être utilisée pour la réinitialisation des équipements. En référence à la figure 6, on décrit la réinitialisation de deux équipements 600 et 601 lorsque le numéro de séquence tombe en dessous d'un seuil prédéterminé suite aux différentes décrémentations opérées par les équipements. Par exemple, le seuil correspond à un nombre d'OTP encore nécessaires pour les échanges de messages lors de la phase de réinitialisation. On peut aussi prévoir un seuil légèrement supérieur pour s'assurer qu'il reste assez d'OTP à générer pour l'échange de messages lors de la réinitialisation. Lors de l'étape 602, l'équipement client compare le numéro de séquence courant à un seuil. Par exemple 2. Lorsque le numéro de séquence atteint le nombre 2 suite aux différentes décrémentations, cela signifie que seuls deux OTP peuvent encore être générés. Si le seuil est atteint, le client envoie une requête de renouvellement 603 au serveur. Cette requête peut par exemple être transmise selon le paquet représenté sur la figure 7a comportant : - un champ 701 d'un octet identifiant le type de paquet transmis. Dans le présent cas, il s'agit d'un message de demande de nouveaux paramètres qui peut être identifié par la chaîne « AUTH_RENEW_REQ », - un champ 702 de 6 octets identifiant l'adresse MAC de l'équipement 600, et - un champ 703 de 8 octets comportant un OTP. Sur réception du message 603, le serveur vérifie l'OTP lors de l'étape 604 conformément au document RFC2289 puis génère lors de l'étape 605 un ensemble de nouveaux paramètres pour la génération de mots de passe à usage unique. Le serveur génère notamment: - une nouvelle passphrase, - une nouvelle graine, et - un nouveau numéro de séquence. Par exemple, pour générer la passphrase, le serveur utilise le dernier OTP enregistré, l'horodatage courant ou d'autres informations. Le serveur crypte ensuite les paramètres lors de l'étape 606 selon des techniques connues par exemple en utilisant les algorithmes AES256 ou 3DES. Par exemple, le serveur utilise la graine précédemment utilisée pour générer les OTP comme clé de chiffrement. En effet, comme déjà indiqué ci-avant, la graine peut rester secrète au cours des authentifications. La graine n'a été transmise que lors de la phase d'initialisation vers le client et le serveur. Ainsi, les deux équipements partagent cette information. Cette information est donc secrète et évolue au cours des différentes réinitialisations des équipements. Elle offre donc des avantages à être utilisée comme clé de chiffrement. Le serveur transmet ensuite au client les paramètres cryptés dans un message 607 selon le paquet illustré par la figure 7b comportant : - un champ 704 d'un octet identifiant le type de paquet transmis. Dans le présent cas, il s'agit d'un message de transmission de paramètres qui peut être identifié par la chaîne « AUTH_RENEW_RESP », - un champ 705 de 6 octets identifiant l'adresse MAC de l'équipement 600, - un champ 706 de 8 octets comportant l' OTP précédemment transmis par l'équipement 600, et - un champ 707 d'autant d'octets que nécessaire pour comporter les paramètres cryptés. Sur réception du message 607, le client décrypte les paramètres lors de l'étape 608. On peut prévoir que le client n'accepte de traiter le message 607 que s'il a précédemment envoyé une requête de demande de nouveaux paramètres. Afin de décrypter les nouveaux paramètres le client utilise la clé commune, par exemple la dernière graine utilisée pour générer les OTP. Le client enregistre ensuite les nouveaux paramètres et répond un message 609 pour confirmer la réception des paramètres. Le message 609 comporte par exemple les champs suivant du paquet représenté sur la figure 7c : - un champ 708 d'un octet identifiant le type de paquet transmis. Dans le présent cas, il s'agit d'un message de confirmation qui peut être identifié par la chaîne « AUTH_RENEW_ACK », - un champ 709 de 6 octets identifiant l'adresse MAC de l'équipement 600, -un champ 710 de 8 octets comportant le dernier OTP généré à partir des anciens paramètres, - un champ 711 d'un octet comportant la réponse à la réception des nouveaux paramètres, ce champ peut être « ACK » ou « 1 » pour confirmer la réception, ou « NACK » ou « 0 » pour informer que les paramètres n'ont pas été reçus ou décryptés, et - un champ 712 d'un octet pour transmettre d'autres informations précisant les raisons de l'échec de réception ou de décryptage par exemple. Des programmes d'ordinateur comportant des instructions pour la mise en oeuvre des procédés selon l'invention peuvent être réalisés selon un algorithme général déduit de l'organigramme général de la figure 6, et de la présente description détaillée. Par exemple, un programme d'authentification par mot de passe à usage unique côté client peut-être réalisé selon le pseudo-code suivant : RENEW_AUTHQ SI (SEQ = 2) ALORS RENEW_PARAM ; FIN; SI (RECEP_NEW_PARAM = VRAI) ALORS DECRYPT(PARAM, GRAINE) -* NEW_PARAM; STOCK(NEW_PARAM); SI (ERREUR) ALORS NACK_RECEP; FAUX -* RECEP_NEW_PARAM ; FAUX -* ERREUR ; SINON ACK_RECEP; NEW_PARAM -*PARAM_COURANT ; FAUX -* RECEP_NEW_PARAM ; 20 FIN La fonction RENEW_AUTH() consiste à veiller au renouvellement des paramètres nécessaire à la génération des mots de passe. A cet effet, lorsque le paramètre SEQ correspondant au numéro de séquence devient égal à 2, la fonction RENEW_PARAM est appelée. Cette fonction assure l'envoi d'un message de requête de renouvellement de paramètres comme décrit ci-avant. Lorsque les nouveaux 25 paramètres PARAM sont reçus, une variable booléenne RECEP_NEW_PARAM passe à VRAI, et lorsque cette variable a la valeur VRAI, la fonction DECRYPTA est appelée pour décrypter les paramètres reçus. La fonction DECRYPTA prend en arguments les paramètres cryptés, et la clé de chiffrement, par exemple la graine GRAINE des paramètres courant. Les paramètres décryptés sont alors stockés dans la variable NEW_PARAM. Cette variable est ensuite enregistrée en mémoire par la fonction 30 STOCKA. En effet, les nouveaux paramètres ne seront utilisés qu'à partir du moment où la réception aura été confirmée. Dans le processus de décryptage, si une erreur survient, la variable booléenne ERREUR passe à VRAI et la fonction NACK_ERREUR est appelée pour transmettre un message d'échec comme 10 15 FIN ; FIN ; décrit ci-avant, et la variable ERREUR est alors remise à FAUX. Sinon la variable ERREUR reste à FAUX, et la fonction ACK_RECEP est appelée pour transmettre un message de confirmation comme décrit ci-avant. En outre, les paramètres reçus et décryptés remplacent alors les paramètres courants et sont dorénavant utilisés pour s'authentifier auprès du serveur. La variable RECEP_NEW_PARAM est repassée à FAUX. Par exemple encore, un programme d'authentification par mot de passe à usage unique côté serveur peut-être réalisé selon le pseudo-code suivant : GEN_AUTHQ SI(RENEW_PARAM) ALORS GEN_PARAM (OTP_COURANT, HORDATA ; MAC_CLNT) -*PARAM ; CRYPTO(PARAM, GRAINE)-*NEW_PARAM ; TRANS(NEW_PARAM, MAC_CLNT) ; FIN; FIN; La fonction GEN_AUTHQ génère et transmet des nouveaux paramètres de génération de mots de passe sur requête du client. Lorsqu'une requête est reçue, la variable booléenne RENEW_PARAM passe à VRAI et la fonction GEN_PARAMQ est alors appelée. Cette fonction prend en arguments, l'OTP courant, les informations d'horodatage courantes, et l'adresse MAC du client pour générer les nouveaux paramètres comme déjà décrit ci-avant. Ces nouveaux paramètres sont stockés dans la variable PARAM. La fonction CRYPTOQ est ensuite appelée pour crypter les paramètres générés en utilisant par exemple la graine des paramètres courant comme clé de chiffrement. Les paramètres cryptés sont ensuite transmis vers le client en utilisant la fonction TRANS() qui prend en argument les paramètres cryptés et l'adresse MAC du client. Lorsque le client enverra la confirmation de la réception des paramètres, le serveur stockera les paramètres générés à la place des paramètres courants. La figure 8 illustre schématiquement un système d'authentification selon un mode de réalisation de l'invention. Le système comporte un équipement 80 appelé client et un équipement 84 appelé serveur. L'équipement 80 comporte une unité de traitement 81 pour s'authentifier auprès de l'équipement 84 selon un procédé selon la présente invention. A cet effet il dispose d'une unité de mémoire 82. Cette unité de mémoire peut comporter différents types de mémoire. Par exemple l'unité de mémoire comporte une mémoire pour stocker des données de calcul. L'unité de mémoire peut également comporter une mémoire pour le stockage d'un programme d'ordinateur selon la présente invention pour son exécution par un processeur de l'unité de traitement. L'équipement comporte en outre une unité de communication 83 pour communiquer notamment avec l'équipement 84 ou un serveur d'authentification par exemple via un réseau de communication (non représenté). L'équipement 84 comporte une unité de traitement 85 pour authentifier l'équipement 80 selon un procédé selon la présente invention. A cet effet il dispose d'une unité de mémoire 86. Cette unité de mémoire peut comporter différents types de mémoire. Par exemple l'unité de mémoire comporte une mémoire pour stocker des données de calcul. L'unité de mémoire peut également comporter une mémoire pour le stockage d'un programme d'ordinateur selon la présente invention pour son exécution par un processeur de l'unité de traitement. L'équipement comporte en outre une unité de communication 87 pour communiquer notamment avec l'équipement 80 ou un serveur d'authentification par exemple via un réseau de communication (non représenté). La présente invention a été décrite et illustrée dans la présente description détaillée et dans les figures. La présente invention ne se limite pas aux formes de réalisation présentées. D'autres variantes et modes de réalisation peuvent être déduits et mis en oeuvre par la personne du métier à la lecture de la présente description et des figures annexées. Dans les revendications, le terme "comporter" n'exclut pas d'autres éléments ou d'autres étapes. L' article indéfini « un » n' exclut pas le pluriel. Un seul processeur ou plusieurs autres unités peuvent être utilisées pour mettre en oeuvre l'invention. Les différentes caractéristiques présentées et/ou revendiquées peuvent être avantageusement combinées. Leur présence dans la description ou dans des revendications dépendantes différentes, n'excluent pas cette possibilité. Les signes de référence ne sauraient être compris comme limitant la portée de l'invention. REVENDICATIONS1. Procédé de renouvellement de paramètres de génération de mots de passe dans une authentification par mot de passe à usage unique, d'un premier équipement auprès d'un deuxième équipement, dans laquelle des mots de passe sont générés par application itérative d'un algorithme de génération de mot de passe sur un ensemble de paramètres, le deuxième équipement mettant en oeuvre les étapes suivantes de: - réception d'une requête (603) du premier équipement pour un renouvellement de l'ensemble de paramètres ; - génération d'un nouvel ensemble de paramètres (604) pour générer des mots de passe ; - transmission cryptée (606, 607) du nouvel ensemble de paramètres vers le premier équipement ; et - réinitialisation du deuxième équipement (611) avec le nouvel ensemble de paramètres générés. 2. Procédé selon la revendication 1, dans lequel l'ensemble de paramètres comporte une graine gardée secrète par le deuxième équipement, et dans lequel le nouvel ensemble est transmis selon un cryptage utilisant ladite graine comme clé de chiffrement. 15 3. Procédé selon la revendication 1, dans lequel l'ensemble de paramètres comporte un mot de passe initial, et dans lequel la génération du nouvel ensemble comporte la génération d'un nouveau mot de passe initial à partir de l'un au moins des éléments suivants : - un ensemble de caractères aléatoires, - une adresse MAC du deuxième équipement, 20 - un dernier mot de passe utilisé avant la réception de la requête, et - un horodatage courant auprès du deuxième équipement. 4. Procédé selon la revendication 1, dans lequel, pour la transmission du nouvel ensemble, le deuxième équipement émet vers le premier équipement une trame de données comportant : 25 - un champ (704) identifiant une réponse à la requête, - un champ (705) comportant une adresse MAC du premier équipement, - un champ (706) comportant un mot de passe à usage unique, et - un champ (707) comportant le nouvel ensemble de paramètres crypté.10 5. Procédé selon la revendication 1, dans lequel, après la transmission du nouvel ensemble, le deuxième équipement se met en attente d'un message (609) de confirmation de réception de l'ensemble de paramètres par le premier équipement, et dans le cas où la réception n'est pas confirmée, le deuxième équipement bloque toute authentification du premier équipement jusqu'à être réinitialisé. 6. Procédé de renouvellement de paramètres de génération de mots de passe dans une authentification par mot de passe à usage unique, d'un premier équipement auprès d'un deuxième équipement, dans laquelle des mots de passe sont générés par application itérative d'un algorithme de génération de mot de passe sur un ensemble de paramètres, le premier équipement mettant en oeuvre les étapes suivantes de: 10 - transmission d'une requête (603) vers le deuxième équipement pour un renouvellement de l'ensemble de paramètres ; - réception et décryptage du nouvel ensemble de paramètres crypté provenant du deuxième équipement ; et - réinitialisation du premier équipement (611) avec le nouvel ensemble de paramètres décrypté. 7. Procédé selon la revendication 6, dans lequel l'ensemble de paramètres comporte une graine gardée secrète par le premier équipement, et dans lequel le premier équipement décrypte le nouvel ensemble en utilisant ladite graine comme clé de chiffrement. 20 8. Procédé selon la revendication 6, dans lequel, après la réception du nouvel ensemble, le premier équipement transmet un message de confirmation de réception de l'ensemble de paramètres. 9. Procédé selon la revendication 6, dans lequel l'ensemble de paramètres comporte un paramètre de comptage représentant un nombre d'itérations de l'algorithme de génération de mot de passe à mettre en 25 oeuvre pour générer un mot de passe, ledit paramètre étant mis à jour à chaque génération de mot de passe, et dans lequel la requête est transmise lorsque le paramètre de comptage indique que le nombre d'itérations à mettre en oeuvre est en dessous d'un seuil. 10. Programme d'ordinateur comportant des instructions pour la mise en oeuvre d'un procédé selon l'une 30 quelconque des revendications 1 à 5, lorsqu'il est exécuté par un processeur. 11. Programme d'ordinateur comportant des instructions pour la mise en oeuvre d'un procédé selon l'une quelconque des revendications 6 à 9, lorsqu'il est exécuté par un processeur. 15. Equipement comportant : - une unité de communication pour envoyer et recevoir des messages pour mettre en oeuvre une authentification par mot de passe à usage unique, et - une unité de traitement pour authentifier un autre équipement sollicitant une authentification par mot de passe à usage unique, ladite unité étant configurée pour générer des mots de passe par application itérative d'un algorithme de génération de mot de passe sur un ensemble de paramètres, pour renouveler ledit ensemble de paramètres sur réception par l'unité de communication d'une requête de l'autre équipement pour un renouvellement de l'ensemble de paramètres, et pour transmettre de manière cryptée via l'unité de communication le nouvel ensemble de paramètres vers l'autre équipement. 13. Equipement comportant : - une unité de communication pour envoyer et recevoir des messages pour mettre en oeuvre une authentification par mot de passe à usage unique, et - une unité de traitement pour solliciter une authentification par mot de passe à usage unique auprès d'un autre équipement, ladite unité étant configurée pour générer des mots de passe par application itérative d'un algorithme de génération de mot de passe sur un ensemble de paramètres, pour transmettre via l'unité de communication une requête vers l'autre équipement pour un renouvellement de l'ensemble de paramètres, et pour recevoir de manière cryptée via l'unité de communication le nouvel ensemble de paramètres transmis par l'autre équipement. 14. Système d'authentification par mot de passe à usage unique, d'un premier équipement auprès d'un deuxième équipement, dans lequel des mots de passe sont générés par application itérative d'un algorithme de génération de mot de passe sur un ensemble de paramètres, et dans lequel l'ensemble de paramètres est renouvelé auprès du deuxième équipement, le premier équipement étant configuré pour transmettre une requête vers le deuxième équipement pour un renouvellement de l'ensemble de paramètres, et pour recevoir le nouvel ensemble de paramètres crypté provenant du deuxième équipement, et le deuxième équipement étant configuré pour recevoir la requête du premier équipement pour un renouvellement de l'ensemble de paramètres, pour générer le nouvel ensemble de paramètres pour générer des mots de passe, et pour transmettre de manière cryptée le nouvel ensemble de paramètres vers le premier équipement. 16