EP1726121A1 - Procede d'authentification anonyme - Google Patents

Procede d'authentification anonyme

Info

Publication number
EP1726121A1
EP1726121A1 EP05736911A EP05736911A EP1726121A1 EP 1726121 A1 EP1726121 A1 EP 1726121A1 EP 05736911 A EP05736911 A EP 05736911A EP 05736911 A EP05736911 A EP 05736911A EP 1726121 A1 EP1726121 A1 EP 1726121A1
Authority
EP
European Patent Office
Prior art keywords
authentication
counter
entity
value
client entity
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.)
Withdrawn
Application number
EP05736911A
Other languages
German (de)
English (en)
Inventor
Olivier Charles
David Arditti
Sébastien NGUYEN NGOC
Thierry Baritaud
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Orange SA
Original Assignee
France Telecom SA
Priority date (The priority date 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 date listed.)
Filing date
Publication date
Application filed by France Telecom SA filed Critical France Telecom SA
Publication of EP1726121A1 publication Critical patent/EP1726121A1/fr
Withdrawn legal-status Critical Current

Links

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/32—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials
    • H04L9/3247—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials involving digital signatures
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/32—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials
    • H04L9/3271—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials using challenge-response
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L2209/00—Additional information or applications relating to cryptographic mechanisms or cryptographic arrangements for secret or secure communication H04L9/00
    • H04L2209/42—Anonymization, e.g. involving pseudonyms

