Brevet FR2874144A1 — publié le 20060210

La présente invention concerne, de façon générale, le domaine de l'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, l'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à 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 l'authentification forte ou par défiré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 Encryption 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 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 l'authentification à l'entité cliente pour ces valeurs 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 oeuvre 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 l'entité se réclamant de l'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 oeuvre 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 à 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 oeuvre 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 oeuvre 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 oeuvre 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 oeuvre 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) a 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é de manière spontanée vers l'entité cliente A sans qu'il soit nécessaire de mettre en oeuvre 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 Dans une quatrième étape, une fois le test sur CB ayant garanti que l'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 = idAIKAICB. 30 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 déchiffréR=idAIK'AICB', 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 30 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 oeuvre 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 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 l'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 oeuvre. 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 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 lavaleur 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 oeuvre: l'entité A signale à l'entité B que sa valeur de 15 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 oeuvre sur la base de cette valeur de CBtemporaire et, si l'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 memorisé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 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 oeuvre 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: 20 idAil; 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: idAil; donnée secrète associée à cette entité cliente: KAi;I valeur de compteur pour cette entité cliente: CBAi]. Le déroulement du processus d'authentification anonyme selon le mode de réalisation mono-directionnel 30 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 à O. 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 = idAIKAICA. 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(PB,R'). On note alors le message déchiffréR = idAIK'AICA 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 oeuvre 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 cryptoprocesseur. 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 2874144 26 retarder, ce qui risque de fausser les étapes de test mis en oeuvre 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 l'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 oeuvre. Dans le cas où l'entité cliente ne dispose pas d'horloge embarquée, il est possible néanmoins de mettre en oeuvre 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 R'=ASYM(PB, idAIKAIHA) 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. 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 oeuvre 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'A) 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'A) 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 oeuvre 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ôte 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é 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 l'authentification, caractérisé en ce qu'il comprend un circuit intégré comportant des moyens de calcul et de stockage pour la mise en oeuvre 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 oeuvre 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.