EP1774699A1 - 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

Info

Publication number
EP1774699A1
EP1774699A1 EP05793306A EP05793306A EP1774699A1 EP 1774699 A1 EP1774699 A1 EP 1774699A1 EP 05793306 A EP05793306 A EP 05793306A EP 05793306 A EP05793306 A EP 05793306A EP 1774699 A1 EP1774699 A1 EP 1774699A1
Authority
EP
European Patent Office
Prior art keywords
authentication
entity
client entity
counter value
client
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Withdrawn
Application number
EP05793306A
Other languages
German (de)
English (en)
Inventor
David Arditti
Olivier Charles
Sébastien NGUYEN NGOC
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Orange SA
Original Assignee
France Telecom SA
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by France Telecom SA filed Critical France Telecom SA
Publication of EP1774699A1 publication Critical patent/EP1774699A1/fr
Withdrawn legal-status Critical Current

Links

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/32—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials
    • H04L9/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

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 , 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 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.
EP05793306A 2004-08-03 2005-07-20 Procede d'authentification anonyme base sur un algorithme cryptographique de type asymetrique Withdrawn EP1774699A1 (fr)

Applications Claiming Priority (2)

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

Publications (1)

Publication Number Publication Date
EP1774699A1 true EP1774699A1 (fr) 2007-04-18

Family

ID=34950312

Family Applications (1)

Application Number Title Priority Date Filing Date
EP05793306A Withdrawn EP1774699A1 (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)

Families Citing this family (11)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
MX2008015210A (es) 2006-06-09 2009-05-28 Verisign Inc Metodo y aparato para proporcionar autentificacion y privacidad con dispositivos de baja complejidad.
EP2206285B1 (fr) * 2007-10-26 2012-03-21 Research In Motion Limited Procédé, appareil et système 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
CN108599952B (zh) * 2017-12-29 2019-01-08 重庆小犀智能科技有限公司 一种基于区块链的通信方法
JP7105894B2 (ja) * 2018-08-28 2022-07-25 アルプスアルパイン株式会社 相互認証方法及び通信システム

Family Cites Families (12)

* 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
US5708710A (en) * 1995-06-23 1998-01-13 Motorola, Inc. Method and apparatus for authentication in a communication system
FR2753858B1 (fr) * 1996-09-25 1999-03-26 Procede et systeme pour securiser les centres de gestion d'appels telephoniques
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
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
US7685423B1 (en) * 2000-02-15 2010-03-23 Silverbrook Research Pty Ltd Validation protocol and system
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

Non-Patent Citations (1)

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

Also Published As

Publication number Publication date
US20090019282A1 (en) 2009-01-15
FR2874144A1 (fr) 2006-02-10
WO2006024732A1 (fr) 2006-03-09

Similar Documents

Publication Publication Date Title
EP1774699A1 (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
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
WO2010046565A2 (fr) Procédé de signature numérique en deux étapes
WO2005101726A1 (fr) Procede d&#39;authentification anonyme
EP2811708A1 (fr) Système et méthode pour l&#39;authentification d&#39;un utilisateur
FR2822002A1 (fr) Authentification cryptographique par modules ephemeres
FR2964812A1 (fr) Procede d&#39;authentification pour l&#39;acces a un site web
EP1911194A1 (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
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
WO2003107587A1 (fr) Procede et dispositif d’interface pour echanger de maniere protegee des donnees de contenu en ligne
EP3724799A1 (fr) Technique de protection d&#39;une clé cryptographique au moyen d&#39;un mot de passe utilisateur
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
EP3965361A1 (fr) Echange de données entre un client et un dispositif distant, par exemple un module sécurisé
WO2006035159A1 (fr) Systeme et procede cryptographique a cle publique et serveur de certification, memoires adaptees pour ce systeme
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
WO2008081150A2 (fr) Procede et systeme d&#39;autorisation d&#39;acces a un serveur
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é
WO2006051197A1 (fr) Procédé d&#39;autorisation d&#39;accès d&#39;un terminal client d&#39;un réseau nominal à un réseau de communication différent du réseau nominal, système, serveur d&#39;authentification et programme informatique correspondants
WO2007138229A2 (fr) Procede d&#39;acces securise a une ressource cryptee

Legal Events

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

Free format text: ORIGINAL CODE: 0009012

17P Request for examination filed

Effective date: 20070119

AK Designated contracting states

Kind code of ref document: A1

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

GRAP Despatch of communication of intention to grant a patent

Free format text: ORIGINAL CODE: EPIDOSNIGR1

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

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

18D Application deemed to be withdrawn

Effective date: 20080311