WO2006024732A1 - Procede d'authentification anonyme base sur un algorithme cryptographique de type asymetrique - Google Patents

Procede d'authentification anonyme base sur un algorithme cryptographique de type asymetrique Download PDF

Info

Publication number
WO2006024732A1
WO2006024732A1 PCT/FR2005/001868 FR2005001868W WO2006024732A1 WO 2006024732 A1 WO2006024732 A1 WO 2006024732A1 FR 2005001868 W FR2005001868 W FR 2005001868W WO 2006024732 A1 WO2006024732 A1 WO 2006024732A1
Authority
WO
WIPO (PCT)
Prior art keywords
authentication
entity
client entity
counter value
client
Prior art date
Application number
PCT/FR2005/001868
Other languages
English (en)
Inventor
David Arditti
Olivier Charles
Sébastien NGUYEN NGOC
Original Assignee
France Telecom
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 filed Critical France Telecom
Priority to US11/659,296 priority Critical patent/US20090019282A1/en
Priority to EP05793306A priority patent/EP1774699A1/fr
Publication of WO2006024732A1 publication Critical patent/WO2006024732A1/fr

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/3236—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 cryptographic hash functions
    • 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
    • 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 generally relates to the domain of authentication of entities in a telecommunication network.
  • It relates more particularly to a method of anonymous authentication of at least one client entity by an authentication entity, based on an asymmetric cryptographic algorithm, for purposes, for example, to authorize or not the user to access to resources when the anonymity of the user who authenticates is required.
  • resource must be taken with a very broad acceptance and generally refers to any function, application, service, set of data to which a user can access and whose access is conditioned by a prior authorization issued after an authentication procedure.
  • it may be a service provided by a specialized server, a network access function, a computer resource such as a database or a software application available on a server. and can be shared by multiple users.
  • authentication is a security service performed by an authentication entity, the purpose of which is to ensure the identity of a user, bringing by the
  • An authentication entity commonly refers to any equipment, machine or computer system that makes it possible to centralize an authentication process and that is accessible by users wishing to authenticate for access to resources via a telecommunication network.
  • a client entity in the present description, refers to any electronic system or equipment for exchanging data with the authentication entity.
  • a client entity A wishes to authenticate with an authentication entity B, it first provides its identity to the entity B, in the form of a static identifier which is specific to it, and the then prove 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 issued by a client entity presenting itself as holder of the identity A, said authentication entity first generates a random number called hazard, or called challenge or challenge, and sends this random to the client entity A.
  • the client entity A signs the received randomness according to a predefined cryptographic algorithm with secret key, such as the algorithm DES (acronym for "Data Encryption Standard").
  • the entity A then returns to the authentication entity B the value C (K A , random), where C is the cryptographic algorithm mentioned above taking as operands the values K A and random.
  • Entity B performs the same calculation using the same cryptographic function C and the secret key AK A , and compares the result obtained with the value returned to it by the entity A. In case of consistency between the result waited and the value returned to it A, the authentication entity B validates the authentication, thus indicating that the entity A has succeeded in authenticating itself.
  • the validation of the authentication results for example by the allocation by the authentication entity to the client entity A that has been successfully authenticated, rights of access to the requested resources.
  • a specific identifier of the client entity is necessarily transmitted in clear to the authentication entity.
  • a malicious third party is able to know the specific identifier of the entity that authenticates itself by observing the transaction between the authentication entity and the authenticating entity.
  • the specific identifier of an entity wishing to authenticate can also be deduced by a malicious third party acting this time actively, that is to say by initiating an authentication process by impersonating a authentication entity vis-à-vis the authenticating entity.
  • An authenticating entity can still be recognized by observing its behavior and, more specifically, by observing the responses provided by the entity during previous authentication processes.
  • the responses provided by an authenticating client entity are characteristic of certain entries corresponding to the risks that have been submitted to it by the authentication entity and, for the same entry, the authenticating entity will always provide the same information. reply.
  • an entity that signs hazards to authenticate can be characterized by its response for a particular random value (for example, 0, 10, 100, 1000, etc.). By observing two successive identifications with the same hazard, it is therefore possible to deduce whether they are two distinct entities or the same entity that have authenticated.
  • a public key algorithm can also be implemented in the authentication process as described above with reference to FIG. 1.
  • the entity A then signs the received randomness of the authentication entity. B using its private key which it is the only one to dispose of, and the entity B verifies the accuracy of the calculation, to ensure that it is in the presence of entity claiming identity of A, realizing the reverse operation thanks to the public key of AP A / which it has.
  • this authentication method based on an asymmetric algorithm, has exactly the same disadvantages as the symmetric version.
  • the present invention aims to overcome the aforementioned various disadvantages by proposing an authentication method using an asymmetric encryption algorithm, in which in particular, 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 for authenticating at least one client entity by an authentication entity having a private key and public key pair for implementing a public key encryption and decryption algorithm, respectively on the client entity side and on the authentication entity side, said method comprising, on the client entity side, steps of: generating a cryptogram obtained by encrypting an authentication message comprising an identification data item specific to said entity, an associated secret data item and an authentication counter value, provided to guarantee that said authentication is not replayed,
  • a database storing, for each client entity that may be authenticated, a record comprising at least the identification data of said client entity, determining the record of said database corresponding to the data item; decrypted identification, and verification of the correspondence between the decrypted secret data and the secret data of said client entity obtained from said record.
  • the corresponding record of the database further comprises the secret data of said client entity.
  • the obtaining of the secret data of said client entity from said record consists in applying a cryptographic MAC type function taking as operand an encryption key stored on the authentication entity side and the identification data of said recording.
  • the corresponding record of the database further comprises an image of the secret data of said client entity, obtained by the application of a cryptographic function to in a single direction taking as an operand said secret data of said client entity, the step of verifying the correspondence between the decrypted secret data and the secret data of said client entity, obtained from said record, being replaced by a step consisting of checking the match of the image of said decrypted secret data computed from said one-way function with the image of the secret data of said record.
  • the authentication entity-side verification step further comprises checking the correspondence between the decrypted authentication counter value and the current counter value stored on the authentication entity side.
  • the counter value stored on the authentication entity side is incremented by a constant value.
  • the counter counter value stored on the authentication entity side is incremented by a random value.
  • the sending of the authentication entity to the client entity of the authentication counter value is performed in response to the sending of an anonymous authentication request from said client entity to said authentication entity. 'authentication.
  • the authentication counter value corresponds to a current counter value stored on the client entity side
  • each record of the database further comprises an entity-side stored counter value.
  • authentication method specific to the client entity said method comprising, on the client entity side, following the encryption step of the authentication message:
  • the counter values correspond to clock values implemented on the client entity side and on the authentication entity side.
  • the invention also relates to an integrated circuit comprising calculation and storage means for implementing the method according to the invention.
  • the device comprises a smart card with or without contact.
  • the invention also relates to an authentication entity of at least one client entity, characterized in that it comprises a card reader chip with or without contact provided with means for implementing the method according to the invention.
  • the invention also relates to a program recorded on a data carrier and comprising instructions for controlling the execution of the method according to the invention by a computer system.
  • 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 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 does not have any static identity that could be revealed.
  • an authentication counter synchronizing with each authentication on the client entity side and authentication entity side ensures on the one hand, the impossibility for any entity other than the authentication entity, of recognize the client entity by observing its behavior, by ensuring that a client entity refuses to authenticate itself in the presence of a question that has already been submitted to it and, on the other hand, ensures the impossibility to cheat vis-à-vis the authentication entity by replaying a previous valid authentication.
  • a malicious third party is unable to distinguish client entities. In view of two successive authentications, it is not possible to say whether they are two distinct entities or the same entity that have authenticated. The anonymity is complete.
  • FIG. 2 is a diagram illustrating the main steps of the authentication method according to a first embodiment;
  • FIG. 3 is a diagram illustrating the main steps of the authentication method according to a second embodiment of the invention
  • the authentication method according to the invention guaranteeing the anonymity of the authenticating entity, is therefore based on the use of a public key algorithm.
  • a public key algorithm is based on a pair of complementary keys specific to the authentication entity B: a public key P B and a private key S B.
  • Entity A which wants to prove its identity, contains an idA identification data of its own, an associated secret data K A , a storage means of a counter value denoted CPTA in FIG. FIG. 3, the public key P B of the authentication entity B, and the public-key encryption algorithm, noted ASYM, also shared by the authentication entity B, which is intended to apply with the following two operands: the public key P B and an authentication message to be encrypted and which will be described in more detail below.
  • ASYM public-key encryption algorithm
  • the authentication entity B which verifies the identities, for its part contains a database BD storing, for each client entity Ai capable of being authenticated by the authentication entity B, a record comprising at least the data identification idAi.
  • each record of the database BD further comprises the secret data K A i associated with the client entity Ai.
  • the entity B thus has according to this preferred embodiment, secret data of all users of the system, stored in the database BD with the corresponding identification data. It will be seen later that, according to one variant, the database BD can store only idAi identification data specific to each client entity that can be authenticated.
  • the authentication entity B also comprises the private key S B corresponding to P B and the public key decryption algorithm ASYM, which is intended to apply with the following two operands: the private key S B and the message encrypted received, so as to recover the message in the clear.
  • the authentication entity B finally comprises means for storing at least one counter value, denoted respectively CB and CBA 1 in FIGS. 2 and 3.
  • the flow of the anonymous authentication process is as follows, with reference to FIG. 2.
  • the counter value CPTA stored on the client entity side is initialized to 0 and the authentication counter value CB, authentication entity side, is initialized to 1.
  • a first step when the client entity A wants to authenticate itself to the authentication entity B, it signals itself to B by the transmission of an anonymous authentication request, for example in the form of the message " RequestAuthentication Colour
  • the authentication entity B sends to the client entity A an authentication counter value CB corresponding to the current counter value stored on the authentication entity side.
  • the sending of the CB authentication counter value could nevertheless be performed the
  • the client entity A compares the received authentication counter value CB with the value of the counter CPTA stored by the client entity A. At this stage, two possibilities are available to the client entity A:
  • the client entity A can have confidence in the authentication entity B because the received authentication counter value CB being strictly greater than the value of the counter CPTA stored by A, this means that this value counter has never been presented to him yet.
  • the process then moves to the next step.
  • the client entity A updates its stored counter value CPTA with the last legal counter value transmitted to it by the authentication entity B, namely CB.
  • ASYM secret data
  • CB' decrypted authentication counter value.
  • the entity B determines the corresponding record in its database BD. Entity B must then verify that the decrypted secret data K ' A from the received cryptogram, effectively corresponds to the secret data K A associated with the client entity A. To carry out this verification, the secret data K A of the client entity A is obtained on the authentication entity side, from the previously determined record.
  • the database BD is provided for storing the secret data K A i respectively associated with idAi identification data of the client entities likely to be authenticated. Also, the secret data K A associated with the client entity A is stored in the record that has been determined from the identification data idA decrypted by B. The entity B can thus find, from the the record corresponding to the decrypted data idA, the associated secret data K A.
  • the secret data KA associated with the client entity A identified during authentication is then dynamically determined on the authentication entity side.
  • This determination may be derived from a diversification calculation implemented by the authentication entity from the database record that has been determined and which includes the idA identification data of the client entity A
  • the key M must then be stored on the authentication entity side. The process steps remain unchanged except for the step of the
  • the client entity A is authenticated, and the authentication entity B increments its stored CB counter value for a next authentication process.
  • entity A is not authenticated.
  • the authentication counter value CB stored on the authentication entity side is incremented by a constant value.
  • increasing the counter value by a constant step makes it possible to predict the authentication counter values that will be used during future authentications.
  • an attacker can request more than one R 'value from an A entity for several consecutive CB counter values, and later try to authenticate with Entity B by returning the previously obtained values from client entity A.
  • the attacker could authenticate himself by posing as A.
  • Two types of parry against a such an attack to the authentication system can be implemented.
  • a first parry consists in increasing the counter value CB stored on the authentication entity side of a random value with each authentication, so as not to use successive values of CB.
  • Another parry consists of client entity A, no longer to encrypt an authentication message R based on a simple counter value CB, but on a pair (CB, random), CB incrementing regularly and randomly taking random values.
  • the random value is intended to be different for each of the authentication counter values sent.
  • the authentication method as just described is vulnerable to counter hop attacks, based on the fact that entities A and B synchronize on the counter value CB at each authentication. Thus, a malicious machine can impersonate the authentication entity B and send to the client entity A seeking to authenticate a counter value much larger than the actual CB authentication counter value, corresponding to the current counter value stored on the entity B side.
  • malicious code provides the entity A a maximum counter value, the latter, by updating its stored counter value CPTA to this maximum value, becomes permanently unusable thereafter.
  • the parries to these attacks relate more particularly to the third step of the authentication method, where the client entity A compares the received CB counter value with the counter value CPTA stored by the client entity A.
  • the entity A signals to the entity B that its stored counter value CPTA is greater than the value CB and returns it CPTA;
  • entity B sends A a counter value
  • 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. Also, B may allow these protections only within a reasonable limit where the difference between the counter value stored by the client entity CPTA and the authentication counter value CB is less than a predetermined value.
  • the third step of the method in the case where the CPTA ⁇ CB relation is verified, it is further verified, on the client entity side, that the difference between the received authentication counter value CB and the value of CPTA counter stored by the client entity is less than or equal to a predetermined value ⁇ , ie CB - CPTA ⁇ Entity A only accepts to continue authentication if this additional condition is verified.
  • This additional condition allows the client entity A seeking to authenticate to limit counter-hop attacks by accepting only a moderate increment of. its stored counter value and ignoring the solicitations using an authentication counter value much higher than its stored counter value.
  • a second embodiment of the invention is described, for the implementation of a mono-directional version of the authentication method, that is to say requiring only exchanges in the meaning of the client entity to the authentication entity.
  • side authentication entity for each client entity.
  • the database BD comprises, for each client entity Ai capable of to be authenticated, a stored counter value CBAi unique to each client entity Ai, the database BD of the authentication entity B therefore contains records of the following type, comprising at least:
  • the value of Authentication counter is the current value of the CA counter stored on the client entity side.
  • the client-side stored AC counter value is initialized to 1 and the counter value, denoted CBA, corresponding to this client entity, stored on the authentication entity side, is initialized to 0.
  • ASYM secret key
  • R secret key
  • the entity B From the idA identification data decrypted, the entity B, now knowing the identity of A, determines the corresponding record and recovers in its database BD the elements K A and CBA associated with the client entity identified. . Entity B then compares the decrypted value of CA authentication counter with that CBA associated with the client entity identified in its database.
  • entity B then refuses authentication because it is a replay.
  • the client entity A is not authenticated and the authentication process is terminated.
  • the authentication entity B then verifies that the decrypted secret data K ' A from the received cryptogram, effectively corresponds to the secret data K A associated with the client entity A, which secret data K A is obtained at from the database record, in the same way as explained above with reference to the bi ⁇ directional embodiment of FIG. 2, depending on whether the record in the database stores the data of secret K A associated with idA.
  • the client entity A is authenticated and the authentication entity B updates the counter value CBA specific to the client entity A on the authentication entity side, with the last counter value of legitimate CA authentication that has been transmitted to it in encrypted form by the client entity A.
  • the client entity A is not authenticated.
  • This mono-directional embodiment advantageously makes it possible to avoid sending an authentication counter value from the authentication entity B to the client entity A to initiate the process. Only encrypted messages pass from the client entity to the authentication entity B. This avoids counter hop attacks as described with reference to the first embodiment.
  • the authentication counter values used in the first or second embodiment may be binary numbers encoded over at least 128 bits.
  • R ' ASYM (PB, R) implemented on the client entity side according to the first or the second embodiment
  • R ' ASYM (PB, R) implemented on the client entity side according to the first or the second embodiment
  • an optimization consists in implementing a clock on the client entity side and on the authentication entity side to set the CA and CBA authentication counter values, respectively on the client entity side and on the authentication entity side.
  • the CA and CBA authentication counter values can be, for example, the time elapsed in seconds since a fixed date.
  • the CA authentication counter value is replaced by a client entity-implemented HA clock value and the CBA counter value is replaced by an HB value implemented on the authentication entity side.
  • the client-side clock is likely to the
  • the client entity does not have an on-board clock
  • an external clock HA which may reside outside the client entity. It may be for example the clock of a PC type computer.
  • the client entity A retains an internally stored counter value CA whose value corresponds to the last clock value submitted.
  • the steps of the method according to the first or the second embodiment with reference to FIG. 2 or 3 may be implemented, on the client entity side, on any physical device comprising an integrated circuit provided with calculation and storage means. It may be for example a smart card, with or without contact. According to this example, the authentication entity is then in the form of a smart card reader with or without contact.
  • the method steps may be in the form of a program, recorded on a data carrier and including instructions for controlling the execution of the method as just described by a computer system.
  • the program for controlling the execution of the method according to the invention can be recorded in or transmitted by a data medium comprising instructions for controlling the execution of the method previously described by a computer system.
  • the data carrier can be a hardware storage medium, for example a CD-ROM, a magnetic diskette or a hard disk, or a medium transmissible, such as an electrical, optical or radio signal.

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Security & Cryptography (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Storage Device Security (AREA)

Abstract

L'invention concerne un procédé d'authentification d'une entité cliente (A) par une entité d'authentification (B) basé sur un algorithme de chiffrement (ASYM (PB, R) ) /déchiffrement (ASYM(SB, R')) à clé publique, mis en œuvre respectivement côté entité cliente/côté entité d'authentification, comprenant, côté entité cliente: -génération d'un cryptogramme (R') par chiffrement d'un message (R) comprenant une donnée d'identification (idA) de ladite entité, une donnée de secret (KA) et une valeur de compteur d'authentification (CA, CB) , garantissant que ladite authentification n'est pas rejouée, -envoi du cryptogramme vers l'entité d'authentification et, côté entité d'authentification: -déchiffrement dudit cryptogramme, -à partir d'une base de données (BD) mémorisant, pour chaque entité cliente susceptible d'être authentifiée, un enregistrement comprenant au moins la donnée d'identification de ladite entité cliente, détermination de l'enregistrement correspondant à la donnée d'identification déchiffrée, et -vérification de la correspondance entre la donnée de secret déchiffrée et la donnée de secret de ladite entité cliente, obtenue à partir dudit enregistrement.

Description

l'l'
PROCEDE D'AUTHENTIFICATION ANONYME BASE SUR UN ALGORITHME CRYPTOGRAPHIQUE DE TYPE ASYMÉTRIQUE
La présente invention concerne, de façon générale, le domaine de authentification d'entités dans un réseau de télécommunication.
Elle concerne plus particulièrement un procédé d'authentification anonyme d'au moins une entité cliente par une entité d'authentification, basé sur un algorithme cryptographique de type asymétrique, à des fins, par exemple, d'autoriser ou non l'utilisateur à accéder à des ressources lorsque l'anonymat de l'utilisateur qui s'authentifie est requis.
Dans la présente description, le terme de ressources doit être pris avec une acceptation trè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 fourni par un serveur spécialisé, une fonction d'accès à un réseau, une ressource informatique telle qu'une base de donnée ou une application logiciel disponible sur un serveur et pouvant être partagée par plusieurs utilisateurs.
D'une manière générale, authentification est un service de sécurité réalisée par une entité d'authentification, dont l'objectif consiste à s'assurer de l'identité d'un utilisateur, apportant par l'
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'authentifier pour l'accès à des ressources, via un réseau de té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.
Diverses techniques d'authentification existent dans l'art antérieur. Parmi celles-ci, on peut citer authentification forte ou par « défi-réponse », qui se caractérise essentiellement par la succession d'étapes suivantes telles que représentées à la figure 1.
Voici la description dans le cas de l'utilisation d'un algorithme symétrique. Lorsqu'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, et la prouve ensuite par l'utilisation d'une clé secrète KA connue et partagée par les entités A et B seulement. 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é défi ou challenge, et envoie cet aléa à l'entité cliente A.
En retour, l'entité cliente A 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 Ξncryption Standard ») . L'entité A renvoie alors à l'entité d'authentification B la valeur C(KA, aléa), où C est l'algorithme cryptographique précédemment cité prenant comme opérandes les valeurs KA et aléa . L'entité B effectue de son côté le même calcul en utilisant la même 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 l'authentification, signifiant ainsi que l'entité A a réussi à s'authentifier.
La validation de l'authentification se traduit par exemple par l'attribution par l'entité d'authentification à l'entité cliente A qui a été authentifiée avec succès, des droits d'accès aux ressources demandées.
De telles méthodes d'authentification à clé secrète sont largement répandues dans les réseaux de télécommunication, 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 l'
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'authentifiant.
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é cliente 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, c'est-à-dire en faisant rejouer authentification à l'entité cliente pour ces valeurs l'l'
déjà fournies. Ainsi, une entité qui signe des aléas pour s'authentifier peut être caractérisée par sa réponse pour une valeur 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 entités distinctes ou la même entité qui se sont authentifiées .
Un algorithme à clé publique peut également être mis en œuvre dans le processus d'authentification tel qu'il a été décrit plus haut en référence à la figure 1. L'entité A signe alors l'aléa reçu de l'entité d'authentification B à l'aide de sa clé privée dont elle est seule à disposer, et l'entité B vérifie l'exactitude du calcul, pour s'assurer qu'elle est bien en présence de entité se réclamant de identité de A, en réalisant l'opération inverse grâce à la clé publique de A PA/ dont elle dispose.
Cependant, cette méthode d'authentification, basée sur un algorithme asymétrique, présente exactement les mêmes inconvénients que la version symétrique.
La présente invention a pour but de pallier aux différents inconvénients précités en proposant un procédé d'authentification utilisant un algorithme de chiffrement asymétrique, dans lequel notamment, 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 l'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 disposant d'un couple clé privée et clé publique pour la mise en œuvre d'un algorithme de chiffrement et de déchiffrement à clé publique, respectivement côté entité cliente et côté entité d'authentification, ledit procédé comprenant, côté entité cliente, des étapes de : génération d'un cryptogramme obtenu par chiffrement d'un message d'authentification comprenant une donnée d'identification propre à ladite entité, une donnée de secret associée et une valeur de compteur d'authentification, prévue pour garantir que ladite authentification n'est pas rejouée,
- envoi du cryptogramme ainsi obtenu vers l'entité d'authentification et, côté entité d'authentification, des étapes de : déchiffrement dudit cryptogramme reçu, et
- à partir d'une base de données mémorisant, pour chaque entité cliente susceptible d'être authentifiée, un enregistrement comprenant au moins la donnée d'identification de ladite entité cliente, détermination de l'enregistrement de ladite base correspondant à la donnée d'identification déchiffrée, et vérification de la correspondance entre la donnée de secret déchiffrée et la donnée de secret de ladite entité cliente, obtenue à partir dudit enregistrement.
De préférence, pour chaque entité cliente susceptible d'être authentifiée, l'enregistrement correspondant de la base de données comprend en outre la donnée de secret de ladite entité cliente. Selon une variante, l'obtention de la donnée de secret de ladite entité cliente à partir dudit enregistrement, consiste à appliquer une fonction de type MAC cryptographique prenant comme opérande une clé de chiffrement mémorisée côté entité d'authentification et la donnée d'identification dudit enregistrement.
Selon une autre variante, pour chaque entité cliente susceptible d'être authentifiée, l'enregistrement correspondant de la base de données comprend en outre une image de la donnée de secret de ladite entité cliente, obtenue par l'application d'une fonction cryptographique à sens unique prenant comme opérande ladite donnée de secret de ladite entité cliente, l'étape de vérification de la correspondance entre la donnée de secret déchiffrée et la donnée de secret de ladite entité cliente, obtenue à partir dudit enregistrement, étant remplacée par une étape consistant à vérifier la correspondance de l'image de ladite donnée de secret déchiffrée calculée à partir de ladite fonction à sens unique avec l'image de la donnée de secret dudit enregistrement.
Selon un premier mode de réalisation, préalablement a l'étape de chiffrement du message d'authentification effectuée côté entité cliente, les étapes suivantes sont mises en oeuvre :
- envoi de ladite entité d'authentification vers ladite entité cliente, de la valeur de compteur d'authentification correspondant à une valeur courante de compteur mémorisée côté entité d'authentification, - vérification, côté entité cliente, que la valeur de compteur d'authentification reçue est strictement supérieure à une valeur de compteur mémorisée côté entité cliente, l'étape de chiffrement côté entité cliente étant suivie d'une mise à jour de ladite valeur de compteur mémorisée côté entité cliente avec ladite valeur de compteur d'authentification reçue, ladite valeur de compteur mémorisée côté entité d'authentification étant incrémentée suite à l'étape de vérification mise en œuvre côté entité d'authentification. De préférence, l'étape de vérification côté entité d'authentification, consiste en outre à vérifier la correspondance entre la valeur de compteur d'authentification déchiffrée et la valeur courante de compteur mémorisée côté entité d'authentification. De préférence, la valeur de compteur mémorisée côté entité d'authentification est incrémentée d'une valeur constante.
8Selon une variante, la valeur de compteur de compteur mémorisée côté entité d'authentification est incrémentée d'une valeur aléatoire.
De préférence, l'envoi de l'entité d'authentification vers l'entité cliente de la valeur de compteur d'authentification est effectué en réponse à l'envoi d'une demande d'authentification anonyme de ladite entité cliente vers ladite entité d'authentification.
Selon un second mode de réalisation, la valeur de compteur d'authentification correspond à une valeur courante de compteur mémorisée côté entité cliente, chaque enregistrement de la base de données comprend en outre, une valeur de compteur mémorisée côté entité d'authentification propre à l'entité cliente, ledit procédé comprenant, côté entité cliente, suite à l'étape de chiffrement du message d'authentification :
- une étape d'incrémentation de ladite valeur de compteur mémorisée côté entité cliente, et, côté entité d'authentification : suite à l'étape de détermination de l'enregistrement de ladite base de données correspondant à la donnée d'identification déchiffrée, une étape de vérification que la valeur de compteur d'authentification déchiffrée est strictement supérieure à la valeur de compteur dudit enregistrement propre à l'entité cliente identifiée, et suite à l'étape de vérification de la correspondance entre la donnée de secret déchiffrée et la donnée de secret obtenue à partir dudit enregistrement, une étape de mise à jour de ladite valeur de compteur dudit enregistrement propre à l'entité cliente identifiée avec ladite valeur de compteur d'authentification déchiffrée.
Avantageusement, les valeurs de compteur correspondent à des valeurs d'horloges implémentées côté entité cliente et côté entité d'authentification.
L'invention concerne également un circuit intégré comportant des moyens de calcul et de stockage pour la mise en œuvre du procédé selon l'invention.
Avantageusement, le dispositif comprend une carte à puce avec ou sans contact.
L'invention concerne aussi une entité d'authentification d'au moins une entité cliente, caractérisée en ce qu'elle comprend un lecteur de carte à puce avec ou sans contact doté de moyens pour la mise en œuvre du procédé selon l'invention.
L'invention concerne encore un programme enregistré sur un support de données et comprenant des instructions pour commander l'exécution du procédé selon l'invention par un système informatique.
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 l'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.
Egalement, la mise en œuvre d'un compteur d'authentification se synchronisant à chaque authentification côté entité cliente et côté entité d'authentification, assure d'une part, l'impossibilité pour toute autre entité que l'entité d'authentification, de reconnaître l'entité cliente par l'observation de son comportement, en faisant en sorte qu'une entité cliente refuse de s'authentifier en présence d'une question qui lui a déjà été soumise et, d'autre part, assure l'impossibilité de tricher vis-à- vis de l'entité d'authentification en rejouant une précédente authentification valide. Ainsi, un tiers malveillant est incapable de distinguer des entités clientes. 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. Ces avantages, ainsi que 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 ou publique 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 un premier mode de réalisation ; la figure 3 est un schéma illustrant les principales étapes du procédé d'authentification selon un second mode de réalisation de l'invention
Le procédé d'authentification selon l'invention, garantissant l'anonymat de l'entité s'authentifiant, est donc basé sur l'utilisation d'un algorithme à clé publique. Un tel algorithme, dit asymétrique, se fonde sur un couple de clés complémentaires propre à l'entité d'authentification B : une clé publique PB et une clé privée SB. La clé publique est divulguée et sert de clé de chiffrement, tandis que la clé privée n'est connue que de son propriétaire, à savoir l'entité d'authentification B et sert à déchiffrer le message chiffré par la clé publique. Les deux clés sont liées par une fonction à sens unique noté ASYM sur les figures, spécifique de chaque algorithme, oùY=ASYM(PB,X)<≠>X=ASYM(SB,Y)
L'entité A qui veut prouver son identité, contient une donnée d'identification idA qui lui est propre, une donnée de secret KA associée, un moyen de mémorisation d'une valeur de compteur notée CPTA à la figure 2 et CA à la figure 3, la clé publique PB de l'entité d'authentification B, ainsi que l'algorithme de chiffrement à clé publique noté ASYM, partagée également par l'entité d'authentification B, et qui est prévue pour s'appliquer avec les deux opérandes suivants : la clé publique PB et un message d'authentification devant être chiffré et qui sera décrit plus en détail ci-après.
L'entité d'authentification B, qui vérifie les identités, contient quant à elle une base de données BD mémorisant, pour chaque entité cliente Ai susceptible d'être authentifiée par l'entité d'authentification B, un enregistrement comprenant au moins la donnée d'identification idAi. Selon un mode de réalisation préféré, chaque enregistrement de la base de données BD comprend en outre la donnée de secret KAi associée à l'entité cliente Ai. L'entité B dispose donc selon ce mode de réalisation préféré, des données de secret de tous les utilisateurs du système, stockées dans la base de données BD avec la donnée d'identification correspondante. On verra plus loin que, selon une variante, la base de données BD peut stocker uniquement les données d'identification idAi propre à chaque entité cliente susceptible d'être authentifiée.
L'entité d'authentification B comprend également la clé privée SB correspondant à PB et l'algorithme de déchiffrement à clé publique ASYM, qui est prévue pour s'appliquer avec les deux opérandes suivants : la clé privée SB et le message chiffré reçu, de sorte à récupérer le message en clair. L'entité d'authentification B comprend enfin des moyens de mémorisation d'au moins une valeur de compteur, notée respectivement CB et CBAi aux figures 2 et 3.
Le déroulement du processus d'authentification anonyme selon un premier mode de réalisation de l'invention est le suivant, en référence à la figure 2. Selon ce mode de réalisation, la valeur de compteur CPTA mémorisée côté entité cliente est initialisée à 0 et la valeur de compteur d'authentification CB, côté entité d'authentification, est initialisée à 1.
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, par exemple sous la forme du message « DemandeAuthentification ». En réponse, dans une deuxième étape, l'entité d'authentification B envoie vers l'entité cliente A une valeur de compteur d'authentification CB correspondant à la valeur courante de compteur mémorisée côté entité d'authentification. L'envoie de la valeur de compteur d'authentification CB pourrait néanmoins être effectué l'
de manière spontanée vers l'entité cliente A sans qu'il soit nécessaire de mettre en œuvre la première étape.
Dans une troisième étape, l'entité cliente A compare la valeur de compteur d'authentification CB reçue avec la valeur de compteur CPTA mémorisée par l'entité cliente A. A ce stade, deux possibilités s'offrent à l'entité cliente A :
Soit CPTA > CB, alors l'entité cliente A ne fait plus rien car cette situation signifie qu'une entité essaye de faire rejouer une authentification à l'entité cliente A. Or, selon une caractéristique de l'invention, pour ne pas être reconnaissable par son comportement, une entité cliente ne réalise jamais deux fois un processus d'authentification avec les mêmes données d'entrée. Cette situation met donc fin au processus d'authentification et l'entité cliente refuse de répondre au test de l'entité d'authentification.
Soit CPTA < CB, alors l'entité cliente A peut avoir confiance en l'entité d'authentification B car la valeur de compteur d'authentification reçue CB étant supérieure strictement à la valeur de compteur CPTA mémorisée par A, cela signifie que cette valeur de compteur CB ne lui a encore jamais été présentée. Le processus passe alors à l'étape suivante. Dans une quatrième étape, une fois le test sur CB ayant garanti que authentification n'est pas rejouée, l'entité cliente A chiffre un message d'authentification R qui lui est propre, constitué par les données idA, KA et CB concaténées : R=idA\KA\CB . Pour ce faire, l'entité cliente A calcule : R'=ASYM(PB,R) , et le cryptogramme R' ainsi obtenu est transmis de l'entité cliente A vers l'entité d'authentification B. L'entité cliente A met alors à jour sa valeur de compteur mémorisée CPTA avec la dernière valeur de compteur licite qui lui a été transmis par l'entité d'authentification B, à savoir CB.
Dans une cinquième étape, l'entité d'authentification B déchiffre le cryptogramme R' reçu et récupère le message d'authentification en clair R, par application de l'algorithme de déchiffrement ASYM avec la clé privée SB sur le cryptogramme R' : R=ASYM(SB,R') . On note alors le message
Figure imgf000017_0001
, K'A étant la donnée de secret déchiffré et CB' étant la valeur de compteur d'authentification déchiffré.
A partir de la donnée d'identification idA déchiffrée, l'entité B détermine l'enregistrement correspondant dans sa base de données BD. L'entité B doit alors vérifier que la donnée de secret déchiffré K'A à partir du cryptogramme reçu, correspond effectivement à la donnée de secret KA associée à l'entité cliente A. Pour effectuer cette vérification, la donnée de secret KA de l'entité cliente A est obtenue côté entité d'authentification, à partir de l'enregistrement précédemment déterminé.
Selon le mode de réalisation préféré, la base de données BD est prévue pour mémoriser les données de secret KAi associées respectivement aux données d'identification idAi des entités clientes susceptibles d'être authentifiées. Aussi, la donnée de secret KA associée à l'entité cliente A est mémorisée dans l'enregistrement qui a été déterminé à partir de la donnée d'identification idA déchiffré par B. L'entité B peut ainsi retrouver, à partir de l'enregistrement correspondant à la donnée idA déchiffrée, la donnée de secret KA associée.
L'entité B vérifie alors que la donnée de secret déchiffré K'A à partir du cryptogramme reçu, correspond à la donnée de secret KA identifiée dans la base de données, soit K'A = KA.
Dans le cas où les enregistrements de la base de données côté entité d'authentification, comprennent uniquement les données d'identification idAi des entités clientes Ai, la donnée de secret KA associée à l'entité cliente A identifiée au cours de d'authentification est alors déterminée de façon dynamique côté entité d'authentification. Cette détermination peut découler d'un calcul de diversification mis en œuvre par l'entité d'authentification à partir de l'enregistrement de la base de données qui a été déterminé et qui comprend la donnée d'identification idA de l'entité cliente A. Par exemple, la donnée de secret KA, correspondant à l'entité cliente concernée, est le résultat du calcul de diversification suivant : KA= MAC(M, idA), où MAC est un MAC cryptographique utilisant une clé de chiffrement mère M et opérant sur la donnée d'identification idA. La clé M doit alors être mémorisée côté entité d'authentification. Les étapes du procédé demeurent inchangées sauf l'étape de l'
vérification K'A=KA précédemment décrite, qui devient K'A=MAC (M, idA) .
L'entité d'authentification B vérifie en outre que la valeur de compteur d'authentification déchiffrée, notée CB', correspond bien à la valeur courante CB de son compteur d'authentification, soit CB'=CB, de sorte à s'assurer qu'un attaquant n'essaye pas de s'authentifier en se faisant passer pour A en fournissant un cryptogramme R' qui aurait été observé et correspondant à une valeur de compteur d'authentification précédemment soumise à l'entité cliente lors d'une authentification antérieure.
Si les tests sont vérifiés, l'entité cliente A est authentifiée, et l'entité d'authentification B incrémente sa valeur de compteur CB mémorisée pour un prochain processus d'authentification.
Sinon, l'entité A n'est pas authentifiée. De préférence, la valeur de compteur d'authentification CB mémorisée côté entité d'authentification est incrémentée d'une valeur constante. Toutefois, le fait d'augmenter la valeur de compteur d'un pas constant permet de prévoir les valeurs de compteur d'authentification qui seront utilisées lors des authentifications à venir. De ce fait, un attaquant peut demander plusieurs valeurs R' à une entité A pour plusieurs valeurs consécutives 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 entité cliente A. Ainsi, l'attaquant pourrait 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 la valeur de compteur CB mémorisée côté entité d'authentification d'une valeur aléatoire à chaque authentification, de sorte à ne plus utiliser des valeurs successives de CB.
Une autre parade consiste côté entité cliente A, non plus à chiffrer un message d'authentification R basé sur une simple valeur de compteur CB, mais sur 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. 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 de compteur mémorisée côté entité B. En mettant à jour sa valeur de compteur mémorisée CPTA avec cette grande valeur CB 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 CPTA, à cause du test de la troisième étape. De plus, si la machine l'
malveillante fournit à l'entité A une valeur de compteur maximale, cette dernière, en mettant à jour sa valeur de compteur mémorisée CPTA à 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 CPTA mémorisée par l'entité cliente A.
Dans le cas où CPTA > 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 CPTA est plus grande que la valeur CB et lui renvoie CPTA ;
-l'entité B envoie à A une valeur de compteur
CBtemporaire > CPTA ; puis, les autres étapes du procédé d'authentification sont mises en œuvre sur la base de cette valeur de
CBtemporaire et, si authentification de l'entité A réussit avec CBtemporaire, alors l'entité B met à jour sa valeur courante de compteur d'authentification CB mémorisée avec la valeur de compteur d'authentification CBtemporaire. Enfin, la valeur de compteur d'authentification CB mémorisée côté entité B 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 sa valeur de compteur mémorisée. Ce processus permet également à l'entité cliente A de synchroniser la valeur de 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 de compteur mémorisée par l'entité cliente CPTA 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 CPTA < 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 CPTA mémorisée par l'entité cliente est inférieure ou égale à une valeur prédéterminée Δ, soit CB - CPTA < Δ L'entité A n'accepte de poursuivre l'authentification 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.
En référence à la figure 3, un second mode de réalisation de l'invention est décrit, pour la mise en œuvre d'une version mono-directionnelle du procédé d'authentification, c'est-à-dire ne nécessitant que des échanges dans le sens de l'entité cliente vers l'entité d'authentification.
Selon ce mode de réalisation, des compteurs individuels sont utilisés," côté entité d'authentification, pour chaque entité cliente. Ainsi, la base de données BD, côté entité d'authentification, comprend en outre, pour chaque entité cliente Ai susceptible d'être authentifiée, une valeur de compteur CBAi mémorisée propre à chaque entité cliente Ai. La base de données BD de l'entité d'authentification B contient donc des enregistrements du type suivant, comprenant au moins :
[donnée d'identification de l'entité cliente Ai : idAi ; valeur de compteur pour cette entité cliente:
CBAi] ;
Ou comprenant, selon le mode de réalisation préféré :
[donnée d'identification de l'entité cliente Ai : idAi ; donnée secrète associée à cette entité cliente :
KAI ; valeur de compteur pour cette entité cliente:
CBAi] .
Le déroulement du processus d'authentification anonyme selon le mode de réalisation mono-directionnel de l'invention est donc le suivant, en référence à la figure 3. Selon ce mode de réalisation, la valeur de compteur d'authentification correspond à la valeur courante de compteur CA mémorisée côté entité cliente. La valeur de compteur CA mémorisée côté entité cliente est initialisée à 1 et la valeur de compteur, notée CBA, correspondant à cette entité cliente, mémorisée côté entité d'authentification, est initialisée à 0.
Dans une première étape, l'entité cliente A chiffre un message d'authentification R qui lui est propre, constitué par les données idA, KA et CA concaténées : R=idAKÂ\CA . Pour ce faire, l'entité cliente A calcule : R'=ASYM(PB,R) , et le cryptogramme R' ainsi obtenu est transmis de l'entité cliente A vers l'entité d'authentification B. L'entité cliente A incrémente alors sa valeur de compteur d'authentification CA mémorisée.
Dans une deuxième étape, l'entité d'authentification B déchiffre le cryptogramme R' reçu et récupère le message d'authentification en clair R, par application de l'algorithme de déchiffrement ASYM avec la clé privée SB sur le cryptogramme R' : R=ASYM(SB,R!) . On note alors le message déchiffréR=idA\KΑ\CA
A partir de la donnée d'identification idA déchiffré, l'entité B, connaissant maintenant l'identité de A, détermine l'enregistrement correspondant et récupère dans sa base de données BD les éléments KA et CBA associés à l'entité cliente identifiée. L'entité B compare alors la valeur déchiffrée de compteur d'authentification CA avec celle CBA associée à l'entité cliente identifiée dans sa base de données.
Soit CA≤CBA, l'entité B refuse alors l'authentification car il s'agit d'un rejeu. L'entité cliente A n'est pas authentifiée et le processus d'authentification prend fin.
Soit CA>CBA, alors, cela signifie que cette valeur de compteur d'authentification CA n'a encore jamais été présentée à l'entité d'authentification B et le processus passe à l'étape suivante.
L'entité d'authentification B vérifie alors que la donnée de secret déchiffré K'A à partir du cryptogramme reçu, correspond effectivement à la donnée de secret KA associée à l'entité cliente A, laquelle donnée de secret KA est obtenue à partir de l'enregistrement de la base de données, de la même façon qu'expliqué précédemment en référence au mode de réalisation bi¬ directionnel de la figure 2, suivant que l'enregistrement concerné de la base de données mémorise ou non la donnée de secret KA associée à idA. Ainsi, l'entité B vérifie au cours de cette étape si K'A = KA ou si K'A=MAC(M,idA) .
Si la vérification est réussie, l'entité cliente A est authentifiée et l'entité d'authentification B met à jour la valeur de compteur CBA propre à l'entité cliente A côté entité d'authentification, avec la dernière valeur de compteur d'authentification CA licite qui lui a été transmise sous forme chiffrée par l'entité cliente A.
Sinon, l'entité cliente A n'est pas authentifiée. Ce mode de réalisation mono-directionnel permet avantageusement d'éviter l'envoi d'une valeur de compteur d'authentification de l'entité d'authentification B cers l'entité cliente A pour initier le processus. Seuls des messages chiffrés transitent de l'entité cliente vers l'entité d'authentification B. On évite ainsi les attaques par saut de compteur telles que décrites en référence au premier mode de réalisation. Selon un exemple, les valeurs de compteur d'authentification utilisées dans le premier ou le second mode de réalisation peuvent être des nombres binaires codés sur au moins 128 bits.
Dans le calcul de R'=ASYM(PB,R)mis en œuvre côté entité cliente selon le premier ou le second mode de réalisation, on pourra par exemple utiliser l'algorithme asymétrique de type RSA, avec un exposant de chiffrement de valeur faible (3, par exemple) . Le calcul revient alors à réaliser deux multiplications modulo, ce qui peut aisément être effectué en un temps très court avec une carte à micro-processeur sans crypto-processeur.
L'optimisation suivante peut être apportée au procédé selon l'invention, s'appliquant indifféremment au mode de réalisation bi-directionnel ou mono¬ directionnel. Ainsi, pour éviter de stocker directement des données de secret KAi dans la base de données BD de l'entité B, il est possible de stocker à la place l'image de KAi, notée UAi, par l'application d'une fonction cryptographique à sens unique U : UAi= U(KAi) . Le test K'A=KA devient alors UA=U(K'A) . Pour la fonction U, on peut utiliser une fonction de condensation (MD5, SHA...) ou alors une fonction de chiffrement Sym basé sur un algorithme symétrique (DES, AES...) prenant comme opérande la donnée secrète KA et une constante, tel que U(KA)=Sym (KA, constante) .
D'autres optimisations peuvent encore être apportées, s'appliquant cette fois uniquement au mode de réalisation mono-directionnel. Ces optimisations ont pour but de réaliser une authentification décentralisée de l'utilisateur qui pourra ainsi s'authentifier auprès de plusieurs entités d'authentification sans que celles-ci aient besoin de communiquer ou de partager des données et notamment, les valeurs de compteur d'authentification CBAi propres aux différentes entités clientes Ai mémorisées côté entité d'authentification.
Pour ce faire, une optimisation consiste à implémenter une horloge côté entité cliente et côté entité d'authentification pour fixer les valeurs de compteur d'authentification CA et CBA, respectivement côté entité cliente et côté entité d'authentification. Ainsi, les valeurs de compteur d'authentification CA et CBA peuvent être par exemple le temps écoulé en seconde depuis une date fixée. Ainsi, la valeur de compteur d'authentification CA est remplacée par une valeur d'horloge HA implémentée côté entité cliente et la valeur de compteur CBA est remplacée par une valeur d'horloge HB implémentée côté entité d'authentification. Toutefois, il faut tenir compte du fait que l'horloge côté entité cliente est susceptible de l'
retarder, ce qui risque de fausser les étapes de test mis en œuvre au cours de la deuxième étape par l'entité d'authentification et de conduire l'entité d'authentification à considérer une tentative d'authentification licite comme une tentative de rejeu d'une authentification. Il est donc nécessaire de prévoir une marge d'erreur D correspondant à un majorant du décalage de toutes les horloges implémentées côté entités clientes et entités d'authentification. Le test CA>CBA est alors remplacé par le test HA > HB - D, ce qui autorise authentification si les valeurs d'horloge côté entité cliente et côté entité d'authentification sont décalées de moins de D secondes. Un problème incontournable est qu'un attaquant peut éventuellement rejouer une authentification auprès d'une entité d'authentification pendant cet intervalle de temps de D secondes. Il faut donc choisir D le plus petit possible tout en restant compatible avec la précision des horloges mises en œuvre.
Dans le cas où l'entité cliente ne dispose pas d'horloge embarquée, il est possible néanmoins de mettre en œuvre la variante proposée ci-dessus en utilisant une horloge externe HA, qui pourra résider à l'extérieur de l'entité cliente. Il pourra s'agir par exemple de l'horloge d'un ordinateur de type PC. Dans ce cas, l'entité cliente A conserve une valeur de compteur CA mémorisée en interne dont la valeur correspond à la dernière valeur d'horloge soumise. Pour s'authentifier, l'entité cliente A lit tout d'abord la valeur d'horloge HA du PC depuis l'extérieur et, si le test suivant est vérifiée : HA > CA, délivre le cryptogramme
Figure imgf000029_0001
vers l'entité d'authentification et met à jour CA : CA=HA. Ce test vise à se prémunir contre un attaquant qui chercherait à authentifier A par l'observation de son comportement en lui soumettant successivement des mêmes valeurs d'horloge HA.
Les étapes du procédé selon le premier ou le second mode de réalisation en référence à la figure 2 ou 3, peuvent être implémentées, côté entité cliente, sur tout dispositif physique comprenant un circuit intégré doté de moyens de calcul et de stockage. Il peut s'agir par exemple d'une carte à puce, avec ou sans contact. Selon cet exemple, l'entité d'authentification se présente alors sous la forme d'un lecteur de carte à puce avec ou sans contact.
De manière générale, les étapes de procédé peuvent se présenter sous la forme d'un programme, enregistré sur un support de données et comprenant des instructions pour commander l'exécution du procédé tel qu'il vient d'être décrit par un système informatique.
Ainsi, le programme pour commander l'exécution du procédé selon l'invention peut être enregistré dans ou transmis par un support de données comprenant des instructions pour commander l'exécution du procédé précédemment décrit par un système informatique. Le support de données peut être un support matériel de stockage, par exemple un CD-ROM, une disquette magnétique ou un disque dur, ou bien un support transmissible tel qu'un signal électrique, optique ou radio.

Claims

REVENDICATIONS
1. Procédé d'authentification d'au moins une entité cliente (A) par une entité d'authentification
(B) disposant d'un couple clé privée (SB) et clé publique (PB) pour la mise en œuvre d'un algorithme de chiffrement (ASYM(PB,R)) et de déchiffrement (ASYM(SB,
R' ) ) à clé publique, respectivement côté entité cliente
(A) et côté entité d'authentification (B), ledit procédé comprenant, côté entité cliente (A) , des étapes de : génération d'un cryptogramme (R' ) obtenu par chiffrement d'un message d'authentification (R) comprenant une donnée d'identification (idA) propre à ladite entité, une donnée de secret (KA) associée et une valeur de compteur d'authentification (CA, CB), prévue pour garantir que ladite authentification n'est pas rejouée, envoi du cryptogramme (R' ) ainsi obtenu vers l'entité d'authentification (B) et, côté entité d'authentification (B), des étapes de
déchiffrement dudit cryptogramme (R') reçu, et - à partir d'une base de données (BD) mémorisant, pour chaque entité cliente (Ai) susceptible d'être authentifiée, un enregistrement comprenant au moins la donnée d'identification (idAi) de ladite entité cliente (Ai), détermination de l'enregistrement de ladite base correspondant à la donnée d'identification (idA) déchiffrée, et vérification de la correspondance entre la donnée de secret déchiffrée (KΑ) et la donnée de secret de ladite entité cliente (KA) , obtenue à partir dudit enregistrement.
2. Procédé selon la revendication 1, caractérisé en ce que, pour chaque entité cliente (Ai) susceptible d'être authentifiée, l'enregistrement correspondant de la base de données comprend en outre la donnée de secret (KAi) de ladite entité cliente.
3. Procédé selon la revendication 1, caractérisé en ce que l'obtention de la donnée de secret (KA) de ladite entité cliente à partir dudit enregistrement, consiste à appliquer une fonction de type MAC cryptographique prenant comme opérande une clé de chiffrement mémorisée côté entité d'authentification et la donnée d'identification (idA) dudit enregistrement.
4. Procédé selon la revendication 1, caractérisé en ce que, pour chaque entité cliente (Ai) susceptible d'être authentifiée, l'enregistrement correspondant de la base de données comprend en outre une image de la donnée de secret (KAi) de ladite entité cliente, obtenue par l'application d'une fonction cryptographique à sens unique prenant comme opérande ladite donnée de secret (KAi) de ladite entité cliente, l'étape de vérification de la correspondance entre la donnée de secret déchiffrée (KΑ) et la donnée de secret de ladite entité cliente, obtenue à partir dudit enregistrement, étant remplacée par une étape consistant à vérifier la correspondance de l'image de ladite donnée de secret déchiffrée calculée à partir de ladite fonction à sens unique avec l'image de la donnée de secret dudit enregistrement.
5. Procédé selon l'une quelconque des revendications 1 à 4, comprenant, préalablement à l'étape de chiffrement du message d'authentification (R) effectuée côté entité cliente (A) , des étapes de :
- envoi de ladite entité d'authentification (B) vers ladite entité cliente (A) , de la valeur de compteur d'authentification (CB) correspondant à une valeur courante de compteur mémorisée côté entité d'authentification,
- vérification, côté entité cliente (A) , que la valeur de compteur d'authentification reçue (CB) est strictement supérieure à une valeur de compteur (CPTA) mémorisée côté entité cliente, l'étape de chiffrement côté entité cliente étant suivie d'une mise à jour de ladite valeur de compteur (CPTA) mémorisée côté entité cliente avec ladite valeur de compteur d'authentification reçue (CB) , ladite valeur de compteur mémorisée côté entité d'authentification (B) étant incrémentée suite à l'étape de vérification mise en œuvre côté entité d'authentification (B) .
6. Procédé selon la revendication 5, caractérisé en ce que l'étape de vérification côté entité d'authentification (B), consiste en outre à vérifier la correspondance entre la valeur de compteur d'authentification déchiffrée (CB') et la valeur courante (CB) de compteur mémorisée côté entité d'authentification.
7. Procédé selon la revendication 5 ou 6, caractérisé en ce que la valeur de compteur mémorisée côté entité d'authentification (B) est incrémentée d'une valeur constante.
8. Procédé selon la revendication 5 ou 6, caractérisé en ce que la valeur de compteur de compteur mémorisée côté entité d'authentification (B) est incrémentée d'une valeur aléatoire.
9. Procédé selon l'une quelconque des revendications 5 à 8, caractérisé en ce que l'envoi de l'entité d'authentification (B) vers l'entité cliente (A) de la valeur de compteur d'authentification (CB) est effectué en réponse à l'envoi d'une demande d'authentification anonyme (DemandeAuthentification) de ladite entité cliente (A) vers ladite entité d'authentification (B) .
10. Procédé selon l'une quelconque des revendications 1 à 4, caractérisé en ce que la valeur de compteur d'authentification (CA) correspond à une valeur courante de compteur mémorisée côté entité cliente (A) , chaque enregistrement de la base de données (BD) comprend en outre, une valeur de compteur (CBAi) mémorisée côté entité d'authentification propre à l'entité cliente (Ai), ledit procédé comprenant, côté l'
entité cliente, suite à l'étape de chiffrement du message d'authentification (R) :
- une étape d'incrémentation de ladite valeur de compteur mémorisée côté entité cliente, et, côté entité d'authentification (B) : suite à l'étape de détermination de l'enregistrement de ladite base de données correspondant à la donnée d'identification (idA) déchiffrée, une étape de vérification que la valeur de compteur d'authentification (CA) déchiffrée est strictement supérieure à la valeur de compteur (CBA) dudit enregistrement propre à l'entité cliente (A) identifiée, et suite à l'étape de vérification de la correspondance entre la donnée de secret déchiffrée (K'A) et la donnée de secret (KA) obtenue à partir dudit enregistrement, une étape de mise à jour de ladite valeur de compteur (CBA) dudit enregistrement propre à l'entité cliente identifiée (A) avec ladite valeur de compteur d'authentification (CA) déchiffrée.
11. Procédé selon la revendication 10, caractérisé en ce que les valeurs de compteur correspondent à des valeurs d'horloges implémentées côté entité cliente et côté entité d'authentification.
12. Dispositif pour authentification, caractérisé en ce qu'il comprend un circuit intégré comportant des moyens de calcul et de stockage pour la mise en œuvre du procédé selon l'une quelconque des revendications 1 à 11.
13. Dispositif selon la revendication 12, caractérisé en ce qu'il comprend une carte à puce avec ou sans contact.
14. Entité d'authentification (B) d'au moins une entité cliente (A), caractérisée en ce qu'elle comprend un lecteur de carte à puce avec ou sans contact doté de moyens pour la mise en œuvre du procédé selon l'une quelconque des revendications 1 à 11.
15. Programme enregistré sur un support de données et comprenant des instructions pour commander l'exécution du procédé selon l'une quelconque des revendications 1 à 11 par un système informatique.
PCT/FR2005/001868 2004-08-03 2005-07-20 Procede d'authentification anonyme base sur un algorithme cryptographique de type asymetrique WO2006024732A1 (fr)

Priority Applications (2)

Application Number Priority Date Filing Date Title
US11/659,296 US20090019282A1 (en) 2004-08-03 2005-07-20 Anonymous authentication method based on an asymmetic cryptographic algorithm
EP05793306A EP1774699A1 (fr) 2004-08-03 2005-07-20 Procede d'authentification anonyme base sur un algorithme cryptographique de type asymetrique

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
FR0408572 2004-08-03
FR0408572A FR2874144A1 (fr) 2004-08-03 2004-08-03 Procede d'authentification anonyme base sur un algorithme cryptographique de type asymetrique

Publications (1)

Publication Number Publication Date
WO2006024732A1 true WO2006024732A1 (fr) 2006-03-09

Family

ID=34950312

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/FR2005/001868 WO2006024732A1 (fr) 2004-08-03 2005-07-20 Procede d'authentification anonyme base sur un algorithme cryptographique de type asymetrique

Country Status (4)

Country Link
US (1) US20090019282A1 (fr)
EP (1) EP1774699A1 (fr)
FR (1) FR2874144A1 (fr)
WO (1) WO2006024732A1 (fr)

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN108599952A (zh) * 2017-12-29 2018-09-28 重庆小犀智能科技有限公司 一种基于区块链的通信方法

Families Citing this family (11)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
EP2027664A4 (fr) 2006-06-09 2016-08-17 Symantec Internat Procédé et appareil permettant d'offrir une authentification et une confidentialité sur des dispositifs de faible complexité
CA2700864C (fr) * 2007-10-26 2017-06-13 Research In Motion Limited Procede, appareil et systeme de navigation anonyme
US20100199323A1 (en) * 2009-02-04 2010-08-05 Greg Salyards System for Dynamically Turning On or Off Log On Methods Used for Access to PC or Network Based Systems
US8621212B2 (en) * 2009-12-22 2013-12-31 Infineon Technologies Ag Systems and methods for cryptographically enhanced automatic blacklist management and enforcement
US8473414B2 (en) * 2010-04-09 2013-06-25 Visa International Service Association System and method including chip-based device processing for transaction
US8630411B2 (en) * 2011-02-17 2014-01-14 Infineon Technologies Ag Systems and methods for device and data authentication
US8707046B2 (en) * 2011-05-03 2014-04-22 Intel Corporation Method of anonymous entity authentication using group-based anonymous signatures
IL213497A0 (en) 2011-06-12 2011-08-31 Eliphaz Hibshoosh Light public key cryptography
DE102013205166A1 (de) * 2013-03-22 2014-09-25 Robert Bosch Gmbh Verfahren zum Erzeugen einer Einwegfunktion
US10797868B2 (en) * 2018-05-31 2020-10-06 Irdeto B.V. Shared secret establishment
JP7105894B2 (ja) * 2018-08-28 2022-07-25 アルプスアルパイン株式会社 相互認証方法及び通信システム

Citations (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US5402490A (en) * 1992-09-01 1995-03-28 Motorola, Inc. Process for improving public key authentication
WO2001061918A1 (fr) * 2000-02-15 2001-08-23 Silverbrook Research Pty. Ltd. Systeme et protocole de validation

Family Cites Families (10)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US5708710A (en) * 1995-06-23 1998-01-13 Motorola, Inc. Method and apparatus for authentication in a communication system
FR2753857B1 (fr) * 1996-09-25 1998-12-11 Procede et systeme pour securiser les prestations de services diffusees sur un reseau informatique du type internet
FR2753858B1 (fr) * 1996-09-25 1999-03-26 Procede et systeme pour securiser les centres de gestion d'appels telephoniques
US5987493A (en) * 1997-12-05 1999-11-16 Insoft Inc. Method and apparatus determining the load on a server in a network
US6820203B1 (en) * 1999-04-07 2004-11-16 Sony Corporation Security unit for use in memory card
US6519647B1 (en) * 1999-07-23 2003-02-11 Microsoft Corporation Methods and apparatus for synchronizing access control in a web server
US9219708B2 (en) * 2001-03-22 2015-12-22 DialwareInc. Method and system for remotely authenticating identification devices
US7275109B1 (en) * 2002-04-02 2007-09-25 Nortel Networks Limited Network communication authentication
US7373509B2 (en) * 2003-12-31 2008-05-13 Intel Corporation Multi-authentication for a computing device connecting to a network
FR2867930A1 (fr) * 2004-03-16 2005-09-23 France Telecom Procede d'authentification anonyme

Patent Citations (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US5402490A (en) * 1992-09-01 1995-03-28 Motorola, Inc. Process for improving public key authentication
WO2001061918A1 (fr) * 2000-02-15 2001-08-23 Silverbrook Research Pty. Ltd. Systeme et protocole de validation

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN108599952A (zh) * 2017-12-29 2018-09-28 重庆小犀智能科技有限公司 一种基于区块链的通信方法

Also Published As

Publication number Publication date
EP1774699A1 (fr) 2007-04-18
US20090019282A1 (en) 2009-01-15
FR2874144A1 (fr) 2006-02-10

Similar Documents

Publication Publication Date Title
WO2006024732A1 (fr) Procede d&#39;authentification anonyme base sur un algorithme cryptographique de type asymetrique
EP1427231B1 (fr) Procédé d&#39;établissement et de gestion d&#39;un modèle de confiance entre une carte à puce et un terminal radio
EP2884716B1 (fr) Mécanisme d&#39;authentificaiton par jeton
EP2811708B1 (fr) Système et méthode pour l&#39;authentification d&#39;un utilisateur
EP3010177A1 (fr) Procédé d&#39;authentification d&#39;un dispositif client auprès d&#39;un serveur à l&#39;aide d&#39;un élément secret
EP1549011A1 (fr) Procédé et système de communication entre un terminal et au moins un équipment communicant
FR2926938A1 (fr) Procede d&#39;authentification et de signature d&#39;un utilisateur aupres d&#39;un service applicatif, utilisant un telephone mobile comme second facteur en complement et independamment d&#39;un premier facteur
EP1726121A1 (fr) Procede d&#39;authentification anonyme
WO2010046565A2 (fr) Procédé de signature numérique en deux étapes
FR2822002A1 (fr) Authentification cryptographique par modules ephemeres
FR2964812A1 (fr) Procede d&#39;authentification pour l&#39;acces a un site web
WO2007012583A1 (fr) Procede de controle de transactions securisees mettant en oeuvre un dispositif physique unique, dispositif physique, systeme, et programme d&#39;ordinateur correspondants
WO2007045745A1 (fr) Procede et dispositif de creation d&#39;une signature de groupe et procede et dispositif de verification d&#39;une signature de groupe associes
EP3724799A1 (fr) Technique de protection d&#39;une clé cryptographique au moyen d&#39;un mot de passe utilisateur
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
WO2010007267A1 (fr) Procede pour securiser des echanges entre un noeud demandeur et un noeud destinataire
EP2509025A1 (fr) Procédé d&#39;accès à une ressource protégée d&#39;un dispositif personnel sécurisé
EP3965361B1 (fr) Echange de données entre un client et un dispositif distant, par exemple un module sécurisé
WO2003107587A1 (fr) Procede et dispositif d’interface pour echanger de maniere protegee des donnees de contenu en ligne
WO2007051769A1 (fr) Procede de depot securise de donnees numeriques, procede associe de recuperation de donnees numeriques, dispositifs associes pour la mise en œuvre des procedes, et systeme comprenant les dits dispositifs
WO2006035159A1 (fr) Systeme et procede cryptographique a cle publique et serveur de certification, memoires adaptees pour ce systeme
EP2115657A2 (fr) Procede et systeme d&#39;autorisation d&#39;acces a un serveur
WO2017005644A1 (fr) Procédé et système de contrôle d&#39;accès à un service via un média mobile sans intermediaire de confiance
WO2006027430A1 (fr) Procede d’authentification entre entites communiquant entre elles au travers d’un reseau de telecommunications
EP1989819B1 (fr) Procéde de certification de clé publique par un prestataire non accrédité

Legal Events

Date Code Title Description
AK Designated states

Kind code of ref document: A1

Designated state(s): AE AG AL AM AT AU AZ BA BB BG BR BW BY BZ CA CH CN CO CR CU CZ DE DK DM DZ EC EE EG ES FI GB GD GE GH GM HR HU ID IL IN IS JP KE KG KM KP KR KZ LC LK LR LS LT LU LV MA MD MG MK MN MW MX MZ NA NG NI NO NZ OM PG PH PL PT RO RU SC SD SE SG SK SL SM SY TJ TM TN TR TT TZ UA UG US UZ VC VN YU ZA ZM ZW

AL Designated countries for regional patents

Kind code of ref document: A1

Designated state(s): BW GH GM KE LS MW MZ NA SD SL SZ TZ UG ZM ZW AM AZ BY KG KZ MD RU TJ TM AT BE BG CH CY CZ DE DK EE ES FI FR GB GR HU IE IS IT LT LU LV MC NL PL PT RO SE SI SK TR BF BJ CF CG CI CM GA GN GQ GW ML MR NE SN TD TG

121 Ep: the epo has been informed by wipo that ep was designated in this application
WWE Wipo information: entry into national phase

Ref document number: 2005793306

Country of ref document: EP

WWE Wipo information: entry into national phase

Ref document number: 11659296

Country of ref document: US

NENP Non-entry into the national phase

Ref country code: DE

WWP Wipo information: published in national office

Ref document number: 2005793306

Country of ref document: EP

WWW Wipo information: withdrawn in national office

Ref document number: 2005793306

Country of ref document: EP