Definitions

  • the present invention relates to a method of authentication by secret key of at least one user, for example in order to authorize or not this user to access resources when the anonymity of the user who s authenti ie, is required.
  • resources must be taken with very broad acceptance and generally designates any function, application, service, set of data to which a user can access and whose access is conditioned by prior authorization issued at the end of an authentication procedure.
  • it may be a service provided by a specialized server, a function for accessing a network, an IT resource such as a database or a software application available on a server. and can be shared by several users.
  • authentication is a security service carried out by an authentication entity, the objective of which is to validate the identity of a user who wishes to identify himself, thereby contributing even proof of the legitimacy of this user to access the resources concerned.
  • An authentication entity commonly designates any equipment, machine or computer system which makes it possible to centralize an authentication process and which is accessible by users wishing to authenticate themselves for access to resources, via a telecommunications network.
  • a user wishing to trigger an authentication process has a client entity allowing him to communicate with the entity authentication.
  • a client entity in the present description designates any electronic system or equipment making it possible to exchange data with the authentication entity, preferably without contact.
  • authentication by secret key is essentially characterized by the succession of following steps as shown in FIG. 1.
  • a client entity A when a client entity A wishes to authenticate itself with an authentication entity B , it first provides its identity to entity B, in the form of a static identifier which is specific to it, t then proves it by the use of a secret key K A known and shared by the entities A and B only.
  • the authentication entity B receives an authentication request sent by a client entity presenting itself to it as the holder of identity A, said authentication entity first generates a random number called a random number, or also called challenge, and sends this hazard to client entity A.
  • the client entity encrypts, we also say sign, the hazard received according to a predefined cryptographic algorithm with secret key, such as the DES algorithm ( English acronym for “Data Encryption Standard”).
  • the entity A then returns to the authentication entity B the value C (K A , random), where C is a cryptographic function.
  • Entity B performs the same calculation using the cryptographic function C and the secret key of AK A , and compares the result obtained with the value returned to it by entity A.
  • the authentication entity B validates the authentication, thereby signifying that A has succeeded in authenticating itself.
  • the validation of the authentication results for example, in the sending by the authentication entity to the client entity A which has been authenticated, of access rights to the resources.
  • Such secret key authentication methods are widely used in telecommunications networks, but nevertheless present a certain number of drawbacks with regard to guaranteeing the anonymity of the client entity wishing to authenticate. Indeed, to initialize the authentication process, a specific identifier of the client entity is necessarily transmitted in clear to the authentication entity. Thus, a malicious third party is able to know the specific identifier of the entity which authenticates by observing the transaction between the authentication entity and the authenticated entity.
  • the specific identifier of an entity wishing to authenticate can also be deduced by a malicious third party acting this time in an active way, that is to say by initiating an authentication process by posing as a authentication entity vis-à-vis the authenticating entity.
  • An authenticating entity can still be recognized by observing its behavior and, more particularly by observing the responses provided by the entity during previous authentication processes. Indeed, the answers provided by . an authenticating entity are characteristic of certain entries corresponding to the hazards which have been submitted to it by the authenticating entity and, for the same entry, the authenticating entity will always provide the same response. By observing beforehand the response of the entity to characteristic random values, it is possible to recognize an authenticating entity by resubmitting to it one of these random values for which a response from the entity has already been observed.
  • an entity that signs hazards to authenticate can be characterized by its response for a particular hazard valevr (for example, 0, 10, 100, 1000, etc.). By observing two successive identifications with the same hazard, it is therefore possible to deduce whether these are two distinct entities or the same entity which are authenticated.
  • the present invention aims to remedy these drawbacks by proposing an authentication method based on a secret key encryption algorithm, in which the anonymity of the authenticating entity is guaranteed, so that only one legitimate authentication entity can recognize the identity of the authenticating entity and no one else.
  • the subject of the invention is a method of authenticating at least one client entity with an authentication entity, said authentication entity comprising a set of secret keys, each being associated with a client entity. likely to be identified by said entity authentication, said method being characterized in that it comprises the following steps consisting in: a-transmitting an anonymous authentication request from the client entity to the authentication entity; b-send from the authentication entity to the client entity, an authentication counter value corresponding to the current state of a counter of the authentication entity; c-check, on the client entity side, that the counter value (of authentication received is strictly greater than a counter value stored by the client entity; d-calculate, on the client entity side, a counter signature by applying a cryptographic function shared by the client entity and the authentication entity, with as operands said authentication counter value and a secret key associated with the client entity; e-transmitting said counter signature to the entity authentication; f-update the counter value memorized by the client entity with said authentication counter value; g-search, at the authentication
  • the search step consists in: i-calculating, for each client entity likely to be identified, the corresponding counter signature by application of the cryptographic function with as operands the authentication counter value and the associated secret key, so as to establish a list of pairs of client entity capable of being identified / corresponding counter signature, for said counter value; j -check the consistency between the counter signature received and at least one counter signature from said list.
  • the list of pairs of client entity capable of being identified / corresponding counter signature established for a given authentication counter value is ordered, on the authentication entity side, according to the value of said counter signature.
  • steps b) to h) are repeated until a single pair is obtained for which the signature counter corresponds to the counter signature received.
  • the counter signature is calculated only for the client entities corresponding to said plurality of pairs determined in the previous iteration.
  • the method according to the invention consists in implementing step i) in advance with respect to an authentication request originating from a client entity in step a), said advance step i) consisting to be pre-established, on the authentication entity side, for at least one future authentication counter value, the list of pairs of client entity likely to be identified / corresponding counter signature for each of said authentication counter values to come, and memorize said pre-established lists on the authentication entity side, any sending of the authentication entity to the client entity of an authentication counter value, corresponding to the sending of a value of authentication counter for which a list of client entity pairs likely to be identified / corresponding counter signature has already been pre-established.
  • step h) consists in increasing the authentication counter by a fixed step.
  • step h.) Consists in increasing the authentication counter by a random step.
  • step b) in response to an authentication request, consists in sending, on the authentication entity side, in addition to the authentication counter value, a random value associated with said value of counter, said random value being different for each of the authentication counter values sent, each counter signing step implemented during said method being replaced by a step of signing the authentication counter value / value pair associated random, consisting of the application of the cryptographic function further comprising as operand said associated random value.
  • step c) also consists in verifying that the difference between the authentication counter value received and the counter value stored by the client entity is less than or equal to a predetermined value.
  • step c) when step c) is not verified, the following intermediate steps are implemented consisting of:
  • step h updating the value of the authentication counter corresponding to the current state of the counter of the authentication entity with the value of the temporary authentication counter and implementing step h).
  • step e) consists in further transmitting to the authentication entity the authentication counter value.
  • the authentication counter value is coded at least 128 bits.
  • the invention also relates to a smart card, characterized in that it comprises an integrated circuit and means for memorizing a secret key and for implementing the method according to the invention. Preferably, it is a contactless smart card.
  • the invention also relates to an authentication entity of at least one client entity, characterized in that it comprises a smart card reader provided with means for implementing the method according to the invention.
  • the authentication entity comprises a contactless smart card reader.
  • FIG. 1 is a diagram illustrating a secret key authentication process according to the state of the art, and has already been described;
  • FIG. 2 is a diagram illustrating the main steps of the authentication method according to the present invention.
  • FIG. 2 therefore describes the main steps of the method of authentication by secret key of a client entity A by an authentication entity B, according to the present invention.
  • the entity A wishing to authenticate has its own secret key K A , a means of memorizing a counter value CA, as well as a cryptographic signature function S, also shared by the authentication entity B, and which is intended to apply with the following two operands: a secret key and a counter value, so as to sign the counter value.
  • the authentication entity B comprises a list of pairs (Ai, K A i), Ai being the name of one of the n client entities capable of being authenticated by the authentication entity B and K A i being the secret key associated with the client entity Ai which is specific to it.
  • the authentication entity .. also includes a counter COMPTB delivering a counter value CB and the cryptographic function S, identical to that implemented in the client entity A.
  • the procedure for the anonymous authentication process is as follows.
  • the client entity A wants to authenticate with the authentication entity B, it signals itself to B by the transmission of an anonymous authentication request "RequestAuthentication”.
  • the authentication entity B sends to the client entity A the counter value CB corresponding to the current state of its counter COMPTB.
  • the client entity A compares the counter value CB received with the counter value CA memorized by client entity A.
  • two possibilities are available to client entity A:
  • the client entity A signs the counter value received CB by application of the cryptographic function S with as operands the secret key K A associated with the client entity A and the counter value CB.
  • the result of this counter signature operation S (K A , CB) is transmitted from the client entity A to the authentication entity B.
  • the client entity A then updates its counter value in a fifth step stored CA with the last lawful counter value transmitted to it by the authentication entity B, namely CB.
  • the authentication entity B searches for at least one client entity Ai from among the n client entities that it is capable of authenticating, for which the corresponding signature of the counter value CB S (K A ⁇ , CB) is consistent with the counter signature received from the client entity seeking to authenticate S (K A , CB).
  • the authentication entity B increases the counter value CB for a next authentication request.
  • the authentication entity B can systematically repeat the authentication process at least a second time in order to ensure that it recognizes the same client entity each time. The process can even be repeated N times, until a probability of falling at random N times on a signature value "corresponding to the same client entity sufficiently low.
  • Another optimization of the authentication process concerns the management of collision cases.
  • a collision case that is to say that several client entities Ai capable of being identified by the authentication entity B have been found for which the counter signature S (K A ⁇ , CB) is consistent with the received counter signature S (K A , CB).
  • the sixth step consisting of the search phase by the authentication entity of at least one client entity Ai among the n client entities that it is capable of authenticating, for which the corresponding signature of the value of counter CB S (K A ⁇ , CB) is consistent with the counter signature received from the client entity which seeks to authenticate S (K A , CB), can be implemented as follows.
  • the authentication entity B calculates, for each client entity Ai capable of being identified, the corresponding counter signature S (K A ⁇ , CB) by application of the function cryptographic S with as operands the authentication counter value CB and the associated secret key K A ⁇ , so as to establish a list of client entity pairs capable of being identified / corresponding counter signature (Ai, S (K A i , CB)), for the current counter value CB.
  • the phase of calculation by B, for each client entity Ai capable of being identified, of the corresponding counter signature S (K A i, CB), so as to establish the list of pairs of client entities likely to be identified / corresponding counter signature (Ai, S (K A ⁇ , CB)), for the current counter value CB can be very long and penalizing in terms of response time.
  • the authentication entity ication B will respond by sending an authentication count value CB for which the list (Ai, S ( A i, CB)) will already have been established.
  • any sending from B to A of an authentication counter value CB will correspond to an authentication counter value for which a list (Ai, S (K A ⁇ , CB) ) will already have been established.
  • the search for a couple in this ordered list for which the counter signature S (K A i, CB) corresponds to S (K A , CB) can then be made according to a dichotomous search.
  • the client entity sought is in this case found average after performing log 2 (n) operations, which saves a lot of time.
  • the CB counter Since the CB counter is unique for each authentication, it can be used as an authentication session identifier. Thus, if several entities Ai are being authenticated simultaneously by the entity B, the latter can distinguish the dialogs thanks to this value. It is sufficient for this that the client entities seeking to authenticate return the value CB in addition to the signature value S (KA, CB).
  • the counter COMPTB supplying the value of authentication counter CB increases by a fixed step.
  • the fact that the counter CB grows by a fixed step makes it possible to predict the values of authentication counter which will be used during the future authentications.
  • a hacker can request several values S (K A , CB) from an entity A for several values of counters CB and, subsequently, seek to authenticate himself with entity B by returning to him the values previously obtained from client entity A.
  • the hacker can authenticate himself by posing as A.
  • Two types of countermeasures against such an attack on the authentication system can be implemented.
  • a first display consists in increasing the counter COMPTB by a random step at each authentication, so as to no longer use successive values of CB.
  • the meter must have a greater capacity so as not to come into abutment.
  • Another parade consists in no longer having the client entity A sign seeking to authenticate a simple counter value CB, but a couple (CB, random), CB incrementing regularly and random taking random values.
  • the random value is intended to be different for each of the authentication counter values sent, and each counter signature step implemented during the authentication process in any of its variants is then replaced by a step. signature of the JCB pair, random), consisting in the application of the cryptographic function S with in addition as operand said associated random value.
  • the authentication method as just described is vulnerable to counter jump attacks, based on the fact that the entities A and B synchronize with the counter value CB at each authentication.
  • a malicious machine can impersonate the authentication entity B and send to the client entity A seeking to authenticate a counter value much greater than the effective authentication counter value CB, corresponding to the current value of the counter COMPTB of the entity B.
  • the entity A can no longer respond following an authentication request as long as the value counter CB of the authentication entity B will not have caught up with this value CA, because of the test of the third step.
  • the malicious machine provides entity A a maximum counter value, the latter, by updating its stored counter value CA to this maximum value, becomes permanently unusable thereafter.
  • the countermeasures to these attacks relate more particularly to the third step of the authentication process, where the client entity A compares the counter value CB received with the counter value CA stored by the client entity A.
  • the entity A signals to the entity B that its stored counter value CA is greater than the value CB and returns CA to it;
  • the other steps of the authentication process are implemented on the basis of this value of CB t e m o r ai r e, and if the authentication of the entity A succeeds with CB temp0r ai re , then l entity B updates its value of authentication counter CB corresponding to the current state of its counter COMPTB with the value of authentication counter CB tem p 0 rai r e. Finally, the counter is incremented for a next authentication.
  • This process allows the authentication entity to guard against a counter jump attack. Indeed, it will first authenticate the client entity A with CBtemp or aire, before updating its counter. This process also allows the client entity A to synchronize the counter of the authentication entity B with its stored counter value, if the latter had suffered a counter jump attack.
  • entity B can also implement additional protections. For example, B may allow only a certain number of these counter synchronizations per client entity and per period. Likewise, B can authorize these protections only within a reasonable limit where the difference between the value of counter memorized by the client entity CA and the value of authentication counter CB is less than a predetermined value.
  • the counter values CA and CB can be binary numbers coded on at least 128 bits, which makes it possible to execute 2,128 authentications before the system arrives at the completion of the counter COMPTB.
  • the steps of the method according to the invention on the client entity side are implemented on a smart card, preferably a contactless smart card.
  • a smart card for implementing the steps of the method according to the invention requires only little computational capacity since the operations to be executed are simple (at most the signature of a counter).
  • the authentication entity then takes the form of a smart card reader with or without contact.
  • only a legitimate authentication entity can recognize the identity of the client entity seeking to authenticate.
  • the identity of the client entity A seeking to authenticate itself is known only to the authentication entity B and is never revealed during the authentication.
  • the client entity A does not know under which name it is identified by the authentication entity.
  • the authenticating entity actually has no static identity that could be revealed.
  • a malicious third party is unable to distinguish entities. In view of two successive authentications, it is not possible to say whether these are two separate entities or the same entity that have authenticated. Anonymity is therefore complete.

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Security & Cryptography (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Storage Device Security (AREA)
  • Management, Administration, Business Operations System, And Electronic Commerce (AREA)

Abstract

L'invention concerne un procédé d'authentification d'une entité cliente (A) par une entité d'authentification (B) comprenant plusieurs clés secrètes (KAi) associée chacune à une entité cliente (Ai) à identifier, consistant à -envoyer une valeur de compteur d'authentification (CB) de l'entité d'authentification (B) vers l'entité cliente (A) suite à une demande d'authentification; -vérifier, côté entité cliente, que la valeur de compteur reçue est strictement supérieure à une valeur de compteur (CA) mémorisée par l'entité cliente; -calculer, côté entité cliente, une signature du compteur (S(KA, CB)) et la transmettre à l'entité d'authentification; -mettre à jour la valeur de compteur (CA) mémorisée par l'entité cliente avec ladite valeur de compteur d'authentification (CB); -rechercher, côté entité d'authentification (B), une entité cliente (Ai) à identifier pour laquelle la signature de compteur correspondante (S(KAi, CB)) est cohérente avec la signature de compteur reçue (S(KA, CB)); -faire croître le compteur d'authentification (COMPTB).

Description

PROCEDEDΑUTHENTD7ICATIONANTONYME
La présente invention se rapporte à un procédé d'authentification par clé secrète d'au moins un utilisateur, en vue par exemple d'autoriser ou non cet utilisateur à accéder à des ressou-rces lorsque l'anonymat de l'utilisateur qui s'authenti ie, est requis. Dans la présente description, le terme de ressources doit être pris avec une acceptation trrès large et désigne de manière générale toute fonction, application, service, ensemble de données à laquelle un utilisateur peut accéder et dont l'accès est conditionné par une autorisation préalable délivrée à l'issue d'une procédure d'authentification. A titre d'exemple non limitatif, il peut s'agir d'un service fomrni par un serveur spécialisé, une fonction d'accès à un réseau, une ressource informatique telle qu'urne base de données ou une application logicielle disponible sur un serveur et pouvant être partagée par plusieurs utilisateurs.
D'une manière générale, l 'authenti fication est un service de sécurité réalisé par une ent±té d'authentification, dont l'objectif est de val-Lder l'identité d'un utilisateur qui souhaite s'identifier, apportant par là même la preuve de la légitimité de cet utilisateur à accéder aux ressources concernées . Une entité d'authentification désigne communément tout équipement, machine ou système informatique qui permet de centraliser un processus d'authentification et qui est accessible par des utilisateurs souhaitant s'auth-entifier pour l'accès à des ressources, via un réseau de élécommunication. De façon usuelle, un utilisateur souhaitant déclencher un processus d'authentification dispose d'une entité cliente lui permettant de communiquer avec l'entité d'authentification. Une entité cliente dans la présente description, désigne tout système ou équipement électronique permettant d'échanger des données avec l'entité d'authentification, de préférence sans contact. Selon l'art antérieur, l'authentification par clé secrète se caractérise essentiellement par la succession d'étapes suivantes telles que représentées à la figure 1. Ainsi, lorsque une entité cliente A souhaite s'authentifier auprès d'une entité d'authentification B, elle fournit dans un premier temps son identité à l'entité B, sous la forme d'un identifiant statique qui lui est spécifique, t la prouve ensuite par l'utilisation d'une clé secrète KA connue et partagée par les entités A et B seulemen . Pour ce faire, lorsque l'entité d'authentification B reçoit une demande d'authentification émise par une entité cliente se présentant à elle comme détentrice de l'identité A, ladite entité d'authentification génère d'abord un nombre aléatoire appelé aléa, ou encore appelé challenge, et envoie cet aléa à l'entité cliente A. En retour, l'entité cliente chiffre, on dit encore signe, l'aléa reçu selon un algorithme cryptographique prédéfini à clé secrète, tel que l'algorithme DES (acronyme anglo- saxon pour « Data Encryption Standard ») . L'entité A renvoie alors à l'entité d'authentification B la valeur C(KA, aléa), où C est une fonction cryptographique. L'entité B effectue de son côté le même calcul en utilisant la fonction cryptographique C et la clé secrète de A KA, et compare le résultat obtenu avec la valeur que lui a retourné l'entité A. En cas de cohérence entre le résultat attendu et la valeur que lui a retournée A, l'entité d'authentification B valide 1 'authentification, signifiant ainsi que A a réussi à s'authentifier. La validation de 1 'authentification se traduit par exemple par l'envoi par l'entité d'authentification à destination de l'entité cliente A qui a été authentifié, des droits d'accès aux ressources.
De telles méthodes d'authentification à clé secrète sont largement répandues dans les réseaux de télécommunications, mais présentent toutefois un certain nombre d'inconvénients en ce qui concerne la garantie de l'anonymat de l'entité cliente souhaitant s'authentifier. En effet, pour initialiser le processus d'authentification, un identifiant spécifique de l'entité cliente est nécessairement transmis en clair à l'entité d'authentification. Ainsi, un tiers malveillant est à même de connaître l'identifiant spécifique de l'entité qui s'authentifie par l'observation de la transaction entre l'entité d'authentification et l'entité s ' authentifian .
De plus, l'identifiant spécifique d'une entité souhaitant s'authentifier peut également être déduite par un tiers malveillant agissant cette fois de façon active, c'est-à- dire en initialisant un processus d'authentification en se faisant passer pour une entité d'authentification vis- à-vis de l'entité s 'authentifiant.
Une entité s 'authentifiant peut encore être reconnue par l'observation de son comportement et, plus particulièrement par l'observation des réponses fournies par l'entité au cours de processus d'authentification antérieurs . En effet, les réponses fournies par . une entité s 'authentifiant sont caractéristiques de certaines entrées correspondant aux aléas qui lui ont été soumis par l'entité d'authentification et, pour une même entrée, l'entité s 'authentifiant fournira toujours la même réponse. En observant au préalable la réponse de l'entité à des valeurs caractéristiques d'aléa, il est possible de reconnaître une entité s 'authentifiant en lui soumettant à nouveau une de ces valeurs d'aléa pour laquelle une réponse de l'entité a déjà été observée. Ainsi, une entité qui signe des aléas pour s'authentifier peut être caractérisée par sa réponse pour une valevr d'aléa particulière (par exemple, 0, 10, 100, 1000, etc..) . En observant deux identifications successives avec le même aléa, il est donc possible de déduire si ce sont deux ent±tés distinctes ou la même entité qui se sont authentifiées .
La présente invention a pour but de remédier à ces inconvénients en proposant un procédé d'authentification basé sur un algorithme de chiffrement à clé secrète, dans lequel l'anonymat de l'entité s 'authentifiant est garanti, de sorte à ce que seule une entité d'authentification légitime puisse reconnaître l'identité de 1- ' entité qui s'authentifie et personne d'autre.
Avec cet objectif en vue, l'invention a pour objet un procédé d'authentification d'au moins une entité cliente par une entité d'authentification, ladite entité d'authentification comprenant un ensemble de clés secrètes, chacune étant associée à une entité cliente susceptible d'être identifiée par ladite entité d'authentification, ledit procédé étant caractérisé en ce qu'il comprend les étapes suivantes consistant à : a-transmettre une demande d'authentification anonyme de la part de l'entité cliente vers l'entité d'authentification ; b-envoyer de l'entité d'authentification vers l'entité cliente, une valeur de compteur d'authentification correspondant à l'état courant d'un compteur de l'entité d'authentification; c-vérifier, côté entité cliente, que la valeur de compteur (d'authentification reçue est strictement supérieure à une valeur de compteur mémorisée par l'entité cliente ; d-calculer, côté entité cliente, une signature de compteur par application d'une fonction cryptographique partagée par l'entité cliente et l'entité d'authentification, avec comme opérandes ladite valeur de compteur d'authentification et une clé secrète associée à l'entité cliente ; e-transmettre ladite signature de compteur à l'entité d'authentification ; f-mettre à jour la valeur de compteur mémorisée par l'entité cliente avec ladite valeur de compteur d'authentification; g-rechercher, côté entité d'authentification, au moins une entité cliente susceptible d'être identifiée, pour laquelle la signature de compteur correspondante pour ladite valeur de compteur d'authentification est cohérente avec la signature de compteur reçue ; h-faire croître le compteur d'authentification. De préférence, les étapes b) à h) sont réitérées au moins une fois, de sorte à s'assurer que l'entité cliente identifiée est identique à chaque itération.
Selon un mode de réalisation particulier, l'étape de recherche consiste à : i-calculer, pour chaque entité cliente susceptible d'être identifiée, la signature de compteur correspondante par application de la fonction cryptographique avec comme opérandes la valeur de compteur d'authentification et la clé secrète associée, de sorte à établir une liste de couples entité cliente susceptible d'être identifiée/signature de compteur correspondante, pour ladite valeur de compteur; j -vérifier la cohérence entre la signature de compteur reçue et au moins une signature de compteur de ladite liste.
De préférence, la liste des couples entité cliente susceptible d'être identifiée/signature de compteur correspondante établie pour une valeur de compteur d'authentification donnée, est ordonnée, côté entité d'authentification, selon la valeur de ladite signature de compteur.
Selon ce mode de réalisation, en cas de cohérence entre la signature de compteur reçue et la signature de compteur d'une pluralité de couples, les étapes b) à h) sont réitérées jusqu'à obtention d'un couple unique pour lequel la signature de compteur correspond à la signature de compteur reçue.
De préférence, lors de la répétition de l'étape i) , la signature de compteur est calculée uniquement pour les entités clientes correspondant à ladite pluralité de couples déterminée à l'itération précédente. Dans une variante, le procédé selon l'invention consiste à mettre en œuvre l'étape i) de manière anticipée par rapport à une demande d'authentification issue d'une entité cliente à l'étape a), ladite étape i) anticipée consistant à pré-établir, côté entité d'authentification, pour au moins une valeur de compteur d'authentification à venir, la liste des couples entité cliente susceptible d'être identifiée/signature de compteur correspondante pour chacune desdites valeurs de compteur d'authentification à venir, et à mémoriser lesdites listes pré-établies côté entité d'authentification, tout envoi de l'entité d'authentification vers l'entité cliente d'une valeur de compteur d'authentification, correspondant à l'envoi d'une valeur de compteur d'authentification pour laquelle une liste des couples entité cliente susceptible -d'être identifiée/signature de compteur correspondante a déjà été pré-établie . De préférence, l'étape h) consiste à faire croître le compteur d'authentification d'un pas fixe. Dans une variante, l'étape h.) consiste à faire croître le compteur d'authentification d'un pas aléatoire. Selon un mode de réalisation particulier, en réponse à une demande d'authentification, l'étape b) consiste à envoyer, côté entité d'authentification, en plus de la valeur de compteur d'authentification, une valeur aléatoire associée à ladite valeur de compteur, ladite valeur aléatoire étant différente pour chacune des valeurs de compteur d'authentification envoyée, chaque étape de signature de compteur mise en œuvre au cours dudit procédé étant remplacée par une étape de signature du couple valeur de compteur d' authentification/valeur aléatoire associée, consistant en l'application de la fonction cryptographique comprenant en plus comme opérande ladite valeur aléatoire associée.
Selon une variante, l'étape c) consiste en outre à vérifier que la différence entre la valeur de compteur d'authentification reçue et la valeur de compteur mémorisée par l'entité cliente est inférieure ou égale à une valeur prédéterminée .
Dans une variante, lorsque l'étape c) n'est pas vérifiée, les étapes intermédiaires suivantes sont mises en œuvre consistant à :
-envoyer de l'entité cliente v rs l'entité d'authentification, la valeur de compteur mémorisée par l'entité cliente ;
-envoyer de l'entité d'authentification vers l'entité cliente, une valeur de compteur d'authentification temporaire supérieure à ladite valeur de compteur mémorisée par l'entité cliente, puis à :
-mettre en oeuvre les étapes d) à g) sur la base de la valeur de compteur d'authentification temporaire et, en cas de succès de l' authentification de ladite entité cliente,
-mettre à jour la valeur de compteur d'authentification correspondant à l'état courant clu compteur de l'entité d'authentification avec la valeur de compteur d'authentification temporaire et mettre en œuvre l'étape h) .
De préférence, l'étape e) consiste à transmettre en outre à l'entité d'authentification la valeur de compteur d' authentification. De préférence, la valeur de compteur d'authentification est codée sur au moins 128 bits. L'invention concerne également une carte à puce, caractérisé en ce qu'elle comprend un circuit intégré et des moyens de mémorisation d'une clé secrète et de mise en œuvre du procédé selon l'invention. De préférence, il s'agit d'une carte à puce sans contact. L'invention concerne encore une entité d'authentification d'au moins une entité cliente, caractérisé en ce qu'elle comprend un lecteur de carte à puce doté de moyens pour la mise en œuvre du procédé selon l'invention. -De préférence, l'entité d'authentification comprend un lecteur de carte à puce sans contact.
D'autres caractéristiques et avantages de la présente invention apparaîtront plus clairement à la lecture de la description suivante donnée à titre d'exemple illustratif et non limitatif et faite en référence aux figures annexées dans lesquelles :
—la figure 1 est un schéma illustrant un processus d'authentification par clé secrète selon, l'état de la technique, et a déjà été décrite ;
—la figure 2 est un schéma illustrant Les principales étapes du procédé d'authentification selon la présente invention.
La figure 2 décrit donc les étapes principales du procédé d'authentification par clé secrète d'une entité cliente A par une entité d'authentification B, selon la présente invention. L'entité A souhaitant s'authentifier possède une clé secrète KA qui lui est propre, un moyen de mémorisation d'une valeur de compteur CA, ainsi qu'une fonction cryptographique de signature S, partagée également par l'entité d'authentification B, et qui est prévue pour s'appliquer avec les deux opérandes suivants : une clé secrète et une valeur de compteur, de sorte à signer la valeur de compteur .
L'entité d'authentification B comprend quant à elle une liste de couples (Ai, KAi) , Ai étant le nom d'une des n entités clientes susceptibles d'être authentifiées par l'entité d'authentification B et KAi étant la clé secrète associée à l'entité cliente Ai qui lui est propre. L'entité d'authentification .. comprend également un compteur COMPTB délivrant une valeur de compteur CB et la fonction cryptographique S, identique à celle implémentée dans l'entité cliente A.
Le déroulement du processus d'authentification anonyme selon l'invention est le suivant. Dans une première étape, lorsque l'entité cliente A veut s'authentifier auprès de l'entité d'authentification B, elle se signale à B par la transmission d'une demande d'authentification anonyme « DemandeAuthentification ». En réponse, dans une deuxième étape, l'entité d'authentification B envoie vers l'entité cliente A la valeur de compteur CB correspondant à l'état courant de son compteur COMPTB.
Dans une troisième étape, l'entité cliente A compare la valeur de compteur CB reçue avec la valeur de compteur CA mémorisée par l'entité cliente A. A ce stade, deux: possibilités s'offrent à l'entité cliente A :
Soit CA > CB, alors -l'entité cliente A ne fait plus rien car cette situation signifie qu'une entité essaye de faire rejouer une signature à l'entité cliente A. Or, selon une caractéristique de l'invention, pour ne pas être reconnaissable par son comportement, une entité cliente ne signe jamais deux fois les mêmes données. Cette situation met donc fin au processus d' authentification.
Soit CA < CB, alors l'entité cliente A peut avoir confiance en l'entité d'authentification B car la valeur de compteur reçue CB étant supérieure strictement à la valeur de compteur mémorisée par A, cela signifie que cette valeur de compteur CB ne lui a encore jamais été soumise pour signataire. Le processus passe alors à 1 ' étape suivante .
Dans une quatrième étape, l'entité cliente A signe la valeur de compteur reçue CB par application de la fonction cryptographique S avec comme opérandes la clé secrète KA associée à l'entité cliente A et la valeur de compteur CB. Le résultat de cette opération de signature de compteur S(KA, CB) est transmis de l'entité cliente A vers l'entité d'authentification B. L'entité cliente A met alors à jour dans une cinquième étape sa valeur de compteur mémorisée CA avec la dernière valeur de compteur licite qui lui a été transmis par l'entité d'authentification B, à savoir CB . Dans une sixième étape, l'entité d'authentification B recherche au moins une entité cliente Ai parmi les n entités clientes qu'elle est capable d'authentifier, pour laquelle la signature correspondante de la valeur de compteur CB S(KAι, CB) est cohérente avec la signature de compteur reçue de l'entité cliente qui cherche à s'authentifier S(KA, CB) .
Si aucune entité cliente susceptible d'être identifiée n'est trouvée, alors cela signifie que l' authentification a échoué. A l'inverse, si exactement une entité cliente Ai est trouvée à l'issue eue la ph~.se de recherche pour laquelle S(K Ai, CB) = S(KA, CB) , alors l'entité d'authentification B en conclut que A = Ai . Cela signifie que c'est l'entité cliente Ai qui a cherché à s'authentifier auprès de l'entité d'authentification B et que cette authentification a. réussi.
Dans une septième et dernière étape mettant fin au processus d'authentification, l'entité d'authentification B fait croître la valeur- de compteur CB pour un -e prochaine demande d'authent fication.
Il est possible qu'un fraudeur, en renvoyant un nombre tiré au hasard, tombe sur" une valeur S(KAi, CB) qui existe et donc se fasse passer pour l'entité cliente Ai. Pour éviter ce risque, l'entité d'authentification B peut systématiquement faire refaire le processus d'authentification au moins une seconde fois de sorte à s'assurer qu'il reconnaît chaque fois la même entité cliente. Le processus peut même être répétée N fois, jusqu'à obtenir une probabilité de tomber au hasard N fois sur une valeur de signature «correspondant à la même entité cliente suffisamment faible.
Egalement, une autre optimisation du processus d'authentification concerne la gestion des cas de collision. En effet, à l'issue cle la sixième étape, on peut aboutir à un cas de collision, c'est-à-dire que plusieurs entités clientes Ai susceptibles d'être identifiées par l'entité d'authentification B ont été trouvées pour lesquelles la signature de compteur S(KAι, CB) est cohérente avec la signature de compteur reçue S(K A, CB) . Il existe en effet une probabilité faible, mais non nulle, pour la fonction cryptographique de signature S fournisse un résultat identi que pour deux données différentes. Dans cette situation de collision, il est nécessaire de répéter les étapes du procédé à partir de la deuxième étape, avec une valeur de compteur CB incrémentée à chaque répétition, jusqu'à l'obtention d'une entité cliente Ai susceptible d'être identifiée unique, pour laquelle S(KAi, CB) = S(KA, CB) .
La sixième étape, consistant en la- phase de recherche par l'entité d'authentification d'au m-oins une entité cliente Ai parmi les n entités clientes qu'elle est capable d'authentifier, pour laquelle la signature correspondante de la valeur de compteur CB S(KAι, CB) est cohérente avec la signature de compteur reçue de l'entité cliente qui cherche à s'authentifier S(KA, CB) , peut être mise en œuvre de la manière suivante. L'entité d'authentification B calcule, pour chaque entité cliente Ai susceptible d'être identifiée, la signature de compteur correspondante S(KAι, CB) par application de la fonction cryptographique S avec comme opérandes la valeur de compteur d'authentification CB et la clé secrète associée KAι, de sorte à établir une liste de couples entité cliente susceptible d'être identifiée/signature de compteur correspondante (Ai, S(KAi, CB) ) , pour la valeur de compteur CB courante .
Une fois cette liste établie, l'entité d'authentification la parcourt pour vérifier s'il existe au oins une entité cliente susceptible d'être identifiée Ai vé_rifiant S(KAι, CB) = S(KA, CB) .
Dans le cas où plusieurs couples (Ai, S(KAι, CB) ) correspondent, on a vu qu'il était nécessaire de répéter les opérations d'envoi et de signature d'une valeur de compteur CB. Néanmoins, cette répétition peut encore aboutir à l'existence de plusieurs couples (Ai, S(KAi, CB) ) qui correspondent. Dans ce cas, il est prévu de ne chercher les couples possibles que parmi les couples ayant déjà été sélectionnés aux itérations précédentes. Ainsi, le procédé convergera plus vite vers une entité cliente Ai unique puisque, à chaque itération, la signature de compteur S(KAi, CB) est calculée uniquement pour les entités clientes Ai correspondant aux couples (Ai, S(KAi, CB) ) sélectionnée à l'itération précédente.
A la sixième étape, la phase de calcul par B, pour chaque entité cliente Ai susceptible d'être ident-ifiée, de la signature de compteur correspondante S(KAi, CB) , de sorte à établir la liste de couples entité cliente susceptible d'être identifiée/signature de compteur correspondante (Ai, S(KAι, CB) ) , pour la valeur de compteur CB courante peut être très longue et pénalisante en termes de temps de réponse. Pour régler ce problème, selon une variante de l'invention, il est prévu que l'entité d'authentification B pré-calcule, pour au moins une valeur de compteur d'authentification CB à -venir, les listes de couples (Ai, S(KAι, CB) ) pour ces valeurs CB à venir et mémorise ces résultats. Ainsi, lorsqu'une entité cliente souhaitera s'authentifier par l'envoi du message DemandeAuthentification, l'entité d'authentif-:ication B répondra en envoyant une valeur de compter d'authentification CB pour laquelle la liste (Ai, S( Ai, CB) ) aura déjà été établie. De manière générale, selon ce mode de réalisation, tout envoi de B vers A d' une valeur de compteur d'authentification CB correspondra à une valeur de compteur d'authentification pour lacquelle une liste (Ai, S(KAι, CB) ) aura déjà été établie.
La phase de vérification par l'entité d'authentification B, consistant à rechercher l'existence d'au moins une entité cliente Ai de la liste (Ai, S( Ai, CB) ) pour laquelle S(KAι, CB) = S(KA, CB) peut également être très longue en cas de recherche séquentielle, en théorie de l'ordre de n/2 tests avec une liste com ortant n éléments. Aussi, pour optimiser cette phase, la liste des couples obtenus (Ai, S(KAi, CB) ) peut être ordonnée de façon croissante (ou décroissante) selon la valeur de la signature de compteur S(KAi, CB) . La reche-rche d'un couple dans cette liste ordonnée pour lequel la signature de compteur S(KAi, CB) correspond à S(KA, CB) peut alors être faite selon une recherche dichotomique. L'entité cliente recherchée est dans ce cas trouvée e moyenne après avoir effectué log2 (n) opérations, ce qui procure un gain de temps important .
Le compteur CB étant unique pour chaque authentification, il peut être utilisé comme identifiant de session d'authentification. Ainsi, si plusieurs entités Ai sont en train de se faire authentifier simultanément par l'entité B, cette dernière peut distinguer les dialogues grâce à cette valeur. Il suffit pour cela que les entités clientes cherchant à s'authentifier retournent la valeur CB en plus de la valeur de signature S (KA, CB) .
De préférence, le compteur COMPTB fournissant la valeur de compteur d'authentification CB croît d'un pas fixe. Toutefois, le fait que le compteur CB croisse d'un pas fixe permet de prévoir les valeurs de compteur d'authentification qui seront utilisées lors des authentifications à venir. De ce fait, un pirate peut demander plusieurs valeurs S(KA, CB) à une entité A pour plusieurs valeurs de compteurs CB et, ultérieurement, chercher à s'authentifier auprès de l'entité B en lui retournant les valeurs précédemment obtenues de l'entité cliente A. Ainsi, le pirate peut s'authentifier en se faisant passer pour A. Deux types de parade contre une telle attaque au système d'authentification peuvent être mises en œuvre.
Tout d'abord, une première parade consiste à faire croître le compteur COMPTB d'un pas aléatoire à chaque authentification, de sorte à ne plus utiliser des valeurs successives de CB . Dans ce cas, le compteur devra avoir une capacité plus grande afin de ne pas venir en butée . Une autre parade consiste à ne plus faire signer à l'entité cliente A cherchant à s'authentifier une simple valeur de compteur CB, mais un couple (CB, aléa) , CB s ' incrémentant régulièrement et aléa prenant des valeurs aléatoires. La valeur aléatoire est prévue pour être différente pour chacune des valeurs de compteur d'authentification envoyée, et chaque étape de signature de compteur mise en œuvre au cours du procédé d'authentification dans l'une quelconque de ses variantes est alors remplacée par une étape de signature du couple JCB, aléa), consistant en l'application de la fonction cryptographique S avec en plus comme opérande ladite valeur aléatoire associée.
Le procédé d'authentification tel qu'il vient d'être décrit est vulnérable aux attaques par saut de compteur, basées sur le fait que les entités A et B se synchronisent sur la valeur de compteur CB à chaque authentification. Ainsi, une machine malveillante peut se faire passer pour l'entité d'authentification B et envoyer à l'entité cliente A cherchant à s'authentifier une valeur de compteur beaucoup plus grande que la valeur de compteur d'authentification CB effective, correspondant à la valeur courante du compteur COMPTB de l'entité B. En mettant à jour sa valeur de compteur mémorisée CA avec cette grande valeur qui lui est soumise, l'entité A ne pourra plus répondre suite à une demande d'authentification tant que la valeur de compteur CB de l'entité d'authentification B n'aura pas rattrapée cette valeur CA, à cause du test de la troisième étape. De plus, si la machine malveillante fournit à l'entité A une valeur de compteur maximale, cette dernière, en mettant à jour sa valeur de compteur mémorisée CA à cette valeur maximale, devient définitivement inutilisable par la suite.
Les parades à ces attaques portent plus particulièrement sur la troisième étape du procédé d'authentification, où l'entité cliente A compare la valeur de compteur CB reçue avec la valeur de compteur CA mémorisée par l'entité cliente A.
Dans le cas où CA > CB, selon une variante de l'invention, les étapes intermédiaires suivantes sont mises en œuvre :
-l'entité A signale à l'entité B que sa valeur de compteur mémorisée CA est plus grande que la valeur CB et lui renvoie CA ;
-l'entité B envoie à A une valeur de compteur CBtemporaire > CA ;
puis, les autres étapes du procédé d'authentification sont mises en œuvre sur la base de cette valeur de CBtemoraire et, si 1 ' authentification de l'entité A réussit avec CBtemp0raire, alors l'entité B met à jour sa valeur de compteur d'authentification CB correspondant à l'état courant de son compteur COMPTB avec la valeur de compteur d'authentification CBtemp0raire. Enfin, le compteur est incrémenté pour une prochaine authentification. Ce processus permet à l'entité d'authentification de se prémunir contre une attaque par saut de compteur. En effet, elle va d'abord authentifier l'entité cliente A avec CBtemporaire, avant de mettre à jour son compteur. Ce processus permet également à l'entité cliente A de synchroniser le compteur de l'entité d'authentification B avec sa valeur de compteur mémorisée, si ce dernier avait subi une attaque par saut de compteur.
A ce stade, l'entité B peut aussi implémenter des protections supplémentaires. Par exemple, B peut n'autoriser qu'un certain nombre de ces synchronisations de compteur par entité cliente et par période. Egalement, B peut n'autoriser ces protections que dans une limite raisonnable où la différence entre la valeur d compteur mémorisée par l'entité cliente CA et la valeur de compteur d'authentification CB est inférieure à une valeur prédéterminée.
Selon une autre variante, à la troisième étape du procédé, dans le cas où la relation CA < CB est vérifiée, on vérifie en outre, côté entité cliente, que la différence entre la valeur de compteur d'authentification CB reçue et la valeur de compteur CA mémorisée par l'entité cliente est inférieure ou égale à une valeur prédéterminée Δ, soit CB - CA ≤ Δ. L'entité A n'accepte de signer la valeur de compteur CB que si cette condition supplémentaire est vérifiée. Cette condition supplémentaire permet à l'entité cliente A cherchant à s'authentifier de limiter les attaques par saut de compteur en n'acceptant qu'une incrémentation modérée de sa valeur de compteur mémorisée et en ignorant les sollicitations utilisant une valeur de compteur d'authentification très supérieure à sa valeur de compteur mémorisée. Selon un exemple de réalisation, les valeurs de compteur CA et CB peuvent être des nombres binaires codés sur au moins 128 bits, ce qui permet d'exécuter 2128 authentifications avant que le système n'arrive à l'exhaustion du compteur COMPTB.
Les étapes du procédé selon l'invention côté entité cliente, sont par exemple implémentées sur une carte à puce, de préférence une carte à puce sans contact. Une carte à puce pour la mise en œuvre des étapes du procédé selon l'invention ne nécessite que peu de capacité de calcul dans la mesure où les opérations à exécuter sont simples (au plus la signature d'un compteur). L'entité d'authentification se présente alors sous la forme d'un lecteur de carte à puce avec ou sans contact.
Avantageusement, grâce au procédé selon l'invention, seule une entité d'authentification légitime peut reconnaître l'identité de l'entité cliente cherchant à s'authentifier. L'identité de l'entité cliente A cherchant à s'authentifier n'est connue que de l'entité d'authentification B et n'est jamais révélée au cours de 1 'authentification. De plus, l'entité cliente A ne sait pas sous quel nom elle est identifiée par l'entité d'authentification. L'entité qui s'authentifie n'a en fait aucune identité statique qui pourrait être révélée. D'autre part, en faisant en sorte qu'une entité refuse de s'authentifier en présence d'une question qui lui a déjà été soumise, un tiers malveillant est incapable de distinguer des entités. Au vue de deux authentifications successives, il n'est pas possible de dire si ce sont deux entités distinctes ou la même entité qui se sont authentifiées. L'anonymat est donc complet.

Claims

REVENDICATIONS
1. Procédé d'authentification d'au moins une entité cliente (A) par une entité d'authentification (B) , ladite entité d'authentification (B) comprenant un ensemble de clés secrètes (KAi) , chacune étant associée à une entité cliente (Ai) susceptible d'être identifiée par ladite entité d'authentification, ledit procédé étant caractérisé en ce qu'il comprend les étapes suivantes consistant à :
a-transmettre une demande d'authentification anonyme (DemandeAuthentification) de la part de l'entité cliente
(A) vers l'entité d'authentification (B) ;
b-envoyer de l'entité d'authenti ication (B) vers l'entité cliente (A), une valeur de compteur d'authentification (CB) correspondant à l'état courant d'un compteur (COMPTB) de l'entité d'authentification
(B) ;
c-vérifier, côté entité cliente (A) , que la valeur de compteur d'authentification (CB) reçue est strictement supérieure à une valeur de compteur (CA) mémorisée par l'entité cliente ;
d-calculer, côté entité cliente (A) , une signature de compteur par application d'une fonction cryptographique (S) partagée par l'entité cliente et l'entité d'authentification, avec comme opérandes ladite valeur de compteur d' authentification (CB) et une clé secrète (KA) associée à l'entité cliente (A) ;
e-transmettre ladite signature (S(KA, CB) ) de compteur à l'entité d'authentification (B) ;
f-mettre à jour la valeur de compteur (CA) mémorisée par l'entité cliente (A) avec ladite valeur de compteur d'authentification (CB) ;
g-rechercher, côté entité d'authentification (B) , au moins une entité cliente (Ai) susceptible d'être identifiée, pour laquelle la signature de compteur correspondante (S(KAi, CB) ) pour ladite valeur de compteur d'authentification (CB) est cohérente avec la signature de compteur reçue (S(KA, CB) ) ;
h-faire croître le compteur d'authentification (COMPTB).
2. Procédé d'authentification selon la revendication 1, caractérisé en ce que les étapes b) à h) sont réitérées au moins une fois, de sorte à s'assurer que l'entité cliente identifiée est identique à chaque itération.
3. Procédé selon la revendication 1 ou 2, caractérisé en ce que l'étape de recherche consiste à :
i-calculer, pour chaque entité cliente (Ai) susceptible d'être identifiée, la signature de- compteur correspondante (S(KAi, CB) ) par application de la fonction cryptographique (S) avec comme opérandes la valeur de compteur d'authentification (CB) et la clé secrète associée (KAι) , de sorte à établir une liste de couples entité cliente susceptible d'être identifiée/signature de compteur correspondante (Ai, S(KAi, CB) ) , pour ladite valeur de compteur (CB) ;
j -vérifier la cohérence entre la signature de compteur reçue (S(KA, CB) ) et au moins une signature de compteur (S(KAi, CB) ) de ladite liste.
4. Procédé d'authentification selon la revendication 3, caractérisé en ce que la liste des couples entité cliente susceptible d'être identifiée/signature de compteur correspondante (Ai, S(KAι, CB) ) établie pour une valeur de compteur d'authentification (CB) donnée, est ordonnée, côté entité d'authentification, selon la valeur de ladite signature de compteur (S(KAi, CB) ) .
5. Procédé d'authentification selon la revendication 3 ou 4, caractérisé en ce qu'en cas de cohérence entre la signature de compteur reçue (S(KA, CB) ) et la signature de compteur (S(KAi, CB) ) d'une pluralité de couples, les étapes b) à h) sont réitérées jusqu'à obtention d'un couple unique pour lequel la signature de compteur correspond à la signature de compteur reçue.
6. Procédé d'authentification selon la revendication 5, caractérisé en ce que, lors de la répétition de l'étape i) , la signature de compteur (S(KAι, CB) ) est calculée uniquement pour les entités clientes (Ai) correspondant à ladite pluralité de couples déterminée à l'itération précédente .
7. Procédé d'authentification selon l'une quelconque des revendications 3 à 5, caractérisé en ce qu'il consiste à mettre en œuvre l'étape i) de manière anticipée par rapport à une demande d'authentification issue d'une entité cliente (A) à l'étape a), ladite étape i) anticipée consistant a. pré-établir, côté entité d'authentification (B) , pour au moins une valeur de compteur d'authentification (CB) à venir, la liste des couples entité cliente susceptible d'être identifiée/signature de compteur correspondante (Ai, S(KAι, CB) ) pour chacune desdites valeurs de compteur d'authentification à venir, et à mémoriser lesdites listes pré-établies côté entité d'authentification (B) , tout envoi de l'entité d'authentification (B) vers l'entité cliente (A) d'une valeur de compteur d'authentification (CB) , correspondant à l'envoi d'une valeur de compteur d'authentification (CB) pour laquelle une liste des couples entité cliente susceptible d'être identifiée/signature de compteur correspondante (Ai, S(KAi, CB) ) a déjà été pré—établie.
8. Procédé d'authentification selon l'une quelconque des revendications précédentes, caractérisé en ce que l'étape h) consiste à faire croître le compteur d'authentification (COMPTB) d'un pas fixe.
9. Procédé d'authentification selon l'une quelconque des revendications 1 à 7, caractérisé en ce que l'étape h) consiste à faire croître le compteur d'authentification (COMPTB) d'un pas aléatoire.
10. Procédé d'authentification selon l'une quelconque des revendications 1 à 8, caractérisé en ce que, en réponse à une demande d'authentification, l'étape b) consiste à envoyer, côté entité d'authentification (B) , en plus de la valeur de compteur d'authentification (CB) , une valeur aléatoire associée à ladite valeur de compteur (CB) , ladite valeur aléatoire étant différente pour chacune des valeurs de compteur d'authentification envoyée, chaque étape de signature de compteur mise en œuvre au cours dudit procédé étant remplacée par une étape de signature du couple valeur de compteur d' authentification/valeur aléatoire associée, consistant en l'application de la fonction cryptographique (S) comprenant en plus comme opérande ladite valeur aléatoire associée.
11. Procédé d'authentification selon l'une quelconque des revendications précédentes, caractérisé en ce que l'étape c) consiste en outre à vérifier que la différence entre la valeur de compteur d'authentification (CB) reçue et la valeur de compteur (CA) mémorisée par l'entité cliente est inférieure ou égale à une valeur prédéterminée.
12. Procédé d'authentification selon l'une quelconque des revendications 1 à 10, caractérisé en ce que, l'étape c) n'étant pas vérifiée, les étapes intermédiaires suivantes sont mises en œuvre consistant à :
-envoyer de l'entité cliente (A) vers l'entité d'authentification (B) , la valeur de compteur (CA) mémorisée par l'entité cliente ; -envoyer de l'entité d'authentification (B) vers l'entité cliente (A), une valeur de compteur d'authentification temporaire supérieure à ladite valeur de compteur (CA) mémorisée par l'entité cliente, puis à :
-mettre en oeuvre les étapes d) à g) sur la base de la valeur de compteur d'authentification temporaire et, en cas de succès de l' authentification de ladite entité cliente,
-mettre à jour la valeur de compteur d'authentification (CB) correspondant à l'état courant du compteur (COMPTB) de l'entité d'authentification (B) avec la valeur de compteur d'authentification temporaire et mettre en œuvre 1 'étape h) .
13. Procédé selon l'une quelconque des revendications précédentes, caractérisé en ce que l'étape e) consiste à transmettre en outre à l'entité d'authentification (B) la valeur de compteur d'authentification (CB) .
14. Procédé d'authentification selon l'une quelconque des revendications précédentes, caractérisé en ce que la valeur de compteur d'authentification (CB) est codée sur au moins 128 bits.
15. Carte à puce, caractérisé en ce qu'elle comprend un circuit intégré et des moyens de mémorisation d'une clé secrète (KA) et de mise en œuvre du procédé selon l'une quelconque des revendications 1 à 14.
16. Carte à puce selon la revendication 15, caractérisé en ce qu'il s'agit d'une carte à puce sans contact.
17. Entité d'authentification (B) d'au moins une entité cliente (A), caractérisé en ce qu'elle comprend un lecteur de carte à puce doté de moyens pour la mise en œuvre du procédé selon l'une quelconque des revendications 1 à 14.
18. Entité d'authentification selon la revendication 17, caractérisé en ce qu'elle comprend un lecteur de carte à puce sans contact.
EP05736911A 2004-03-16 2005-03-04 Procede d'authentification anonyme Withdrawn EP1726121A1 (fr)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
FR0402674A FR2867930A1 (fr) 2004-03-16 2004-03-16 Procede d'authentification anonyme
PCT/FR2005/000528 WO2005101726A1 (fr) 2004-03-16 2005-03-04 Procede d'authentification anonyme

