WO2011098702A1 - Authentification par mot de passe a usage unique - Google Patents
Authentification par mot de passe a usage unique Download PDFInfo
- Publication number
- WO2011098702A1 WO2011098702A1 PCT/FR2011/050163 FR2011050163W WO2011098702A1 WO 2011098702 A1 WO2011098702 A1 WO 2011098702A1 FR 2011050163 W FR2011050163 W FR 2011050163W WO 2011098702 A1 WO2011098702 A1 WO 2011098702A1
- Authority
- WO
- WIPO (PCT)
- Prior art keywords
- parameters
- equipment
- password
- new
- request
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Ceased
Links
Classifications
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L63/00—Network architectures or network communication protocols for network security
- H04L63/08—Network architectures or network communication protocols for network security for authentication of entities
- H04L63/083—Network architectures or network communication protocols for network security for authentication of entities using passwords
- H04L63/0838—Network architectures or network communication protocols for network security for authentication of entities using passwords using one-time-passwords
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L63/00—Network architectures or network communication protocols for network security
- H04L63/04—Network architectures or network communication protocols for network security for providing a confidential data exchange among entities communicating through data packet networks
- H04L63/0428—Network architectures or network communication protocols for network security for providing a confidential data exchange among entities communicating through data packet networks wherein the data content is protected, e.g. by encrypting or encapsulating the payload
Definitions
- the second equipment may use at least one of the following:
- the first equipment after receiving the new set, transmits a confirmation message of receipt of the set of parameters.
- a communication unit for sending and receiving messages for implementing a one-time password authentication
- the second equipment includes:
- FIG. 4 illustrates authentication according to one embodiment of the invention
- FIGS. 7a, 7b and 7c illustrate messages exchanged during the reset; and - Figure 8 schematically illustrates a system and equipment according to one embodiment of the invention.
- FIG. 2 describes the initialization of two equipment 20 and 21 for the implementation of an authentication method according to one embodiment of the invention.
- this field is intended to avoid any ambiguity in the event of the presence of several customer equipments,
- This initialization process is sensitive, since parameters for generating the OTPs are transmitted to the client and the server. In order to guarantee the confidentiality of the exchanges during this process, it is possible to envisage carrying out the communications in an Https stream.
- the server then returns a response message 45 to confirm or not the authentication.
- This message can be transmitted according to the data packet represented by FIG. 5b comprising:
- the equipment will be able to notify the failure to a remote management entity or to go into an uninitialized state that blocks the authentications of the client to the server.
- the reinitialization of two devices 600 and 601 is described when the sequence number falls below a predetermined threshold following the various decrementations made by the equipment.
- the threshold corresponds to a number of OTPs still necessary for message exchanges during the reset phase.
- the server Upon receiving the message 603, the server checks ⁇ in step 604 according to KFC2289 and then generates in step 605 a set of new parameters for the generation of one-time passwords.
- the server generates, in particular:
- a field 708 of one byte identifying the type of packet transmitted is a confirmation message that can be identified by the string "AUTH_KEMEW_ACK”,
Landscapes
- Engineering & Computer Science (AREA)
- Computer Hardware Design (AREA)
- Computer Security & Cryptography (AREA)
- Computing Systems (AREA)
- General Engineering & Computer Science (AREA)
- Computer Networks & Wireless Communication (AREA)
- Signal Processing (AREA)
- Computer And Data Communications (AREA)
Abstract
On propose un 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 œuvre 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, et réinitialisation du deuxième équipement avec le nouvel ensemble de paramètres généré.
Description
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 Γ authentification du premier équipement auprès du deuxième équipement. Le premier équipement est appelé « client », au sens où ce premier équipement requiert Γ 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 ΓΟΤΡ de rang N. Le client transmet ΓΟΤΡ ainsi calculé au serveur dans un message 15.
Le serveur qui connaît 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+1 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 à ΓΟΤΡ transmis par le client. On obtient ainsi le mot de passe de rang N+1 (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 ΟΤΡ 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 œuvre 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 authentifîcation 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'authentifïcation, 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 authentifîcation 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 œuvre 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 ]e 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 œuvre 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 œuvre 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 œuvre 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 équipements configurés pour la mise en œuvre 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 œuvre d'un procédé selon le premier aspect et le deuxième aspect de l'invention.
Un tel système met en œuvre 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 œuvre une authentifîcation par mot de passe à usage unique, et
- une unité de traitement pour solliciter une authentifîcation 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 œuvre une authentifîcation par mot de passe à usage unique, et
- une unité de traitement pour authentifier un autre équipement sollicitant une authentifîcation 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 authentifîcation selon un mode de réalisation de l'invention ;
- les figures 5a et 5b illustrent des messages échangés lors de authentifîcation ;
- 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 œuvre 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 I'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 « AUTHJ-NIT »,
- 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 ambigiiité 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é. Us 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 connaît 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. H 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 va permettre au serveur d'authentifier le client en vérifiant que ΓΟΤΡ fourni correspond à ΓΟΤΡ qui lui a été transmis lors de l'initialisation.
Lors de l'étape 44, le serveur compare ΓΟΤΡ reçu du client avec soit ΓΟΤΡ 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 ΓΟΤΡ est reconnu, le serveur décrémente le numéro de séquence et stocke ΓΟΤΡ reçu.
Le serveur renvoie alors un message 45 de réponse pour confirmer ou non I'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 ΓΟΤΡ 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 I'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 FC2289, 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 F OTP.
Si, au contraire, I'authentification a échoué, le champ 57 vaut « NACK » ou « 0 » et le champ 58 indique la raison éventuellement identifiée. L'authentifîcation peut échouer pour différents raisons, notamment :
- si l'équipement 41 n'est pas initialisé,
- si l'adresse MAC est inconnue, ou
- si ΟΤΡ 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 ΓΟΤΡ 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 ΓΟΤΡ lors de l'étape 604 conformément au document KFC2289 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 aufhentifications. 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 ΓΟΤΡ précédemment transmis par Y é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_KEMEW_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 œuvre 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_AUTH()
SI (SEQ = 2) ALORS
RENEWJPARAM ;
FIN;
SI (RECEP_NEW_PARAM = VRAI) ALORS
DECRYPT(PARAM, GRAINE) -» EW_PARAM;
STOCK(NEW_PARAM);
SI (ERREUR) ALORS
NACKJRECEP;
FAUX -> RECEP_NEW_PARAM ;
FAUX -> ERREUR ;
SINON ACK_RECEP ;
NEW_PARAM ->PARAM_COURANT ;
FAUX -> RECEP_NEW_PARAM ;
FIN ;
FIN ;
FIN -
La fonction RENEW_AUTH0 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 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 DECRYPT0 est appelée pour décrypter les paramètres reçus. La fonction DECRYPT() 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 STOCK(). 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
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 AUTHO
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_AUTH() 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_PARAM() est alors appelée. Cette fonction prend en arguments, ΓΟΊΡ 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 CRYPTO() 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 enveaa 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. À 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 œuvre 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 œuvre 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.
Claims
1. Procédé de renouvellement de paramètres de génération de mots de passe dans une aut entification 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 œuvre 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.
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,
- 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 îa transmission du nouvel ensemble, le deuxième équipement émet vers le premier équipement une trame de données comportant :
- 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é.
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 œuvre les étapes suivantes de:
- 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.
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 œuvre 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 œuvre est en dessous d'un seuil.
10. Programme d'ordinateur comportant des instructions pour la mise en œuvre d'un procédé selon l'une quelconque des revendications 1 à 5, lorsqu'il est exécuté par un processeur.
11. Programme d'ordinateur comportant des instructions pour la mise en œuvre d'un procédé selon l'une quelconque des revendications 6 à 9, lorsqu'il est exécuté par un processeur.
12. Equipement comportant :
- une unité de communication pour envoyer et recevoir des messages pour mettre en œuvre une authentifîcation par mot de passe à usage unique, et
- une unité de traitement pour authentifier un autre équipement sollicitant une authentifîcation 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 œuvre une authentifîcation par mot dépasse à usage unique, et
- une unité de traitement pour solliciter une authentifîcation 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' authentifîcation 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.
Applications Claiming Priority (2)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| FR1050980 | 2010-02-11 | ||
| FR1050980A FR2956272A1 (fr) | 2010-02-11 | 2010-02-11 | Authentification par mot de passe a usage unique |
Publications (1)
| Publication Number | Publication Date |
|---|---|
| WO2011098702A1 true WO2011098702A1 (fr) | 2011-08-18 |
Family
ID=42288651
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| PCT/FR2011/050163 Ceased WO2011098702A1 (fr) | 2010-02-11 | 2011-01-27 | Authentification par mot de passe a usage unique |
Country Status (2)
| Country | Link |
|---|---|
| FR (1) | FR2956272A1 (fr) |
| WO (1) | WO2011098702A1 (fr) |
Families Citing this family (1)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US11792184B2 (en) * | 2019-12-05 | 2023-10-17 | Microsoft Technology Licensing, Llc | Autopilot re-enrollment of managed devices |
Citations (1)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| EP0774707A1 (fr) * | 1995-11-20 | 1997-05-21 | Bull S.A. | Procédé d'authentification d'un utilisateur travaillant dans un environnement distribué en mode client/serveur |
-
2010
- 2010-02-11 FR FR1050980A patent/FR2956272A1/fr not_active Withdrawn
-
2011
- 2011-01-27 WO PCT/FR2011/050163 patent/WO2011098702A1/fr not_active Ceased
Patent Citations (1)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| EP0774707A1 (fr) * | 1995-11-20 | 1997-05-21 | Bull S.A. | Procédé d'authentification d'un utilisateur travaillant dans un environnement distribué en mode client/serveur |
Non-Patent Citations (1)
| Title |
|---|
| HALLER BELLCORE C METZ KAMAN SCIENCES CORPORATION P NESSER NESSER & NESSER CONSULTING M STRAW BELLCORE N: "A One-Time Password System; rfc2289.txt", IETF STANDARD, INTERNET ENGINEERING TASK FORCE, IETF, CH, 1 February 1998 (1998-02-01), XP015008073, ISSN: 0000-0003 * |
Also Published As
| Publication number | Publication date |
|---|---|
| FR2956272A1 (fr) | 2011-08-12 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| EP2884716B1 (fr) | Mécanisme d'authentificaiton par jeton | |
| EP1427231B1 (fr) | Procédé d'établissement et de gestion d'un modèle de confiance entre une carte à puce et un terminal radio | |
| US20080162934A1 (en) | Secure transmission system | |
| CN109150897B (zh) | 一种端到端的通信加密方法及装置 | |
| CN105915342A (zh) | 一种应用程序通信处理系统、设备、装置及方法 | |
| FR3002400A1 (fr) | Generation d'une cle de session pour l'authentification et la transmission de donnees securisees | |
| CN104836784B (zh) | 一种信息处理方法、客户端和服务器 | |
| EP2153613A2 (fr) | Procede de securisation d'echange d'information, dispositif, et produit programme d'ordinateur correspondant | |
| WO2018211026A1 (fr) | Procede de securisation d'une communication sans gestion d'etats | |
| WO2016102833A1 (fr) | Entité électronique sécurisée, appareil électronique et procédé de vérification de l'intégrité de données mémorisées dans une telle entité électronique sécurisée | |
| FR3067829B1 (fr) | Procede d'authentification par defi-reponse d'un element securise (se) aupres d'un microcontroleur | |
| WO2017081208A1 (fr) | Procede de securisation et d'authentification d'une telecommunication | |
| EP3732849B1 (fr) | Procédé et système d'identification de terminal d'utilisateur pour la réception de contenus multimédia protégés et fournis en continu | |
| FR3111038A1 (fr) | Traitements cryptographiques pour chiffrer ou déchiffrer des données | |
| CN114006697A (zh) | 加密通信方法、装置 | |
| EP2710779A1 (fr) | Procede de securisation d'une platforme d'authentification, dispositifs materiels et logiciels correspondants | |
| WO2011098702A1 (fr) | Authentification par mot de passe a usage unique | |
| EP3777007A1 (fr) | Procédés, dispositifs et programmes d'ordinateur pour le chiffrement et le déchiffrement de données pour la transmission ou le stockage de données | |
| CN111431846B (zh) | 数据传输的方法、装置和系统 | |
| EP3266148B1 (fr) | Dispositif et procédé d'administration d'un serveur de séquestres numériques | |
| WO2021074527A1 (fr) | Procede de gestion d'une base de donnees de cles publiques, procede d'authentification de cles publiques, et dispositifs serveur et client mettant en oeuvre ces procedes | |
| EP4160987B1 (fr) | Procédé pour générer une signature électronique au moyen du protocole fido | |
| JP2013042330A (ja) | 一方向通信システム、方法及びプログラム | |
| CN117997630A (zh) | 一种文件的加密传输方法、装置、存储介质及电子设备 | |
| WO2024175864A1 (fr) | Procede et dispositif de stockage en ligne reparti de fichiers dans un contexte zero confiance |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| 121 | Ep: the epo has been informed by wipo that ep was designated in this application |
Ref document number: 11706878 Country of ref document: EP Kind code of ref document: A1 |
|
| NENP | Non-entry into the national phase |
Ref country code: DE |
|
| 122 | Ep: pct application non-entry in european phase |
Ref document number: 11706878 Country of ref document: EP Kind code of ref document: A1 |