Publications (1)

Publication Number Publication Date
EP1726121A1 true EP1726121A1 (fr) 2006-11-29

Family

ID=34896544

Family Applications (1)

Application Number Title Priority Date Filing Date
EP05736911A Withdrawn EP1726121A1 (fr) 2004-03-16 2005-03-04 Procede d'authentification anonyme

Country Status (6)

Country Link
US (1) US20080270798A1 (fr)
EP (1) EP1726121A1 (fr)
JP (1) JP2007529935A (fr)
CN (1) CN1934823A (fr)
FR (1) FR2867930A1 (fr)
WO (1) WO2005101726A1 (fr)

Families Citing this family (15)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
FR2874144A1 (fr) * 2004-08-03 2006-02-10 France Telecom Procede d'authentification anonyme base sur un algorithme cryptographique de type asymetrique
WO2007048969A1 (fr) * 2005-10-24 2007-05-03 France Telecom Serveur, systeme et procede pour le chiffrement de donnees numeriques, en particulier pour la signature electronique de donnees numeriques au nom d'un groupe d'utilisateurs
GB2450131B (en) * 2007-06-13 2009-05-06 Ingenia Holdings Fuzzy Keys
US8051097B2 (en) * 2008-12-15 2011-11-01 Apple Inc. System and method for authentication using a shared table and sorting exponentiation
JP5434203B2 (ja) * 2009-04-02 2014-03-05 大日本印刷株式会社 認証装置、認証プログラム、認証システム、パスワード生成装置、携帯型セキュリティデバイス、およびパスワード生成プログラム
CN101997688B (zh) 2010-11-12 2013-02-06 西安西电捷通无线网络通信股份有限公司 一种匿名实体鉴别方法及系统
CN101984577B (zh) * 2010-11-12 2013-05-01 西安西电捷通无线网络通信股份有限公司 匿名实体鉴别方法及系统
EP2461534A1 (fr) * 2010-12-01 2012-06-06 Irdeto B.V. Protection de mot de contrôle
US20120222100A1 (en) * 2011-02-24 2012-08-30 International Business Machines Corporation Advanced captcha using integrated images
CN103312499B (zh) 2012-03-12 2018-07-03 西安西电捷通无线网络通信股份有限公司 一种身份认证方法及系统
CN103312670A (zh) 2012-03-12 2013-09-18 西安西电捷通无线网络通信股份有限公司 一种认证方法及系统
US9998494B2 (en) * 2013-09-13 2018-06-12 GM Global Technology Operations LLC Methods and apparatus for secure communication in a vehicle-based data communication system
US10949520B2 (en) 2018-10-02 2021-03-16 Capital One Services, Llc Systems and methods for cross coupling risk analytics and one-time-passcodes
JP2022502901A (ja) * 2018-10-02 2022-01-11 キャピタル・ワン・サービシーズ・リミテッド・ライアビリティ・カンパニーCapital One Services, LLC 非接触カードの暗号化認証のためのシステムおよび方法
EP4055796B1 (fr) * 2019-11-05 2025-06-04 Capital One Services, LLC Systèmes et procédés d'analyse de risque de couplage croisé et de code secret à usage unique

Family Cites Families (7)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CZ289189B6 (cs) * 1994-10-27 2001-11-14 International Business Machines Corporation Způsob zajiątění identifikace pohyblivého uľivatele v komunikačním systému a přenosný vstupní přístroj k provádění tohoto způsobu
FR2757723B1 (fr) * 1996-12-24 1999-01-15 France Telecom Procede d'authentification aupres d'un systeme de controle d'acces et/ou de paiement
US5708710A (en) * 1995-06-23 1998-01-13 Motorola, Inc. Method and apparatus for authentication in a communication system
FR2745965B1 (fr) * 1996-03-08 1998-09-04 Inside Technologies Procede d'authentification d'un emetteur au cours d'une communication a un seul sens
US6519647B1 (en) * 1999-07-23 2003-02-11 Microsoft Corporation Methods and apparatus for synchronizing access control in a web server
JP4326189B2 (ja) * 2002-06-10 2009-09-02 健 坂村 自律型ｉｃカード及び通信システム
US7373509B2 (en) * 2003-12-31 2008-05-13 Intel Corporation Multi-authentication for a computing device connecting to a network

Non-Patent Citations (1)

* Cited by examiner, † Cited by third party
Title
See references of WO2005101726A1 *

Also Published As

Publication number Publication date
JP2007529935A (ja) 2007-10-25
FR2867930A1 (fr) 2005-09-23
WO2005101726A1 (fr) 2005-10-27
CN1934823A (zh) 2007-03-21
US20080270798A1 (en) 2008-10-30

Similar Documents

Publication Publication Date Title
EP1922632B1 (fr) Procede et appareil pour mot de passe a usage unique
EP2347541B1 (fr) Systéme d&#39;autentification
EP3280089B1 (fr) Procédé de génération de clé et procédé de contrôle d&#39;accès
EP2820795B1 (fr) Procede de verification d&#39;identite d&#39;un utilisateur d&#39;un terminal communiquant et systeme associe
EP1726121A1 (fr) Procede d&#39;authentification anonyme
EP2345202A2 (fr) Procédé de signature numérique en deux étapes
FR2964812A1 (fr) Procede d&#39;authentification pour l&#39;acces a un site web
EP1166496B1 (fr) Procede d&#39;authentification et de signature de message utilisant des engagements de taille reduite et systemes correspondants
EP2568406B1 (fr) Procédé de mise en oeuvre, a partir d&#39;un terminal, de données cryptographiques d&#39;un utilisateur stockées dans une base de données
WO2019145620A1 (fr) Système sécurisé de transactions entre terminaux
EP2509025A1 (fr) Procédé d&#39;accès à une ressource protégée d&#39;un dispositif personnel sécurisé
EP1514377A1 (fr) Procede et dispositif d&#39;interface pour echanger de maniere protegee des donnees de contenu en ligne
EP1774699A1 (fr) Procede d&#39;authentification anonyme base sur un algorithme cryptographique de type asymetrique
EP1851901B1 (fr) Procede de pre-authentification rapide par reconnaissance de la distance
CN109145543B (zh) 一种身份认证方法
EP2836952A1 (fr) Procede de generation et de verification d&#39;identite portant l&#39;unicite d&#39;un couple porteur-objet
WO2006027430A1 (fr) Procede d’authentification entre entites communiquant entre elles au travers d’un reseau de telecommunications
FR3070776A1 (fr) Enrolement perfectionne d&#39;un equipement dans un reseau securise
EP4560972A1 (fr) Authentification avec une communication en champ proche securisée
CN121037098A (zh) 基于动态扰动因子的前端数据加密方法、系统及可读介质
WO2012022856A1 (fr) Procédé d&#39;authentification d&#39; un utilisateur du réseau internet
Morales Securing Passwords Against Dictionary Attacks
WO2006035137A1 (fr) Procede et dispositif de filtrage pour detecter une usurpation d’adresse dans un reseau informatique
EP2115657A2 (fr) Procede et systeme d&#39;autorisation d&#39;acces a un serveur
FR3076153A1 (fr) Procede pour creer une signature electronique a distance au moyen du protocole fido

Legal Events

Date Code Title Description
PUAI Public reference made under article 153(3) epc to a published international application that has entered the european phase

Free format text: ORIGINAL CODE: 0009012

17P Request for examination filed

Effective date: 20060905

AK Designated contracting states

Kind code of ref document: A1

Designated state(s): AT BE BG CH CY CZ DE DK EE ES FI FR GB GR HU IE IS IT LI LT LU MC NL PL PT RO SE SI SK TR

RIN1 Information on inventor provided before grant (corrected)

Inventor name: CHARLES, OLIVIER

Inventor name: ARDITTI, DAVID

Inventor name: NGUYEN NGOC, SEBASTIEN

Inventor name: BARITAUD, THIERRY

DAX Request for extension of the european patent (deleted)
STAA Information on the status of an ep patent application or granted ep patent

Free format text: STATUS: THE APPLICATION IS DEEMED TO BE WITHDRAWN

18D Application deemed to be withdrawn

Effective date: 20081001