FR2847401A1 - Procede d'acces a un service avec authentification rapide et anonymat revocable et systeme d'ouverture et de maintien de session - Google Patents

Procede d'acces a un service avec authentification rapide et anonymat revocable et systeme d'ouverture et de maintien de session Download PDF

Info

Publication number
FR2847401A1
FR2847401A1 FR0214230A FR0214230A FR2847401A1 FR 2847401 A1 FR2847401 A1 FR 2847401A1 FR 0214230 A FR0214230 A FR 0214230A FR 0214230 A FR0214230 A FR 0214230A FR 2847401 A1 FR2847401 A1 FR 2847401A1
Authority
FR
France
Prior art keywords
client
server
anonymous
token
aca
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.)
Pending
Application number
FR0214230A
Other languages
English (en)
Inventor
Sebastien Canard
Stephane Guilloteau
Eric Malville
Jacques Traore
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
Priority to FR0214230A priority Critical patent/FR2847401A1/fr
Priority to PCT/FR2003/003380 priority patent/WO2004047362A1/fr
Priority to EP03782564A priority patent/EP1561302A1/fr
Priority to US10/534,857 priority patent/US7840813B2/en
Publication of FR2847401A1 publication Critical patent/FR2847401A1/fr
Pending legal-status Critical Current

Links

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/08—Network architectures or network communication protocols for network security for authentication of entities
    • H04L63/0823—Network architectures or network communication protocols for network security for authentication of entities using certificates
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F21/00—Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G06F21/30—Authentication, i.e. establishing the identity or authorisation of security principals
    • G06F21/31—User authentication
    • G06F21/33—User authentication using certificates
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00—Payment architectures, schemes or protocols
    • G06Q20/38—Payment protocols; Details thereof
    • G06Q20/383—Anonymous user system
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q40/00—Finance; Insurance; Tax strategies; Processing of corporate or income taxes
    • G06Q40/04—Trading; Exchange, e.g. stocks, commodities, derivatives or currency exchange
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/08—Network architectures or network communication protocols for network security for authentication of entities
    • 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/3234—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials involving additional secure or trusted devices, e.g. TPM, smartcard, USB or software token
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/32—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials
    • H04L9/3247—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials involving digital signatures
    • H04L9/3255—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials involving digital signatures using group based signatures, e.g. ring or threshold signatures
    • 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

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Security & Cryptography (AREA)
  • Business, Economics & Management (AREA)
  • Theoretical Computer Science (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Accounting & Taxation (AREA)
  • General Physics & Mathematics (AREA)
  • Computer Hardware Design (AREA)
  • General Engineering & Computer Science (AREA)
  • Finance (AREA)
  • Physics & Mathematics (AREA)
  • Strategic Management (AREA)
  • General Business, Economics & Management (AREA)
  • Computing Systems (AREA)
  • Software Systems (AREA)
  • Development Economics (AREA)
  • Economics (AREA)
  • Marketing (AREA)
  • Technology Law (AREA)
  • Management, Administration, Business Operations System, And Electronic Commerce (AREA)
  • Computer And Data Communications (AREA)

Abstract

La présente invention concerne un procédé d'accès à un service consistant à i) identifier et enregistrer un Client (C), ii) authentifier le Client auprès d'une Autorité de Certification Anonyme, iii) authentifier le Client par la production d'une signature anonyme et ouvrir et maintenir une session d'authentification anonyme auprès d'un Serveur (Se), et iv) permettre sélectivement un contact entre le Serveur (Se) et l'Autorité de Certification Anonyme (ACA) pour lever l'anonymat du Client (C) sur la base de la signature fournie à l'étape iii). L'invention concerne également un système apte à permettre l'ouverture et le maintien d'une session d'authentification garantissant la non répudiation.

Description

<Desc/Clms Page number 1>
PROCEDE D'ACCÈS AU SERVICE AVEC AUTHENTIFICATION RAPIDE ET ANONYMAT REVOCABLE
DOMAINE TECHNIQUE
L'invention concerne le domaine de la sécurité des accès à des services, notamment à des ressources informatiques.
L'invention a pour objectif général d'offrir un service d'authentification forte et anonyme d'utilisateurs et un mécanisme rapide et économique de maintien de session d'authentification.
L'invention permet, malgré l'anonymat, de responsabiliser les utilisateurs en offrant aux ressources la possibilité de lever l'anonymat de l'utilisateur le cas échéant (en cas de litige par exemple).
APPLICATIONS
L'invention peut trouver de nombreuses applications. Celles qui seront indiquées par la suite ne doivent pas être considérées comme limitatives.
Les applications majeures de cette invention sont les enchères électroniques ou les jeux en réseau/communauté. En fait, l'invention est adaptée en particulier à toute application dont le but est de proposer une place publique où plusieurs utilisateurs peuvent se réunir et échanger tout en gardant leur anonymat.
L'invention est particulièrement pertinente pour les enchères électroniques dont le but est de reproduire le principe de fonctionnement des enchères réelles. Les enchères réelles permettent à des personnes, réunies dans une même salle, de faire des offres de manière anonyme.
Bien que leur identité réelle ne soit jamais dévoilée, les participants ne peuvent pas se rétracter. La présente invention offre les mêmes propriétés d'authentification anonyme et de non-répudiation.
Ces mêmes fonctionnalités peuvent également être exploitées pour des applications de jeux multi-acteurs, tels que les jeux de casino, où plusieurs personnes se réunissent autour d'une même table de jeux sans se connaître les uns les autres. Lorsqu'un joueur mise sur un numéro, il ne peut pas nier avoir misé sur ce numéro. La présente invention offre ces propriétés : elle garantit l'anonymat des joueurs
<Desc/Clms Page number 2>
(l'identité des joueurs n'est pas révélée) tout en les responsabilisant (l'identité des joueurs pourra être révélée si besoin).
ETAT ACTUEL DES CONNAISSANCES PUBLIEES SUR LE SUJET (ART ANTERIEUR LE PLUS PROCHE) - INCONVENIENTS DE LA TECHNIQUE ANTERIEURE
Le but général de l'invention est de proposer des moyens permettant 1) de garantir l'anonymat des clients, 2) de maintenir efficacement une session d'authentification et 3) de responsabiliser les clients.
Aujourd'hui, un certain nombre de techniques permettent de répondre en partie à ces exigences, mais aucune n'offre de solution complète à la problématique globale.
Certaines techniques permettent à un serveur d'authentifier un client. Ces techniques sont généralement couplées à un mécanisme permettant de maintenir une session d'authentification entre l'utilisateur et le serveur.
Les techniques majeures offrant des services d'authentification et de maintien de session sont les suivantes : 1) les mots de passe jetables, 2) les techniques SSL et TLS et 3) la technique Kerberos.
# Les mots de passe jetables : le principe des mots de passe à usage unique - encore appelés mots de passe jetables ou OTP (OneTime Password) - consiste à utiliser des mots de passe qui ne peuvent être utilisés qu'une seule fois. Même si le mot de passe est dérobé, il n'est pas réutilisable. Dans la pratique, ce dispositif prend généralement la forme d'une cartulette (ex. ActivCard, SecurID) qui calcule les mots de passe que l'utilisateur doit saisir pour s'authentifier. Ce mot de passe est ensuite utilisé pour calculer une clé de session (une clé secrète) destinée à garantir la confidentialité et l'intégrité des échanges.
# SSL et TLS : sont des techniques qui reposent sur des certificats et des algorithmes de cryptographie à clés publiques (ou asymétriques) pour l'authentification et des algorithmes de cryptographie à clés secrètes (ou symétriques) pour le maintien de session. Un certificat constitue une carte d'identité numérique. Il prend
<Desc/Clms Page number 3>
la forme d'un fichier contenant une clé publique et des informations sur son propriétaire. Ces informations sont certifiées (i.e. signées) par une autorité de confiance appelée autorité de certification. Typiquement, pour authentifier un utilisateur, un serveur lui envoie un challenge (une valeur numérique aléatoire) que l'utilisateur signe avec sa clé privée. La clé publique permet au serveur de vérifier que l'utilisateur possède bien la clé privée, le certificat de connaître l'identité de l'utilisateur. En outre, cette phase d'authentification permet au client et au serveur de s'échanger une clé de session (une clé secrète) qui leur permettra de garantir la confidentialité et l'intégrité de leurs échanges.
# Kerberos : il s'agit d'un mécanisme de SSO (Single SignOn) permettant à un utilisateur d'accéder à plusieurs ressources sans avoir à s'authentifier plusieurs fois. Il repose sur des algorithmes de cryptographie à clé secrète. Typiquement, pour accéder à un serveur, l'utilisateur s'authentifie auprès d'un distributeur de clés ou KDC (Key Distribution Center) qui lui retourne un jeton d'authentification pour ce serveur cible. Ce jeton est envoyé de manière transparente au serveur cible et lui permet d'identifier/authentifier l'utilisateur et de récupérer une clé de session (une clé secrète) utilisée par le serveur et le client pour garantir la confidentialité et l'intégrité de leurs échanges.
Les inconvénients majeurs de ces techniques connues sont les suivants : # L'anonymat des utilisateurs n'est pas préservé : Les mécanismes d'authentification proposés par ces techniques sont destinés à vérifier l'identité réelle du client. Cette identité est dévoilée par le login dans le cas des mots de passe jetables, par le certificat dans le cas de TLS et SSL ou par le jeton d'authentification dans le cas de Kerberos.
# La non-répudiation n'est pas garantie : Ces techniques s'appuient sur des algorithmes de cryptographie à clé secrète pour maintenir la session d'authentification et garantir la confidentialité et l'intégrité des échanges. Ce type d'algorithme cryptographique ne
<Desc/Clms Page number 4>
permet pas de garantir la non-répudiation ; Le client peut toujours nier avoir envoyé un message.
# Le maintien de la session est coûteux : le maintien de la session est réalisé en chiffrant ou en authentifiant les messages que le client et le serveur s'échangent. Le client doit, en permanence, disposer de moyens de calculs pour maintenir la session.
D'autres techniques offrent des mécanismes d'authentification permettant de préserver l'anonymat des utilisateurs.
L'utilisation d'un pseudonyme est l'approche la plus couramment utilisée par les serveurs actuellement déployés sur Internet (ex. les sites d'enchères électroniques, les sites de jeux). Cette technique repose sur un mécanisme d'authentification basé sur l'utilisation d'un login (i.e. le pseudonyme) et d'un mot de passe. Les utilisateurs s'enregistrent généralement auprès du serveur en renseignant un certain nombre d'informations personnelles et en choisissant un pseudonyme et un mot de passe qu'ils devront ensuite présenter pour s'authentifier. Cette approche pose un certain nombre de problèmes : # Problème d'ergonomie chaque utilisateur doit s'enregistrer auprès de chacun des serveurs en entrant plusieurs fois les mêmes informations.
# Problème d'anonymat : Les informations personnelles des utilisateurs sont stockées sur chaque serveur. L'anonymat d'un utilisateur est garanti vis-à-vis des autres utilisateurs mais pas vis-à-vis du serveur. L'utilisateur doit donc faire totalement confiance à chacun des fournisseurs de services.
# Problème d'identification et de responsabilisation : les informations renseignées par l'utilisateur ne sont pas ou peu vérifiées.
L'utilisateur est authentifié mais faiblement. Il peut donc entrer des informations erronées, se faire passer pour quelqu'un d'autre ou s'enregistrer plusieurs fois en utilisant différents pseudonymes. D'une manière générale, cette approche ne permet pas de responsabiliser l'utilisateur puisque le serveur ne peut rien prouver.
<Desc/Clms Page number 5>
# Problème de traçabilité : le serveur peut suivre les activités de ses clients et peut ainsi en déduire un profil, information souvent plus intéressante que l'identité réelle. L'anonymat n'est donc pas complètement garanti.
Les techniques de signature de groupe voir documents ([1], [2], [3] et [4] et utilisées notamment pour les enchères électroniques dans l'article [5] ) offrent également un mécanisme d'authentification anonyme. Le principe général consiste, pour un client, à s'inscrire auprès d'une autorité de confiance, le gestionnaire du groupe. Les clients enregistrés auprès de cette autorité appartiennent à un même groupe et disposent des moyens nécessaires pour signer au nom du groupe. Tout serveur dispose des moyens pour vérifier une signature. La vérification d'une signature consiste, en fait, à vérifier qu'elle a bien été produite par un membre du groupe ; Elle ne dévoile rien sur le membre qui l'a produite et ne permet donc pas au serveur de connaître son identité. L'anonymat des clients est donc garanti. Un serveur peut, néanmoins, interroger le gestionnaire de groupe pour lever l'anonymat du signataire.
Cette technique répond donc à la problématique d'authentification anonyme. En revanche, elle n'intègre aucun mécanisme permettant de maintenir une session d'authentification entre un client et un serveur. Le serveur ne peut donc pas se "souvenir" de l'identité du client. Pour maintenir l'authentification, le client doit signer chacun des messages qu'il transmet au serveur et doit donc disposer en permanence des moyens de calcul nécessaires. De plus, les calculs mis en #uvre pour réaliser de telles signatures sont assez conséquent et ne permettent pas une authentification rapide.
BUT DE L'INVENTION
Un but de l'invention est de fournir une solution complète à la problématique d'authentification anonyme et de maintien de session.
BASE DE L'INVENTION
Le but précité est atteint dans le cadre de la présente invention grâce à un procédé qui comprend les étapes consistant à :
<Desc/Clms Page number 6>
il identifier et enregistrer un Client et lui fournir des moyens lui permettant de s'authentifier auprès d'une Autorité de Certification Anonyme, ii) authentifier le Client auprès de l'Autorité de Certification Anonyme sur la base des moyens fournis en i) et fournir des moyens lui permettant de s'authentifier de manière anonyme auprès d'un Serveur , iii) authentifier le Client par la production d'une signature anonyme et ouvrir et maintenir une session d'authentification anonyme auprès d'un Serveur, et iv) permettre sélectivement un contact entre le Serveur et l'Autorité de Certification Anonyme pour lever l'anonymat du Client sur la base de la signature fournie à l'étape iii).
L'étape i) consiste avantageusement pour un Client utilisateur à récupérer, auprès de l'Autorité de Certification Anonyme formant un tiers de confiance, les informations (une clé publique et un certificat) lui permettant de calculer des signatures anonymes. Tout serveur ou ressource peut vérifier ces signatures sans que l'identité réelle de l'utilisateur ne lui soit révélée. Une signature valide garantie à la ressource ou serveur qu'il pourra, le cas échéant, recouvrer l'identité réelle de l'utilisateur en interrogeant le tiers de confiance.
La présente invention propose ainsi une solution complète et globale pour : # Garantir l'anonymat des clients : l'invention repose sur des mécanismes d'authentification forte permettant de préserver l'anonymat des clients ; # Maintenir efficacement une session d'authentification : le mécanisme de maintien de session d'authentification que propose l'invention ne nécessite aucun calcul côté client. Toutes les informations nécessaires sont calculées au cours de la phase d'authentification ; # Responsabiliser les clients : L'invention permet de garantir la non-répudiation. D'une part, parce qu'à tout moment, le serveur peut lever l'anonymat d'un client en interrogeant un tiers de confiance.
<Desc/Clms Page number 7>
D'autre part, parce que le serveur peut prouver chacune des actions d'un client.
La présente invention concerne également un système apte à permettre l'ouverture et le maintien d'une session d'authentification garantissant la non répudiation, caractérisé par le fait qu'il comprend des moyens adaptés pour la mise en #uvre de trois phases : . une première phase dans laquelle un Client calcule un ensemble de données, formé d'une suite de jetons, l'un de ceux-ci permettant d'ouvrir une session, tandis que les autres permettent de la maintenir, . une deuxième phase dans laquelle le Client s'engage fortement sur la suite de jetons après d'un Serveur, et . une troisième phase de maintien de la session à l'aide de la suite de jetons.
On notera que dans le contexte de ce système d'ouverture et de maintien de session, le Client dispose de moyens lui permettant de produire une signature digitale qui n'est pas obligatoirement anonyme, bien que préférentiellement elle le soit bien entendu.
D'autres caractéristiques, buts et avantages de la présente invention apparaîtront à la lecture de la description détaillée qui va suivre, et en regard des dessins annexés, donnés à titre d'exemples non limitatifs et sur lesquels : - la figure 1 représente l'architecture générale des moyens relationnels mise en jeu dans le cadre de la présente invention, - la figure 2 représente un organigramme schématique du procédé conforme à la présente invention, - la figure 3 schématise le processus d'identification forte, - la figure 4 schématise le processus de certificat anonyme, - la figure 5 schématise le processus de signature aveugle à anonymat révocable, - la figure 6 schématise le processus de signature de groupe, - la figure 7 schématise l'application de la présente invention à un processus d'enchères électroniques,
<Desc/Clms Page number 8>
- la figure 8 schématise une étape préparatoire de mise en vente et consultation dans le contexte d'enchères électroniques, - la figure 9 schématise un exemple de fiche article mise à disposition d'un visiteur, Client potentiel, dans le cadre d'une vente aux enchères, - la figure 10 schématise une étape d'obtention de certificat anonyme, - la figure 11 schématise les étapes d'inscription de groupe, génération de clés et envoi de certificat dans ce contexte, - la figure 12 schématise une étape de demande de participation avec certificat et autorisation, - la figure 13 schématise les étapes d'initialisation puis de génération de jetons par deux Clients respectifs dans le cadre d'enchères, - la figure 14 schématise une étape de participation à une vente aux enchères, - la figure 15 schématise les étapes de surenchères par transmission de jeton dont l'indice (ou "rang") représente la valeur choisie pour la surenchère, - la figure 16 schématise une étape de traitement des ordres d'enchères, - la figure 17 schématise le traitement d'un jeton reçu d'un Client et la comparaison de la valeur représentée par son indice avec les données antérieurement reçues, - la figure 18 schématise une étape de conclusion de vente aux enchères, - la figure 19 schématise des étapes d'information de Client gagnant d'enchères, de Clients perdant, de vendeur et de fin de transaction, et - la figure 20 schématise une architecture Client-Serveur permettant de mettre en oeuvre le procédé à la présente invention.
Comme indiqué précédemment et illustré sur la figure 1 annexé, l'invention met en oeuvre trois entités dans le protocole : des Clients C, au moins une Autorité de Certification Anonyme ACA et au moins un Serveur (ou "Ressource") Se.
<Desc/Clms Page number 9>
Comme également indiqué précédemment, l'invention propose, d'une part, un mécanisme d'authentification anonyme basé sur l'utilisation de certificat anonyme. Elle propose, d'autre part, un mécanisme de maintien de session économique et efficace garantissant la non-répudiation. Enfin, elle propose une solution globale combinant les mécanismes d'authentification anonyme (ex. signature de groupe, certificat anonyme) et le mécanisme de maintien de session pour répondre aux problématiques suivantes : # L'anonymat des utilisateurs : l'invention repose sur des mécanismes d'authentification forte permettant de préserver l'anonymat des utilisateurs, non seulement vis-à-vis des autres utilisateurs, mais aussi vis-à-vis des serveurs ; # L'efficacité et portabilité : le mécanisme de maintien de session d'authentification que propose l'invention ne nécessite aucun calcul côté utilisateur. Toutes les informations nécessaires sont calculées préalablement au cours de la phase d'authentification ; # La non-répudiation : L'invention permet de garantir la nonrépudiation. D'une part parce qu'à tout moment, le serveur peut lever l'anonymat d'un utilisateur en interrogeant le tiers de confiance ACA.
D'autre part parce que le serveur peut prouver chacune des actions d'un utilisateur.
# L'ergonomie : l'utilisateur s'enregistre une seule et unique fois auprès d'un tiers de confiance ACA.
L'Autorité de Certification Anonyme (ACA) délivre des certificats anonymes et est adaptée et habilitée pour lever l'anonymat le cas échéant. Le Serveur fournit des services à des personnes C désirant rester anonyme, cet anonymat pouvant être levé quand cela est nécessaire. Un Client va obtenir un certificat anonyme dans le but de s'authentifier anonymement puis de maintenir une session auprès d'un Serveur.
Le procédé conforme à l'invention dans une mise en oeuvre préférentielle comprend essentiellement 4 étapes.
<Desc/Clms Page number 10>
# Etape 1 : l'identification. Le Client C s'enregistre auprès d'une autorité de confiance (cette autorité peut être soit l'Autorité de Certification Anonyme elle-même, soit une autorité de certification).
Cette étape consiste pour l'utilisateur à fournir des informations personnelles (nom, prénom, adresse, etc.). Plusieurs alternatives sont possibles pour cela. Par exemple, le client peut s'enregistrer soit en ligne en remplissant un formulaire électronique, soit en se déplaçant physiquement dans un endroit bien précis. L'autorité de confiance vérifie l'identité du client et toutes ou une partie de ses informations personnelles, stockent ces informations pour une utilisation future et fournit au Client les moyens (par exemple un login/mot de passe ou un certificat) qui lui permettront de s'authentifier auprès de l'ACA. Il est à noter que dans tout le reste du protocole, le Client ne fournira plus à aucun moment ses données personnelles.
# Etape 2 : l'authentification auprès de l'ACA. Cette étape met en jeu le Client et l'ACA. Le Client s'authentifie de manière forte auprès de l'ACA (en utilisant les moyens qu'il a obtenus à l'étape 1). L'ACA lui délivre en retour les moyens de produire une signature anonyme. Elle se garde les moyens de pouvoir relier à tout moment le Client (i.e. la personne physique qu'elle connaît à l'aide de l'authentification forte) à n'importe quelle signature émanant de celui-ci.
# Etape 3 : l'authentification anonyme auprès du Serveur. Cette étape met en jeu un Serveur et un Client. Ce dernier désire maintenir une session pour accéder aux services qu'offre le Serveur et doit pour cela faire savoir à ce dernier qu'il s'est authentifié de manière forte auprès de l'ACA. Pour autant, le Client veut rester anonyme vis-à-vis du Serveur et d'autres clients potentiels. Le but de cette étape est d'ouvrir une session auprès due Serveur en faisant un certain nombre de calculs pour ensuite pouvoir maintenir cette session de manière très rapide.
Cette étape va ainsi se diviser en trois phases. La première phase va permettre au Client de calculer un ensemble de données (une suite de jetons), l'un de ces jetons permettant d'ouvrir la session alors que les autres permettront de la maintenir. La deuxième phase
<Desc/Clms Page number 11>
permettra au Client de s'engager fortement sur cette suite de jetons auprès du Serveur. La troisième phase consistera à maintenir la session à l'aide de cette suite.
Remarque 1 : certains cas (par exemple lorsque le service d'anonymat est facturé aux serveurs), l'ACA peut exiger une authentification des Serveurs qui veulent offrir le service d'anonymat à leurs utilisateurs. Pour cela, l'ACA doit pouvoir exiger une authentification des serveurs avant de remettre un certificat anonyme à l'utilisateur et/ou avant de lever l'anonymat. Les serveurs doivent donc préalablement se soumettre à une phase d'enregistrement auprès de l'ACA. Pour cela, chaque serveur fait une demande d'affiliation à l'ACA qui étudie la proposition (suivant des critères qu'elle a établis) et décide d'accepter ou non la proposition.
Remarque 2: Les deux premières phases nécessitent un dialogue entre l'utilisateur et l'ACA d'une part (première phase), et entre l'utilisateur et le serveur d'autre part (seconde phase). Elles seront donc typiquement réalisées en utilisant un navigateur web ou une application hébergée sur le poste du client. Toutefois, puisque la suite de jetons est pré-calculée au cours de la phase d'authentification, elle peut être embarquée dans un terminal portable (téléphone mobile, PDA, ...).
L'utilisateur peut donc s'authentifier auprès du serveur en utilisant un navigateur ou une application et maintenir ensuite la session d'authentification en utilisant un autre type de terminal.
Tous les jetons sont à usage unique et sont fortement dépendants les uns des autres. Ils ne peuvent être calculés que par le Client et sont non-falsifiables. N'importe qui, et en l'occurrence le Serveur, peut vérifier la dépendance (et donc la provenance) de ces jetons.
Dans un premier temps donc, le Client, au cours de l'ouverture de la session, calcule la suite de jetons. L'algorithme de génération des jetons est basé sur l'utilisation de deux primitives cryptographiques : une fonction de hachage et un nombre aléatoire.
Une fonction de hachage H() possède les propriétés suivantes :
<Desc/Clms Page number 12>
- H (M) sur un message M de longueur arbitraire - Le résultat h = H (M) une longueur 1 fixe - Etant donné M, il est facile de calculer h - Etant donné M, il est difficile de trouver un autre message Mo tel que H (M) =H(Mo)
Parmi les fonctions de hachage, nous pouvons citer MD5 ("Message Digest 5") ou SHA ("Secure Hash Algorithm"). SHA produit une sortie de 160 bits appelée message abrégé.
Afin d'initialiser l'ensemble des jetons, il est nécessaire de générer un nombre aléatoire à partir duquel la fonction de hachage va calculer les jetons. Ce nombre aléatoire doit être cryptographiquement sûr, c'est-à-dire qu'il faut que la probabilité de réussite de la recherche exhaustive soit quasi nulle.
La fonction de hachage appliquée à ce nombre aléatoire Wo permet d'obtenir un résultat W1 (c'est-à-dire un premier jeton) auquel on applique à nouveau la fonction de hachage pour obtenir un deuxième jeton W2 et ainsi de suite pour obtenir n jetons :
H(Wo) = W1, ..., H(Wn-1) = Wn
La suite de jetons est donc Wn,Wn-1,Wn-2,...,W1,W0). Du fait des propriétés des fonctions de hachage, il est facile, à partir de Wo, de calculer n'importe lequel des W, (pour i allant de 1 à n) alors qu'il est impossible en pratique de retrouver Wo à partir des W, (pour i allant de 1 à n).
Dans un second temps, le Client utilise ses moyens d'authentification forte anonyme obtenus à l'étape 2 pour produire une signature anonyme du jeton d'initialisation Wn, la signature permettant au serveur d'authentifier ce Client (il peut vérifier la validité de la signature et donc être convaincu des droits du client qu'il a en face de lui). Le Client vient ainsi d'ouvrir une session anonyme auprès du Serveur. Il va pouvoir maintenir cette session à l'aide de la suite de jetons. Le jeton Wn est stocké par le Serveur et sera utilisé pour vérifier la validité des autres jetons (et donc de la session).
<Desc/Clms Page number 13>
Remarque : Au cours de la phase d'authentification anonyme, un certain nombre d'informations peuvent être associées au jeton d'initialisation (par exemple, la valeur numéraire d'un jeton). Ces informations constituent les informations de session et permettent de décrire la sémantique associée à chaque jeton. Un jeton permettra donc au serveur de retrouver l'identité de l'émetteur mais également les informations de session.
Au cours de la session, le Serveur veut être sûr de pouvoir retrouver l'identité physique du client qu'il a en face de lui, selon le principe défini à la quatrième étape. De plus, il faut que cette authentification se fasse rapidement. Pour cela, le Client transmet simplement, à chaque nouvelle authentification, un jeton de la liste calculée précédemment : Wn-1, puis Wn-2,Wn-3, ... Pour poursuivre la session, le Client transmet ainsi les jetons dans l'ordre de n - 1 à 0.
D'une manière générale, si le résultat de h(Wn-1) est bien égal à Wn alors l'authentification est acceptée. Le Serveur est capable de vérifier ce lien . le jeton W, reçu est comparé avec les jetons de l'ensemble des clients présents dans la base. Ainsi, pour trouver dans la base le Wk relié au W1 reçu, il utilise la formule : h'(W,) = Wk (en utilisant le fait que h2(Wn-2)=h(h(Wn-2))=h(Wn-1)=Wn). Si le Serveur parvient à trouver dans sa base ce jeton Wk, alors il accepte la poursuite de la session et le jeton W, remplace le jeton Wk pour la vérification suivante.
Dans le cas contraire, le jeton n'appartient pas à un client et l'authentification est refusée.
Lors des diverses authentifications se déroulant au cours de la session, le Serveur sait ainsi toujours relier un jeton (et donc la session) à la signature anonyme effectuée au moment de l'ouverture de cette session.
# Etape 4 : Elle met en jeu un Serveur et l'Autorité de confiance.
Le premier a en sa possession une signature qu'il sait émanant d'un Client s'étant identifié de manière forte auprès de l'ACA. S'il le souhaite, il peut donc envoyer cette signature à l'ACA qui a les moyens de découvrir l'identité physique du signataire (cf. première étape) et de
<Desc/Clms Page number 14>
fournir cette information au Serveur. Ce dernier peut ainsi obtenir l'identité physique du Client ayant produit la signature et l'ensemble des jetons qu'il a reçu au cours de sa session.
Une variante consiste à faire en sorte que le Serveur ne connaisse à aucun moment l'identité du Client. Dans ce cas, une fois la levée d'anonymat effectuée par l'ACA, ce dernier contacte personnellement le Client impliqué et termine ainsi la session de la manière adéquate.
Dans certains cas, le droit de production de signature anonyme a une durée de vie limitée (par exemple liée à une seule session). Dans ce cas, le Client devra s'authentifier de manière forte auprès de l'ACA à chaque session (i.e. pour chaque suite de jeton).
Le nombre de sessions liées à un engagement est limité dans le temps. En effet, la suite de jetons est finie. Une fois le dernier jeton envoyé, le Client doit produire une nouvelle suite de jetons auprès du Serveur et doit signer anonymement le jeton d'initialisation.
D'autre part, l'étape 3 peut être utilisée seule pour ouvrir et maintenir efficacement une session d'authentification. Ainsi, un Client va pouvoir s'authentifier de manière forte auprès du serveur (mais sans anonymat cette fois-ci) et maintenir une session, de manière très rapide, à l'aide de la suite de jetons qu'il aura préalablement calculés.
Cette approche permet, en outre, de garantir la non-répudiation.
DESCRIPTION DETAILLEE D'UN MODE DE REALISATION
Spécification du mécanisme de jetons
Jeton d'initialisation
Le premier jeton envoyé par le Client au Serveur est appelé jeton d'initialisation et permet d'ouvrir la session. Il est lié, à la fois, à l'authentification du Client à partir d'une signature et aux informations de session. Ainsi, le jeton d'initialisation fixe par association, dans un message envoyé par le Client au Serveur, la preuve d'authentification et les paramètres d'initialisation de la session.
Dans le cas des enchères, dont l'application est décrite par la suite, le mécanisme de jetons est utilisé dans la phase de participation à
<Desc/Clms Page number 15>
une vente. Un Client demande une participation à la vente aux enchères en transmettant un message composé du jeton d'initialisation associé aux paramètres de la vente, par exemple, l'identifiant de l'article, son prix actuel, et la valeur du pas. C'est ce message qui est signé. Le Client transmet également, dans cette demande de participation, les moyens pour le serveur de vérifier la signature (message, clé publique, certificat...) et donc d'authentifier le Client, en fonction du mécanisme de signature utilisé. Des spécifications du mécanisme de signature seront décrites ci-dessous.
Si l'authentification du Client par le Serveur est valide, le jeton d'initialisation et les données transmises par le Client, dans cette demande de participation, sont enregistrés par le Serveur d'Enchères.
Jetons de maintien de session
Dans le cas des enchères, si le Serveur autorise le Client à participer à la vente après avoir reçu le jeton d'initialisation, le Client peut alors surenchérir en envoyant au Serveur les jetons successifs et seulement les jetons. En effet, chaque ordre d'enchère du Client se traduit par l'envoi d'un jeton sans autre information ni signature. A partir des informations enregistrées avec le jeton d'initialisation, le Serveur est capable d'authentifier l'ordre en attribuant le jeton à son Client propriétaire et de calculer sa valeur. Ainsi, chaque jeton reçu par le Serveur est comparé avec l'ensemble des jetons enregistrés. Par dépendance entre jetons, le nouveau jeton reçu par le Serveur ne peut correspondre qu'à un seul jeton présent dans la base. Le Serveur retrouve les informations sur le Client et sur l'article lié au jeton reçu en le mettant en correspondance avec un jeton stocké et un seul. Selon ce procédé, le mécanisme de jetons peut s'appliquer aux enchères en établissant des règles de calcul.
Côté client, le calcul de l'indice i du jeton Wi pour surenchérir (prixsup) est basé sur le prix actuel de l'article (prixmax) et du pas de l'article (pas). Les formules peuvent être : prixsup = prixmax + pas j = (prixsup - prixdedepart)/pas
<Desc/Clms Page number 16>
i = nombretotaldejetons - j
Côté serveur, le jeton W, reçu est comparé avec les jetons présents dans la base. Les formules permettant de retrouver le jeton et de calculer sa valeur peuvent être : - Pour trouver dans la base Wk, la formule est : h'(W,) = Wk - Pour calculer la valeur de W,, la formule est : W, = prixdeWk + *pas)
Spécification du mécanisme de signature du jeton d'initialisation.
La signature du jeton d'initialisation permet l'ouverture d'une session et peut être réalisée, selon les cas, avec ou sans anonymat. Le Client possède une clé privée SK, une clé publique PK et un certificat (anonyme ou non). Il utilise sa clé privée SK et un algorithme cryptographique (par exemple RSA, DSA ou signature de groupe) pour signer un message composé du jeton d'initialisation Wn et des informations de session session~data. Il obtient ainsi une signature SSigsk (Wn, session~data) qu'il envoie au Serveur avec le message, sa clé publique PK et le certificat C qui relie cette clé publique à son identité propre.
La figure 3 schématise les détails du protocole de signature du jeton d'initialisation.
Spécification des mécanismes de signature anonyme.
Certificat anonyme
Lors de la seconde étape, le Client C crée une paire de clés publique PK - privée SK (par exemple des clés RSA). Il garde secret la clé privée et envoie à l'ACA la clé publique PK afin d'obtenir, lors d'une session authentifiée fortement, un certificat AC=SigAcA (PK, Pseudo) de cette clé liée à un pseudonyme choisi par l'ACA et/ou le Client. Ce pseudonyme peut éventuellement être le chiffrement de la véritable identité du Client accompagnée d'un aléa. La levée de l'anonymat se fait ainsi facilement par l'ACA qui déchiffre ce pseudonyme pour obtenir l'identité du Client. L'ACA garde en mémoire le lien entre le Client et son pseudonyme pour, par la suite, pouvoir lever l'anonymat.
<Desc/Clms Page number 17>
Remarque : D'une manière générale, un certificat anonyme permet de lier un pseudonyme à une clé publique. Mais il peut également, en fonction du contexte, contenir d'autres informations permettant de limiter la portée du certificat (ex. l'identifiant du serveur, l'identifiant d'une session, une date de validité, l'adresse IP du client, le contexte d'authentification ...).
L'étape de signature du jeton d'initialisation consiste pour le Client à utiliser sa clé privée PK (il s'agit donc d'une signature RSA). Le message est constitué du jeton d'initialisation W1000, de la signature S, de la clé publique PK et du certificat lié au pseudonyme AC+Pseudo. Le Serveur ouvre donc une session avec un client qu'il ne connaît que sous un pseudonyme. Il vérifie ainsi que le Client s'est authentifié fortement auprès de l'ACA à l'aide du certificat AC et que la clé publique PK certifiée (et appartenant au pseudonyme) permet bien de vérifier la signature du jeton d'initialisation.
La levée de l'anonymat est mise en oeuvre lorsque le Serveur fournit à l'ACA le certificat (ou le pseudonyme). L'ACA peut savoir à quel Client correspond ce pseudonyme et donc qui a produit la signature.
La figure 4 schématise les détails des protocoles de certificat anonyme.
Il est à noter que pour obtenir un anonymat intéressant, il convient de changer de certificat (et donc de paire de clé de signature) à chaque session. Il faut donc que le Client se connecte à l'ACA à chaque session.
Remarque : si le Client désire se connecter à plusieurs serveurs bénéficiant des services de l'ACA, au moins deux possibilités s'offrent à lui. Soit l'ACA fournit un seul certificat (universel) pour l'ensemble des serveurs, auquel cas il est possible de tracer le pseudonyme de ce Client sur l'ensemble des sites (on ne sait pas qui il est mais on sait ce qu'il fait sur chacun des serveurs). Soit l'ACA fournit un certificat par serveur , auquel cas on perd l'universalité du certificat mais il est alors impossible de tracer un même client sur plusieurs serveurs.
<Desc/Clms Page number 18>
Chaque serveur fournit au Client un identifiant qui est retransmit à l'ACA. Ce dernier sait alors qu'il a fournit à tel Client un certificat pour tel Serveur et donc n'en fournira pas deux.
Remarque : de même, si le Client possède deux machines à partir desquelles il désire accéder au Serveur (par exemple une machine à son lieu de travail et une machine chez lui), il doit pouvoir obtenir deux certificats différents de la part de l'ACA.
Certificat aveugle à anonymat révocable
Une partie du processus conforme à la présente invention peut s'apparenter à un certificat aveugle à anonymat révocable.
Le concept de schéma de signature aveugle a été introduit par Chaum à Crypto'83. Un schéma de signature aveugle est un protocole mettant en jeu deux entités : un signataire et un utilisateur. Il permet à l'utilisateur d'obtenir la signature d'un message donné faite par le signataire, sans que ce dernier n'apprenne quoi que ce soit à propos du message.
Le modèle de la signature aveugle à anonymat révocable est constitué de plusieurs utilisateurs, d'un signataire, d'une autorité reconnue, par exemple un juge, et de deux protocoles : - Un protocole de signature entre le signataire et l'utilisateur.
- Un protocole de recouvrement entre le signataire et le juge.
A l'aide du protocole de signature, l'envoyeur obtient une signature valide du message de son choix de telle sorte que le signataire ne peut pas relier le protocole et la paire message/signature. Il existe deux types de signature aveugle à anonymat révocable, suivant l'information que le juge reçoit du signataire pendant le second protocole : - Révocation de type 1 : àl'aide de la partie du protocole venant du signataire, le juge donne l'information qui permet au signataire (ou à n'importe qui) de reconnaître le message (i.e. le juge peut retrouver le message).
<Desc/Clms Page number 19>
- Révocation de type 2 : àl'aide du message et de la signature, le juge permet au signataire de retrouver efficacement l'utilisateur ou la partie du protocole correspondant à la signature.
On se reportera aux documents [6], [7], [8], [9], [10] et [11] pour disposer d'exemples de schéma de signature aveugle à anonymat révocable (en anglais "fair blind signature").
Dans le cas de l'invention (révocation de type 2), l'ACA joue le rôle du signataire et le Serveur joue celui de juge. Le Client est l'utilisateur. Lors de la première étape, le Client crée une paire de clés publique PK - privée SK (par exemple de type RSA). Il garde secret la clé privée de signature et envoie à l'ACA la clé publique PK afin d'obtenir, lors d'une session authentifiée fortement, une signature aveugle BC à anonymat révocable (protocole d'obtention de certificat) de cette clé (la signature aveugle correspond à son certificat anonyme).
L'ACA garde en mémoire les moyens de lever l'anonymat de cette signature. Sur la figure 5, cette signature aveugle est intitulée BC=BSigAcA (PK).
L'étape de signature du jeton d'initialisation (protocole de signature de jeton) consiste pour le Client à utiliser sa clé privée PK pour signer (il s'agit donc d'une signature RSA). Le message est constitué du jeton d'initialisation W1000, de la signature S, de la clé publique PK et du certificat anonyme BC. Le Serveur vérifie ainsi que le Client s'est authentifié fortement auprès de l'ACA à l'aide du certificat anonyme (il vérifie que la signature BC émane bien de l'ACA) et que la clé publique PK certifiée permet bien de vérifier la signature S du jeton d'initialisation.
La levée de l'anonymat est mise en oeuvre lorsque le Serveur fournit à l'ACA le certificat anonyme BC. L'ACA peut savoir à quel moment il a produit cette signature (protocole de levée d'anonymat) et donc à qui est ce qu'il l'a fourni.
La figure 5 schématise les détails des protocoles de certificat aveugle à anonymat révocable.
<Desc/Clms Page number 20>
Il est à noter que dans ce cas, il convient d'obtenir une signature aveugle pour chaque session (il est ainsi impossible de relier deux sessions d'un même client). Il faut alors que le Client se connecte à l'ACA avant chaque début de session.
On retrouve le même problème (et les mêmes solutions) que pour le certificat anonyme dans le cas de plusieurs serveurs ou de plusieurs machines par client.
Certificat de groupe
L'invention peut également mettre en oeuvre une signature de groupe.
Une signature de groupe permet aux membres d'un groupe de produire une signature telle que le vérificateur reconnaîtra cette signature comme ayant été produite par un membre du groupe, tout en ignorant de quel membre il s'agit. Cependant, une autorité de confiance a la possibilité de lever à tout moment cet anonymat et donc de révéler l'identité du signataire. De telles signatures sont bien souvent "noncorrélables" : il est impossible de déterminer si deux signatures ont été émises par la même personne ou non.
Dans tout schéma de signature de groupe, est attribuée au groupe une unique clé publique de groupe, tandis que sont attribués à chaque membre de ce groupe un identifiant et une clé privée qui lui sont propres. A l'aide de sa clé privée, un membre du groupe peut produire une signature de groupe d'un message de son choix, laquelle signature peut être vérifiée par une entité quelconque à l'aide de la clé publique de groupe. La vérification apprend seulement à cette entité que la signature a été produite par un membre du groupe, mais ne lui donne aucune information sur l'identifiant du membre qui a signé. En revanche, l'autorité de confiance dispose d'une information supplémentaire qui lui permet de retrouver l'identifiant de ce membre, et donc de lever cet anonymat à tout moment (on dit que l'autorité de confiance "ouvre" la signature). On se reportera aux documents [1], [2], [3] et [4] pour des schémas de signature de groupe.
<Desc/Clms Page number 21>
Dans le cas de l'invention, l'ACA joue le rôle d'autorité de confiance. Au cours de la première étape, un Client va s'inscrire à unn groupe auprès de l'ACA en interagissant avec lui afin d'obtenir un certificat de membre GC (protocole d'enregistrement d'un membre).
L'ACA se garde les moyens d'ouvrir une signature le cas échéant.
L'étape de signature du jeton d'initialisation W1000 consiste à produire une signature de groupe S de cet élément (protocole de signature de groupe) soit S=SigGP (W1000). Ainsi, le signataire est anonyme au sein du groupe. Le Serveur a les moyens de vérifier qu'une signature a bien été émise par un membre du groupe (protocole de vérification de signature de groupe) mais sans pour autant savoir de quel membre il s'agit.
Enfin, l'ACA, en temps qu'autorité de confiance, a les moyens d'ouvrir la signature (protocole d'ouverture de signature de groupe) pour lever l'anonymat et divulguer l'identité du signataire.
La figure 6 schématise les détails des protocoles de certificat de groupe.
Il est à noter que, du fait des propriétés d'anonymat et de nonreliabilité des signatures de groupe, il n'est pas nécessaire de s'enregistrer au groupe pour chaque session. Le fait d'être inscrit au groupe permet de faire autant de signature de groupe que le Client le désire sans pour autant que quelqu'un puisse relier deux de ses signatures. Ce certificat unique peut être utilisé chez plusieurs serveurs sans risque de pouvoir tracer le client. De même, un client possédant plusieurs machines n'aura pas besoin d'obtenir plusieurs certificats.
Remarque : Une propriété intéressante des approches basées sur les signatures de groupe et les signatures aveugles est qu'elles permettent de répartir les fonctions de génération de certificats et le pouvoir de levée d'anonymat entre deux ou plusieurs autorités. Selon ce principe, la levée de l'anonymat d'un utilisateur ne sera possible que si l'ensemble de ces autorités l'autorise. Ce processus est moins naturel dans le cas des certifications anonymes.
EXEMPLE DE REALISATION
<Desc/Clms Page number 22>
On va maintenant décrire plus particulièrement l'application de la présente invention aux enchères électroniques.
L'application présentée ici pour illustrer le procédé conforme à l'invention appartient au domaine du commerce électronique sous la forme des ventes aux enchères sur Internet.
Le principe de ventes retenu est celui des enchères classiques où un article est mis aux enchères croissantes entre plusieurs enchérisseurs et pendant un temps déterminé. Cette réalisation s'appuie sur les technologies Java (applet, servlet, jsp) en architecture client-serveur avec un système de gestion de base de données relationnel.
1 Problème spécifique aux enchères résolu par le procédé
1.1 But
Le procédé offre une solution innovante pour sécuriser les enchères électroniques et permettre de réaliser des transactions en toute confiance.
Actuellement, les enchères en ligne ne présentent pas des niveaux de sécurité suffisants dans le cas d'enchères de grandes valeurs et pour des participants scrupuleux de préserver leur anonymat.
L'organisation de ventes aux enchères publiques de plusieurs milliers voire plusieurs millions d'euros réclament de nouveaux mécanismes.
La cryptographie utilisée dans le cadre de l'invention permet de répondre aux objectifs. Les informations transmises sont inintelligibles à des personnes extérieures à la transaction pour des raisons de confidentialité.
Le procédé assure la non-répudiation pour garantir que le client ne peut pas nier avoir fait acte de surenchère.
Le procédé assure l'intégrité des données échangées.
Le procédé permet d'assurer l'identité d'un utilisateur par authentification.
De plus, le procédé est rapide pour la prise en compte en temps réel des ordres d'enchères.
1. 2 Innovation et avantages techniques du procédé appliqué aux enchères
<Desc/Clms Page number 23>
Le mécanisme de jetons signés avec anonymat est adapté aux enchères. Avec ce procédé, un acheteur peut être autorisé à participer aux enchères sans risque d'infractions liées à la divulgation de son identité. Personne ne peut se faire passer pour un autre et seuls les membres inscrits et autorisés peuvent participer aux enchères.
Le système actuel connu de login/mot de passe est très répandu mais il ne présente pas toutes les garanties. Un programme informatique peut facilement capturer l'information transmise en clair sur Internet et offrir ainsi la possibilité à un usurpateur de voler un mot de passe. Si un protocole comme SSL permet de se prémunir contre ce type d'attaques, il ne permet pas en revanche de lutter contre les attaques à base de dictionnaires de mots de passe. En effet, ces attaques peuvent permettre de casser facilement des mots de passe trop courts et trop simples.
La caractéristique des jetons utilisés dans le procédé conforme à l'invention est son usage unique. Il ne peut servir que pour un ordre d'enchère et un seul, et ne dévoile aucune information sur son utilisateur. Il permet juste de vérifier que la requête transmise appartient bien à un utilisateur précis. Ici, un ordre d'enchère identifié par un mot de passe jetable est certifié appartenir à un acheteur particulier pour une valeur unique.
Les jetons sont envoyés par le client C au serveur d'enchères Se pour enchérir sur un produit. La présentation au début de l'enchère d'un premier jeton, noté W1000 pour le client 1 et X1000 pour le client 2, sert d'initialisation et de preuve pour la suite de la vente (voir figure 7).
A partir de ce mécanisme de jetons, le principe est de signer le premier jeton envoyé pour enregistrer la demande de participation d'un client.
Les jetons transmis pour enchérir sont vérifiés à partir de ce premier jeton d'initialisation, conformément au processus précédemment décrit.
Les jetons suivants représentent les surenchères. Par exemple, si un client (client 1) participe à une enchère avec un prix de départ à 1000 et un pas à 100, il peut proposer d'enchérir à 1100 en transmettant un jeton (W999). Pour enchérir à 1400 et battre un autre
<Desc/Clms Page number 24>
acheteur monté à 1300, il devra révéler le jeton correspondant au prix de 1400 soit le jeton W996.
Ce processus est schématisé sur la figure 7.
2 Modélisation du système
2. 1 Schéma général
L'application de ventes aux enchères fait appel aux trois entités définies précédemment dans le procédé : - L'Autorité de Certification Anonyme (ACA) est placée sur un serveur d'anonymat (SA); - Le serveur Se fournisseur de services est ici le serveur d'enchères ; - Le client C.
Nous trouvons également dans cette application un serveur de certificat (SC) qui fournit un certificat pour l'authentification forte.
Les fonctions principales du système d'enchères électroniques sont : - La phase préparatoire : qui consiste à mettre en vente, consulter et obtenir un certificat anonyme; - La phase d'enchères : qui consiste à demander et vérifier une participation à une vente, enchérir et vérifier l'enchérissement dans le but d'acquérir un article; - La phase conclusion : qui consiste à mettre un terme aux enchères, valider et identifier un gagnant en levant l'anonymat, clore la vente.
Chacune de ces fonctions va être détaillée par la suite.
2. 2 Mise en vente et consultation
Cette fonction est schématisée figure 8.
Phase du déroulement : Préparatoire ; - Niveau de sécurité : Assurer l'authenticité du serveur d'enchères ; - Précondition : Connaîtrele site d'enchères ; - Objectifs : Faire connaître les articles mis en vente ; - Acteur principal : Visiteur, Vendeur, Administrateur ;
<Desc/Clms Page number 25>
Scénario typique : M. Martin est un collectionneur d'art, il décide d'acquérir une oeuvre mise en vente sur le site d'enchères. Il se connecte au site et demande à afficher le catalogue des articles à vendre. Parmi les articles, il s'intéresse plus particulièrement à une photographie intitulée Regards dont le prix de départ est 600 euros et vendu par M.LeVendeur. Il clique alors pour obtenir la fiche article, illustré à titre d'exemple sur la figure 9.
2. 3 Obtention d'un certificat anonyme
Cette fonction est schématisée sur la figure 10.
- Phase du déroulement : Préparatoire ; elle correspond à la première étape du procédé; - Niveau de sécurité : Obtenir l'anonymat avec la signature de groupe ; - Contrainte : Double certification ; - Précondition : Authentification forte (étape 1 du procédé), choisir un serveur d'anonymat (SA) ; - Objectifs : S'authentifier pour participer à une vente aux enchères tout en étant anonyme ; - Acteur principal : Visiteur et SA; - Scénario typique : M.Dupond est toujours décidé à participer à la vente aux enchères pour une #uvre d'art dont le prix de départ est 500. 000 euros. Il souhaite rester anonyme pour cette vente afin de ne pas révéler ses moyens financiers ni son intérêt pour le type d'oeuvre à vendre, et, s'il gagne l'enchère, il ne veut pas que l'on sache qu'il devient le nouveau propriétaire. Rester anonyme tout en signant est rendu possible grâce à la signature de groupe. M. Dupond fait donc appel aux services d'une autorité de certification délivrant une signature de groupe. Il s'inscrit à un groupe qui vérifie son identité avant de lui fournir les moyens de créer ses clés et de l'enregistrer comme membre certifié. Un tel processus est schématisé figure 11.
2. 4 Demande de participation avec certificat et autorisation
Cette fonction est schématisée figure 12.
<Desc/Clms Page number 26>
Phase du déroulement Enchère ; elle fait partie de la troisième étape du procédé; - Niveau de sécurité : Certificat et applet signée de génération de jetons d'enchères; - Précondition : Pour le client, avoir un certificat, avoir choisi un article, autoriser le chargement des applets signées ; pour le serveur d'enchères, avoir obtenu les moyens de vérifier une authentification anonyme (deuxième étape du procédé); - Objectifs : Participer à une vente aux enchères ; - Acteur principal : Client ; - Scénario typique : Afin de participer à l'enchère, M.Dupond présente sa demande à l'aide d'un jeton signé. Ce premier jeton, noté W1000 pour M. Dupond et X1000 pour un autre client (voir figure 13), sert d'initialisation et de preuve pour la suite de la vente. Ce premier jeton est généré et signé par le client avec sa clé privée grâce à une applet transmise par le site d'enchère. Le jeton est associé aux paramètres de la vente, identifiant de l'article, prix actuel et valeur du pas. Pour M.Dupond, la signature est anonyme grâce à la signature de groupe.
2. 5 Participation à une vente aux enchères
Cette fonction est schématisée figure 14.
- Phase du déroulement : Enchère ; elle fait partie de la troisième étape du procédé; - Niveau de sécurité : Le jeton assure l'authenticité, l'intégrité et la confidentialité de l'ordre d'enchère ;
Précondition : Etre inscrit à la vente, le jeton possède une filiation ;
Objectifs : Soumettre un ordre d'enchère pour remporter la vente ;
Acteur principal : Client ;
Scénario typique : M. Martin participe à la vente aux enchères de la photographie qu'il a choisi avec un prix de départ à 600 euros et un pas à 10 euros. Il est le premier enchérisseur et il s'engage
<Desc/Clms Page number 27>
à enchérir à 610 euros en transmettant un jeton (W999). Au cours de l'enchère, un deuxième client augmente le prix à 620 euros. M.Martin est prêt à mettre plus et clique sur le bouton pour surenchérir à 630 euros. Il transmet alors le jeton d'indice 997, noté W997. En effet, comme décrit précédemment, chaque jeton correspond à une valeur calculée en fonction du prix de départ et du pas de l'enchère.
Dans cette vente, l'indice 999 représente la valeur 610 euros, 998-620,997-630, 996-640,... ;
Un tel processus est schématisé figure 15.
2. 6 Traitement des ordres d'enchères
Cette fonction est schématisé figure 16.
- Phase du déroulement : Enchère ; elle fait partie de la troisième étape du procédé; - Niveau de sécurité : Le jeton assure l'authenticité du client et l'intégrité des données ; - Précondition : Avoir un jeton d'initialisation pour les enchères d'un client particulier sur un article ; - Objectifs : Comparer les ordres d'enchères, enregistrer les ordres et informer de l'évolution des enchères ; - Acteur principal : Client ; - Scénario typique : Lorsque M.Martin clique sur le bouton pour enchérir, un jeton correspondant au prix est envoyé au serveur d'enchères. Côté serveur, le jeton permet de retrouver les informations nécessaires à l'ordre d'enchère, c'est-à-dire sa valeur, son propriétaire (M. Martin) et l'article visé. Pour connaître la position de M. Martin, son ordre est comparé aux ordres des autres clients. La proposition de M. Martin est enregistrée et le prix de la photo est actualisé.
Ce processus est schématisé figure 17.
2. 7 Conclusion de la vente
Cette fonction est schématisé figure 18.
- Phase du déroulement . Conclusion de la vente ; elle comporte la quatrième étape du procédé;
<Desc/Clms Page number 28>
Niveau de sécurité : Identifier le gagnant et lever l'anonymat du gagnant en cas de signature de groupe ; - Objectifs : Déterminer un gagnant et clore la transaction ; - Acteur principal : Client, Vendeur, SA, Tiers de confiance ; - Scénario typique : Le temps de la vente écoulé, le système détermine si M. Dupond a gagné ou non l'enchère en comparant les différentes propositions. L'offre de 800. 000 euros est la plus forte et M. Dupond (anonyme) remporte l'oeuvre d'art. Les autres clients sont prévenus qu'ils ont perdu. Le vendeur est informé que son article a trouvé un acheteur. Le Tiers de Confiance est alors chargé de lever l'anonymat de M. Dupond et de clore la transaction en tant qu'intermédiaire entre M. Dupond et le vendeur. Ce processus est schématisé figure 19.
2. 8 Remarques - Inscription pour la participation à une vente : L'inscription à une vente est liée à une session. Il est donc nécessaire de réinitialiser l'inscription en cas de déconnexion ou de changement de session ; - Usage des certificats : Les certificats d'authentification forte et les certificats anonymes sont multi-usages. Il est donc possible d'utiliser un certificat pour plusieurs ventes sans avoir à renouveler les demandes à chaque vente, sauf en cas de révocation ou d'expiration du certificat; - Propriétés à la demande du certificat anonyme : Lors de la connexion entre un client et le site serveur d'anonymat, la confidentialité et l'intégrité des informations transmises et la garantie d'anonymat du client vis-à-vis de l'extérieur sont assurées par un protocole de communication par exemple SSL ; - Anticipation pour une première participation : La configuration de l'environnement technique du poste client (applet cryptographique signée) et les démarches d'obtention de certificats réclament une préparation à la participation à une vente.
3 Spécification de l'application d'enchères
Cette partie décrit succinctement l'API pour les services de l'application aux niveaux suivants :
<Desc/Clms Page number 29>
Demande d'un certificat anonyme et de participation à une vente ;
Contrôle de demande de participation; - Enchère; - Vérification d'enchère; - Conclusion de la vente.
Les étapes indiquées par une * sont considérées comme basiques dans le cadre du procédé conforme à l'invention.
3. 1 Demande d'un certificat anonyme et de participation à une vente - S'authentifier de manière forte auprès de l'ACA* - Générer les clés* - Envoyer la clé publique à l'ACA* - Obtenir un certificat anonyme auprès de l'ACA* - Générer les jetons* - Stocker les jetons* - Signer le jeton d'initialisation et l'id article* - Transmettre le jeton signé, le certificat et l'id article signé* - Recevoir la confirmation - Afficher la confirmation
3. 2 Contrôle de demande de participation - Récupérer les moyens de vérifier une authentification anonyme auprès de l'ACA* - Recevoir les données de l'applet - Vérifier la signature avec les moyens de l'ACA* - Se connecter à la base de données - Enregistrer les données jeton, certificat, id article - Sélectionner dans la base le prix max de l'article - Transmettre la confirmation
3. 3 Enchère - Actualiser le prix max - Calculer le jeton par rapport au prix supérieur
W, ?
<Desc/Clms Page number 30>
prixsup = prixmax + pas j = (prixsup - prixdedepart)/pas i = nombretotaldejetons - j - Transmettre le jeton* - Recevoir la réponse
3. 4 Vérification d'enchère - Décompter le temps de la vente - Recevoir le jeton (W,)* - Vérifier le jeton (trouver dans la base Wk tel que hl(W,) = Wk)* - Sélectionner les données de la base pour Wk - Sélectionner le prix max de l'id article - Calculer le prix correspondant au jeton reçu W, prix de W, = prix de Wk +(I* pas) - Comparer le prix max au prix de Wi - Enregistrer le prix de W, (UPDATE) - Répondre au client sur sa situation
3. 5 Conclusion de la vente - Détecter la fin de l'enchère - Déterminer l'offre la plus haute - Lever l'anonymat* - Informer l'acheteur gagnant - Informer le vendeur 4 Organisation technique
4. 1 Architecture client - serveur
Cette architecture est schématisée figure 20.
On y retrouve un navigateur Client, un Serveur ACA et un Serveur Se enchères (ces derniers étant chacun associé à une base de données spécifiques) aptes à mettre en oeuvre les étapes précitées.
4. 2 Outils de prototypage : Base de données, serveur d'application et Plug-in Java
La base de données utilisée par les inventeurs pour un prototypage de cette application est une base Oracle 8i. Oracle est un SGBD (système de gestion de bases de données) relationnel édité par la
<Desc/Clms Page number 31>
société du même nom. Oracle dispose d'un langage permettant la définition et la manipulation des données : le langage SQL (Structured Query Language), qui est devenu le langage normalisé dans le domaine des bases de données relationnelles. SQL*PLUS est l'interface utilisateur d'Oracle qui permet d'utiliser interactivement le langage SQL sur une instance Oracle.
Le langage de programmation et les technologies utilisées pour l'implantation sont Java. L'application est gérée par le produit d'IBM WebSphere 3. 5. WebSphere Application Server permet de réaliser des transactions et des interactions Web. Il fournit une plate-forme portable de déploiement d'applications Web Java, axée sur la prise en charge et l'exécution de servlets, de JavaBeans et de fichiers Java Server Pages (JSP). C'est une interface avec le serveur Web pour gérer les requêtes client portant sur les ressources côté serveur et pour les acheminer vers le serveur d'applications en vue de leur traitement. L'outil utilisé dans WebSphere est le moteur de servlet. Il s'exécute à l'intérieur du serveur d'applications et gère les requêtes relatives aux servlets, aux fichiers Java Server Pages (JSP) et aux applications Web qui les contiennent.
Le poste client a été testé sur un système Windows avec le Plugin Java. Le Plug-in (fournit par Sun) permet d'actualiser la version de la JVM du navigateur (IE ou Netscape). Le Java-plugin remplace le Java Runtime par défaut du navigateur par le JRE de Sun.
Bien entendu la présente invention n'est pas limitée au mode de réalisation particulier qui vient d'être décrit mais s'étend à toute variante conforme à son esprit.
REFERENCES [1] G. Ateniese, J. Camenisch, M. Joye, G. Tsudik. A practical and provably secure coalition-resistant group signature scheme. In L.
Bellare, editor, Advances in Cryptology - Crypto 2000, volume 1880 of LNCS, pages 255-270. Springer-Verlag, 2000.
[2] S. Canard, M Girault. Implementing group signature schemes with smart cards. conférence CARDIS 2002.
<Desc/Clms Page number 32>
[3] J. Camenisch, M. Michels. A group signature scheme based on an RSA-variant. Proceedings of Eurocrypt'98, volume 1514 of LNCS.
Springer-Verlag, 1998.
[4] J. Camenisch, M. Stadler. Efficient group signature schemes for large groups. Proceedings of Crypto'97, volume 1296 of LNCS, pages 410-424. Springer-Verlag, 1997.
[5] K. Q. Nguyen, J. Traoré. "An Online Public Auction Protocol Protecting Bidder Privacy". Information Security and Privacy, 5th Australasian Conference-ACISP 2000, pages 427-442. Springer-Verlag, 2000.
[6] J Camenisch, U. Maurer, M. Stadler. Digital payment systems with passive anonymity-revoking trustees. Proceedings of ESORICS'96, volume 1146 of LNCS, pages 33-43. Springer-Verlag, 1996.
[7] J Camenisch, U. Maurer, M. Stadler. Digital payment systems with passive anonymity-revoking trustees. Journal of Computer Security, vol. 5, number 1, IOS Press, 1997.
[8] A. de Solages, J. Traoré. An Efficient fair off-line electronic cash system with extensions to checks and wallet with observers, Proceedings of Financial Crypto'98, volume 1465 of LNCS, pages 275- 295. Springer-Verlag, 1998.
[9] A. de Solages et J. Traoré, Procédé de signature numérique juste, n 98 02197, CNET/02959, dépôt du 24/02/98.
[10] Y. Frankel, Y. Tsiounis, M. Yung. Indirect discourse proofs: achieving fair off-line electronic cash. Proceedings of Asiacrypt'96, volume 1136 of LNCS, pages 244-251. Springer-Verlag, 1996.
[11] Y. Frankel, Y. Tsiounis et M. Yung . "Fair off-line cash made easy". Proceedings of Asiacrypt'98, volume 1514 of LNCS. SpringerVerlag, 1998.

Claims (77)

REVENDICATIONS
1. Procédé d'accès à un service avec authentification rapide et anonymat révocable, caractérisé par le fait qu'il comprend les étapes consistant à : i) identifier et enregistrer un Client (C) et lui fournir des moyens lui permettant de s'authentifier auprès d'une Autorité de Certification Anonyme (ACA), ii)) authentifier le Client auprès de l' Autorité de Certification Anonyme sur la base des moyens fournis en i) et fournir des moyens lui permettant de s'authentifier de manière anonyme auprès d'un Serveur (Se), iii) authentifier le Client par la production d'une signature anonyme et ouvrir et maintenir une session d'authentification anonyme auprès d'un Serveur (Se), et iv) permettre sélectivement un contact entre le Serveur (Se) et l'Autorité de Certification Anonyme (ACA) pour lever l'anonymat du Client (C) sur la base de la signature fournie à l'étape iii).
2. Procédé selon la revendication 1, caractérisé par le fait que l'étape i) comprend la fourniture de l'Autorité de Certification Anonyme (ACA), au client (C), de moyens lui permettant de calculer au moins une signature anonyme.
3. Procédé selon l'une des revendications 1 ou 2, caractérisé par le fait que l'étape i) comprend la fourniture d'une Clé Publique (PK), et d'un Certificat (C).
4. Procédé selon l'une des revendications 1 à 3, caractérisé par le fait que l'étape i) comprend l'identification par l'Autorité de Certification Anonyme (ACA) de la personne physique qui correspond au Client (C).
5. Procédé selon l'une des revendications 1 à 4, caractérisé par le fait qu'elle comprend une sauvegarde par l'Autorité de Certification Anonyme (ACA) de moyens permettant de relier à tout moment le Client (C) à n'importe quelle signature émanant de celui-ci.
<Desc/Clms Page number 34>
6. Procédé selon l'une des revendications 1 à 5, caractérisé par le fait qu'il met en oeuvre une clé privée (SK) et une clé publique (PK) détenue par le Client.
7. Procédé selon l'une des revendications 1 à 6, caractérisé par le fait que la signature du Client met en oeuvre sa clé privée (SK).
8. Procédé selon l'une des revendications 1 à 7, caractérisé par le fait que le Client (C) adresse au Serveur (Se) un message contenant un jeton (W1000), une signature (S), une clé publique (PK) et un Certificat (C).
9. Procédé selon l'une des revendications 1 à 8, caractérisé par le fait que le Client (C) adresse une clé publique (PK) à l'Autorité (ACA) pour l'obtention d'un Certificat (AC).
10. Procédé selon l'une des revendications 1 à 9, caractérisé par le fait qu'il comprend une étape additionnelle d'échange entre l'Autorité de Certification Anonyme (ACA) et le Serveur (Se) préalable à l'étape ii) par laquelle le Serveur (Se) présente à ladite Autorité (ACA) une requête d'obtention de moyens permettant de vérifier l'authentification anonyme fournie par un Client (C).
11. Procédé selon l'une des revendications 1 à 10, caractérisé par le fait que l'étape ii) comprend trois phases : . une première phase dans laquelle le Client (C) calcule un ensemble de données, formé d'une suite de jetons, l'un de ceux-ci permettant d'ouvrir une session, tandis que les autres permettent de la maintenir, . une deuxième phase dans laquelle le Client (C) s'engage fortement sur la suite de jetons après du Serveur, et . une troisième phase de maintien de la session à l'aide de la suite de jetons.
12. Procédé selon la revendication 11, caractérisé par le fait que la première phase est opérée par dialogue entre le Client (C) et l'Autorité de Certification Anonyme (ACA).
13. Procédé selon l'une des revendications 11 à 12, caractérisé par le fait que les deux premières phases sont réalisées à l'aide d'un
<Desc/Clms Page number 35>
navigateur WEB ou d'une application hébergée sur le poste du Client (C), formé le cas échéant d'un terminal portable.
14. Procédé selon l'une des revendications 11 à 13, caractérisé par le fait que la phase de maintien est opérée d'un terminal différent de celui utilisé pour l'ouverture de session.
15. Procédé selon l'une des revendications 11 à 14, caractérisé par le fait que tous les jetons sont à usage unique et fortement dépendants les uns des autres.
16. Procédé selon l'une des revendications 11 à 15, caractérisé par le fait que l'étape de génération des jetons met en oeuvre deux primitives cryptographiques : fonction de hachage et un nombre aléatoire.
17. Procédé selon la revendication 16, caractérisé par le fait que la fonction de hachage H (M) possèdeles propriétés suivantes : - H (M) sur un message M de longueur arbitraire, - le résultat h = H (M) une longueur 1 fixe - Etant donné M, il est facile à calculer h - Etant donné M, il est difficile de trouver un autre message Mo tel que H (M) = H (Mo).
18. Procédé selon l'une des revendications 16 ou 17, caractérisé par le fait que la fonction de hachage est choisie dans le groupe comprenant les algorithmes Message Digest 5 ou Secure Hash Algorithm.
19. Procédé selon l'une des revendications 16 ou 18, caractérisé par le fait que le premier jeton est obtenu en appliquant la fonction de hachage au nombre aléatoire, le deuxième jeton est obtenu en appliquant à nouveau la fonction de hachage au premier jeton obtenu, et ainsi de suite pour obtenir n jetons : H(W0)=W1 ; H(Wu-1)=Wn.
20. Procédé selon l'une des revendications 11 à 19, caractérisé par le fait que la deuxième phase comprend l'obtention d'une signature anonyme d'un jeton d'initialisation Wn permettant l'authentification d'un Client par le Serveur.
<Desc/Clms Page number 36>
21. Procédé selon la revendication 20, caractérisé par le fait que le Serveur mémorise le jeton d'initialisation Wu pour permettre la vérification de la validité de la session.
22. Procédé selon l'une des revendications 11 à 21, caractérisé par le fait que des informations, telles qu'une valeur numéraire, sont associées au jeton d'initialisation.
23. Procédé selon l'une des revendications 11 à 22, caractérisé par le fait qu'à chaque nouvelle authentification le Client (C) transmet au Serveur (Se) un jeton de rang inférieur d'au moins une unité à celui précédemment utilisé.
24. Procédé selon l'une des revendications 11 à 23, caractérisé par le fait qu'après initialisation le Client (C) transmet au Serveur (Se) un jeu W, dont le rang i inférieur est choisi représentatif de la valeur d'une opération, par exemple du nombre de pas d'une enchère.
25. Procédé selon la revendication 24, caractérisé par le fait que le Serveur (Se) vérifie que l'application de la fonction de hachage au jeton reçu correspond au jeton précédemment utilisé.
26. Procédé selon la revendication 25, caractérisé par le fait que l'étape iii) comprend la fourniture, par l'Autorité de Certification Anonyme (ACA), au Serveur (Se), de l'identité physique du Client (C).
27. Procédé selon l'une des revendications 1 à 25, caractérisé par le fait que l'étape iii) comprend une prise de contact du Client (C) par ladite Autorité pour la fermeture de la session selon un protocole contrôle.
28. Procédé selon l'une des revendications 1 à 27, caractérisé par le fait que le droit de production de signature anonyme a une durée de vie limitée.
29. Procédé selon la revendication 28, caractérisé par le fait que le Client (C) s'identifie auprès de ladite Autorité (ACA) à chaque session.
30. Procédé selon l'une des revendications 1 à 29, caractérisé par le fait que l'Autorité de Certification Anonyme (ACA) est confondue avec le Serveur (Se) de sorte que l'identification de manière forte est opérée directement auprès du Serveur (Se).
<Desc/Clms Page number 37>
31. Procédé selon l'une des revendications 1 à 30, caractérisé par le fait qu'il est appliqué à des enchères.
32. Procédé selon la revendication 31, caractérisé par le fait que le jeton d'initialisation envoyé par le Client (C) au Serveur (Se) est associé aux paramètres d'une vente, tels que identifiant de l'article, prix et valeur du pas.
33. Procédé selon l'une des revendications 31 ou 32, caractérisé par le fait que les étapes de surenchérissement par le Client (C) sont opérées par envois successifs de jetons de rang inférieur.
34. Procédé selon l'une des revendications 1 à 33, caractérisé par le fait qu'à l'étape i) l'Autorité (ACA) délivre un Certificat (C) lié à un pseudonyme du Client (C) d'une clé publique fournie par le Client et elle-même associée à une clé privée gardée secrète par le Client (C).
35. Procédé selon la revendication 34, caractérisé par le fait que le pseudonyme est obtenu par chiffrement d'une donnée liée à l'identité du Client.
36. Procédé selon l'une des revendications 34 ou 35, caractérisé par le fait que le Certificat Anonyme comprend des informations limitant la portée du Certificat.
37. Procédé selon la revendication 36, caractérisé par le fait que les informations de limitation sont choisies dans le groupe comprenant : l'identifiant d'au moins un Serveur, l'identifiant d'au moins une session, une date de validité, une adresse de Client.
38. Procédé selon la revendication 37, caractérisé par le fait que pour ouvrir une session le Client (C) envoie au Serveur (Se) un message comprenant un jeton d'initialisation, une clé privée formant signature, une clé publique et un Certificat.
39. Procédé selon l'une des revendications 1 à 38, caractérisé par le fait que l'Autorité (ACA) fournit au Client (C) un Certificat valable pour plusieurs Serveurs (Se).
40. Procédé selon l'une des revendications 1 à 38, caractérisé par le fait que l'Autorité (ACA) fournit au Client un Certificat par Serveur (Se).
<Desc/Clms Page number 38>
41. Procédé selon la revendication 40, caractérisé par le fait que chaque Serveur (Se) fournit un identifiant destiné à l'Autorité (ACA).
42. Procédé selon l'une des revendications 1 à 41, caractérisé par le fait que l'Autorité (ACA) fournit sur requête plusieurs Certificats à un même Client (C) destinés respectivement à des sites de travail différent.
43. Procédé selon l'une des revendications 1 à 42, caractérisé par le fait qu'il met en oeuvre une signature de groupe, par association de plusieurs identifiants et clés privées respectives, à une unique clé publique de groupe.
44. Procédé selon l'une des revendications 1 à 43, caractérisé par le fait qu'il met en oeuvre une signature aveugle.
45. Procédé selon l'une des revendications 43 et 44, caractérisé par le fait que les pouvoirs de levée d'anonymat sont répartis entre au moins deux autorités.
46. Procédé selon l'une des revendications 1 à 45, caractérisé par le fait que l'étape i) comprend la fourniture par l'Autorité de Certification Anonyme (ACA), au Client (C), d'un login/mot de passe.
47. Procédé selon l'une des revendications 1 à 45, caractérisé par le fait que l'étape i) comprend la fourniture par l'Autorité de Certification Anonyme (ACA), au Client (C), d'un certificat standard.
48. Procédé selon l'une des revendications 1 à 45, caractérisé par le fait que l'étape i) comprend la fourniture par une Autorité de Certification, autre que l'Autorité de Certification Anonyme, au Client (C), d'un certificat standard.
49. Procédé selon l'une des revendications 1 à 48, caractérisé par le fait que l'Autorité de Certification Anonyme (ACA) est placée sur un serveur d'anonymat (SA).
50. Procédé selon l'une des revendications 1 à 49, caractérisé par le fait que l'Autorité de Certification Anonyme (ACA) est associée à un Serveur de Certification (SC).
51. Système apte à permettre l'ouverture et le maintien d'une session d'authentification garantissant la non répudiation, caractérisé
<Desc/Clms Page number 39>
par le fait qu'il comprend des moyens adaptés pour la mise en #uvre de trois phases : . une première phase dans laquelle un Client (C) calcule un ensemble de données, formé d'une suite de jetons, l'un de ceux-ci permettant d'ouvrir une session, tandis que les autres permettent de la maintenir, . une deuxième phase dans laquelle le Client s'engage fortement sur la suite de jetons après d'un Serveur (se), et . une troisième phase de maintien de la session à l'aide de la suite de jetons.
52. Système selon la revendication 51, caractérisé par le fait que la première phase est opérée par dialogue entre le Client (C) et l'Autorité de Certification Anonyme (ACA).
53. Système selon l'une des revendications 51 à 52, caractérisé par le fait que les deux premières phases sont réalisées à l'aide d'un navigateur Web ou d'une application hébergée sur le poste du Client (C), formé le cas échéant d'un terminal portable.
54. Système selon l'une des revendications 51 à 53, caractérisé par le fait que la phase de maintien est opérée d'un terminal différent de celui utilisé pour l'ouverture de session.
55. Système selon l'une des revendications 51 à 54, caractérisé par le fait que tous les jetons sont à usage unique et fortement dépendants les uns des autres.
56. Système selon l'une des revendications 51 à 55, caractérisé par le fait que l'étape de génération des jetons met en oeuvre deux primitives cryptographiques : fonction de hachage et un nombre aléatoire.
57. Système selon la revendication 56, caractérisé par le fait que la fonction de hachage H (M) possèdeles propriétés suivantes : - H (M) sur un message M de longueur arbitraire, - le résultat h = H (M) une longueur 1 fixe - Etant donné M, il est facile à calculer h - Etant donné M, il est difficile de trouver un autre message Mo tel que H (M) = H (Mo).
<Desc/Clms Page number 40>
58. Système selon l'une des revendications 56 ou 57, caractérisé par le fait que la fonction de hachage est choisie dans le groupe comprenant les algorithmes Message Digest 5 ou Secure Hash Algorithm.
59. Système selon l'une des revendications 56 ou 58, caractérisé par le fait que le premier jeton est obtenu en appliquant la fonction de hachage au nombre aléatoire, le deuxième jeton est obtenu en appliquant à nouveau la fonction de hachage au premier jeton obtenu, et ainsi de suite pour obtenir n jetons : H(W0)=W1 ; H(Wu- i)=Wn.
60. Système selon l'une des revendications 51 à 59, caractérisé par le fait que la deuxième phase comprend l'obtention d'une signature anonyme d'un jeton d'initialisation Wn permettant l'authentification d'un Client par le Serveur.
61. Système selon la revendication 60, caractérisé par le fait que le Serveur mémorise le jeton d'initialisation Wu pour permettre la vérification de la validité de la session.
62. Système selon l'une des revendications 51 à 61, caractérisé par le fait que des informations, telles qu'une valeur numéraire, sont associées au jeton d'initialisation.
63. Système selon l'une des revendications 51 à 62, caractérisé par le fait qu'à chaque nouvelle authentification le Client (C) transmet au Serveur (Se) un jeton de rang inférieur d'au moins une unité à celui précédemment utilisé.
64. Système selon l'une des revendications 51 à 63, caractérisé par le fait qu'après initialisation le Client (C) transmet au Serveur (Se) un jeu W, dont le rang i inférieur est choisi représentatif de la valeur d'une opération, par exemple du nombre de pas d'une enchère.
65. Système selon la revendication 64, caractérisé par le fait que le Serveur (Se) vérifie que l'application de la fonction de hachage au jeton reçu correspond au jeton précédemment utilisé.
<Desc/Clms Page number 41>
66. Système selon l'une des revendications 51 à 65, caractérisé par le fait que lesdits moyens mettent en #uvre les étapes consistant à i) identifier et enregistrer un Client (C) et lui fournir des moyens lui permettant de s'authentifier auprès d'une Autorité de Certification Anonyme (ACA), ii) authentifier le Client auprès de l'Autorité de Certification Anonyme sur la base des moyens fournis en i) et fournir des moyens lui permettant de s'authentifier de manière anonyme auprès d'un Serveur (Se), iii) authentifier le Client par la production d'une signature anonyme et ouvrir et maintenir une session d'authentification anonyme auprès d'un Serveur (Se), et iv) permettre sélectivement un contact entre le Serveur (Se) et l'Autorité de Certification Anonyme (ACA) pour lever l'anonymat du Client (C) sur la base de la signature fournie à l'étape iii).
67. Système selon l'une des revendications 51 à 66, caractérisé par le fait qu'il est appliqué à des enchères.
68. Système selon la revendication 67, caractérisé par le fait que le jeton d'initialisation envoyé par le Client (C) au Serveur (Se) est associé aux paramètres d'une vente, tels que identifiant de l'article, prix et valeur du pas.
69. Système selon l'une des revendications 67 ou 68, caractérisé par le fait que les étapes de surenchérissement par le Client (C) sont opérées par envois successifs de jetons de rang inférieur.
70. Système selon l'une des revendications 51 à 69, caractérisé par le fait que lesdits moyens mettent en #uvre un message adressé par le Client (C) au Serveur (Se), pour ouvrir une session, comprenant un jeton d'initialisation, une clé privée formant signature, une clé publique et un Certificat.
71. Système selon l'une des revendications 51 à 70, caractérisé par le fait que lesdits moyens mettent en #uvre un certificat anonyme.
<Desc/Clms Page number 42>
72. Système selon l'une des revendications 51 à 70, caractérisé par le fait qu'il met en oeuvre une signature de groupe, par association de plusieurs identifiants et clés privées respectives, à une unique clé publique de groupe.
73. Système selon l'une des revendications 51 à 70, caractérisé par le fait qu'il met en #uvre une signature aveugle.
74. Système selon l'une des revendications 51 et 73, caractérisé par le fait que les pouvoirs de levée d'anonymat sont répartis entre au moins deux autorités.
75. Système selon l'une des revendications 51 à 74, caractérisé par le fait que l'étape i) comprend la fourniture par l'Autorité de Certification Anonyme (ACA), au Client (C), d'un login/mot de passe.
76. Système selon l'une des revendications 51 à 75, caractérisé par le fait que l'étape i) comprend la fourniture par l'Autorité de Certification Anonyme (ACA), au Client (C), d'un certificat standard.
77. Système selon l'une des revendications 51 à 76, caractérisé par le fait que l'étape i) comprend la fourniture par une Autorité de Certification, autre que l'Autorité de Certification Anonyme, au Client (C), d'un certificat standard.
FR0214230A 2002-11-14 2002-11-14 Procede d'acces a un service avec authentification rapide et anonymat revocable et systeme d'ouverture et de maintien de session Pending FR2847401A1 (fr)

Priority Applications (4)

Application Number Priority Date Filing Date Title
FR0214230A FR2847401A1 (fr) 2002-11-14 2002-11-14 Procede d'acces a un service avec authentification rapide et anonymat revocable et systeme d'ouverture et de maintien de session
PCT/FR2003/003380 WO2004047362A1 (fr) 2002-11-14 2003-11-14 Procede et systeme avec authentification, anonymat revocable et non repudiation
EP03782564A EP1561302A1 (fr) 2002-11-14 2003-11-14 Procede et systeme avec authentification, anonymat revocable et non repudiation
US10/534,857 US7840813B2 (en) 2002-11-14 2003-11-14 Method and system with authentication, revocable anonymity and non-repudiation

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
FR0214230A FR2847401A1 (fr) 2002-11-14 2002-11-14 Procede d'acces a un service avec authentification rapide et anonymat revocable et systeme d'ouverture et de maintien de session

Publications (1)

Publication Number Publication Date
FR2847401A1 true FR2847401A1 (fr) 2004-05-21

Family

ID=32187588

Family Applications (1)

Application Number Title Priority Date Filing Date
FR0214230A Pending FR2847401A1 (fr) 2002-11-14 2002-11-14 Procede d'acces a un service avec authentification rapide et anonymat revocable et systeme d'ouverture et de maintien de session

Country Status (4)

Country Link
US (1) US7840813B2 (fr)
EP (1) EP1561302A1 (fr)
FR (1) FR2847401A1 (fr)
WO (1) WO2004047362A1 (fr)

Families Citing this family (68)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP4250429B2 (ja) * 2003-01-24 2009-04-08 キヤノン株式会社 連鎖型署名作成装置、及びその制御方法
US9412123B2 (en) 2003-07-01 2016-08-09 The 41St Parameter, Inc. Keystroke analysis
US7860243B2 (en) * 2003-12-22 2010-12-28 Wells Fargo Bank, N.A. Public key encryption for groups
US8495361B2 (en) * 2003-12-31 2013-07-23 International Business Machines Corporation Securely creating an endorsement certificate in an insecure environment
US7644278B2 (en) * 2003-12-31 2010-01-05 International Business Machines Corporation Method for securely creating an endorsement certificate in an insecure environment
US10999298B2 (en) 2004-03-02 2021-05-04 The 41St Parameter, Inc. Method and system for identifying users and detecting fraud by use of the internet
US20060010072A1 (en) * 2004-03-02 2006-01-12 Ori Eisen Method and system for identifying users and detecting fraud by use of the Internet
AU2004201058B1 (en) * 2004-03-15 2004-09-09 Lockstep Consulting Pty Ltd Means and method of issuing Anonymous Public Key Certificates for indexing electronic record systems
WO2004100496A2 (fr) * 2004-09-02 2004-11-18 Pisaramedia Oy Protocole de messagerie ends a recuperation et a securite retroactive
US8402141B2 (en) * 2004-09-28 2013-03-19 International Business Machines Corporation Gracefully reestablishing an expired browser session
US7661128B2 (en) * 2005-03-31 2010-02-09 Google Inc. Secure login credentials for substantially anonymous users
JP2007004461A (ja) * 2005-06-23 2007-01-11 Nec Corp サービス提供システム、アウトソーシング業者装置、サービス提供方法およびプログラム
CN1937496A (zh) * 2005-09-21 2007-03-28 日电（中国）有限公司 可延展伪名证书系统和方法
US8874477B2 (en) 2005-10-04 2014-10-28 Steven Mark Hoffberg Multifactorial optimization system and method
US8938671B2 (en) 2005-12-16 2015-01-20 The 41St Parameter, Inc. Methods and apparatus for securely displaying digital images
US11301585B2 (en) 2005-12-16 2022-04-12 The 41St Parameter, Inc. Methods and apparatus for securely displaying digital images
EP1964306B1 (fr) * 2005-12-19 2012-06-20 Telecom Italia S.p.A. Schema de signature de groupe d'efficacite renforcee en particulier dans une procedure conjointe
US8171293B2 (en) * 2005-12-30 2012-05-01 Apple Inc. Receiver non-repudiation via a secure device
WO2007095691A1 (fr) * 2006-02-24 2007-08-30 Commonwealth Scientific And Industrial Research Organisation Authentification anonyme
US8151327B2 (en) 2006-03-31 2012-04-03 The 41St Parameter, Inc. Systems and methods for detection of session tampering and fraud prevention
US7958544B2 (en) 2006-07-21 2011-06-07 Google Inc. Device authentication
ATE464612T1 (de) * 2006-08-04 2010-04-15 Rolf Zahnd Verfahren zur anonymen analyse authentifizierender identitäts-codes eines benutzers oder eines objekts
GB0621189D0 (en) * 2006-10-25 2006-12-06 Payfont Ltd Secure authentication and payment system
US8635681B2 (en) * 2007-02-02 2014-01-21 Telcordia Technologies, Inc. Method and system to authorize and assign digital certificates without loss of privacy, and/or to enhance privacy key selection
US8443191B2 (en) 2007-04-09 2013-05-14 Objective Interface Systems, Inc. System and method for accessing information resources using cryptographic authorization permits
WO2008146667A1 (fr) * 2007-05-24 2008-12-04 Nec Corporation Système d'authentification anonyme et procédé d'authentification anonyme
US7877331B2 (en) * 2007-09-06 2011-01-25 King Fahd University Of Petroleum & Minerals Token based new digital cash protocols with combined blind digital signature and pseudonym authentication
US9060012B2 (en) * 2007-09-26 2015-06-16 The 41St Parameter, Inc. Methods and apparatus for detecting fraud with time based computer tags
US8838803B2 (en) * 2007-12-20 2014-09-16 At&T Intellectual Property I, L.P. Methods and apparatus for management of user presence in communication activities
US8380981B2 (en) 2008-05-16 2013-02-19 Objective Interface Systems, Inc. System and method that uses cryptographic certificates to define groups of entities
NZ589966A (en) * 2008-05-16 2014-01-31 Objective Interface Systems Inc System and method that uses cryptographic certificates to define groups of entities
US9390384B2 (en) * 2008-07-01 2016-07-12 The 41 St Parameter, Inc. Systems and methods of sharing information through a tagless device consortium
US9621341B2 (en) * 2008-11-26 2017-04-11 Microsoft Technology Licensing, Llc Anonymous verifiable public key certificates
US8458477B2 (en) * 2008-12-01 2013-06-04 Novell, Inc. Communication with non-repudiation
US8806214B2 (en) 2008-12-01 2014-08-12 Novell, Inc. Communication with non-repudiation and blind signatures
KR20100066169A (ko) * 2008-12-09 2010-06-17 한국전자통신연구원 익명 인증을 이용한 개인 정보 관리 시스템 및 방법
US9112850B1 (en) 2009-03-25 2015-08-18 The 41St Parameter, Inc. Systems and methods of sharing information through a tag-based consortium
KR20120030092A (ko) * 2009-05-20 2012-03-27 코닌클리케 필립스 일렉트로닉스 엔.브이. 휴대가능한 이용자 평판을 인에이블하기 위한 방법 및 디바이스
US9608826B2 (en) * 2009-06-29 2017-03-28 Jpmorgan Chase Bank, N.A. System and method for partner key management
US8688591B2 (en) * 2009-08-06 2014-04-01 International Business Machines Corporation Anonymous separation of duties with credentials
US8862879B2 (en) * 2009-10-13 2014-10-14 Sergio Demian LERNER Method and apparatus for efficient and secure creating, transferring, and revealing of messages over a network
WO2011047085A2 (fr) * 2009-10-13 2011-04-21 Certimix, Inc. Procédé et appareil de création, de transfert et de publication efficaces et sécurisés de messages sur un réseau
KR101284114B1 (ko) * 2009-11-18 2013-07-10 한국전자통신연구원 익명 ｉｄ 관리 장치 및 그 방법, 익명 ｉｄ 관리 시스템 및 이를 이용한 서비스 제공 방법
FR2960671B1 (fr) * 2010-06-01 2020-01-10 Institut Telecom-Telecom Paris Tech Procede de securisation de donnees numeriques et d'identites notamment au sein de processus utilisant des technologies de l'information et de la communication
US9361597B2 (en) 2010-10-19 2016-06-07 The 41St Parameter, Inc. Variable risk engine
US10754913B2 (en) 2011-11-15 2020-08-25 Tapad, Inc. System and method for analyzing user device information
US9571481B1 (en) * 2011-11-30 2017-02-14 Amazon Technologies, Inc. Once only distribution of secrets
US10433161B2 (en) * 2012-01-30 2019-10-01 Telefonaktiebolaget Lm Ericsson (Publ) Call handover between cellular communication system nodes that support different security contexts
US9633201B1 (en) 2012-03-01 2017-04-25 The 41St Parameter, Inc. Methods and systems for fraud containment
US9160535B2 (en) * 2012-03-19 2015-10-13 Dell Inc Truly anonymous cloud key broker
US9521551B2 (en) 2012-03-22 2016-12-13 The 41St Parameter, Inc. Methods and systems for persistent cross-application mobile device identification
EP2880619A1 (fr) 2012-08-02 2015-06-10 The 41st Parameter, Inc. Systèmes et procédés d'accès à des enregistrements via des localisateurs de dérivé
WO2014078569A1 (fr) 2012-11-14 2014-05-22 The 41St Parameter, Inc. Systèmes et procédés d'identification globale
EP2974116B1 (fr) 2013-03-15 2018-10-31 EntIT Software LLC Envoi de données chiffrées à un fournisseur de services
FR3006782A1 (fr) * 2013-06-11 2014-12-12 France Telecom Procede et systeme de delegation d'un calcul d'une valeur de couplage bilineaire a un serveur de calcul
US10902327B1 (en) 2013-08-30 2021-01-26 The 41St Parameter, Inc. System and method for device identification and uniqueness
CN103607284B (zh) * 2013-12-05 2017-04-19 李笑来 身份认证方法及设备、服务器
US9779174B2 (en) * 2014-05-11 2017-10-03 Sap Se Framework for anonymous reporting of social incidents
US10091312B1 (en) 2014-10-14 2018-10-02 The 41St Parameter, Inc. Data structures for intelligently resolving deterministic and probabilistic device identifiers to device profiles and/or groups
US10498537B2 (en) * 2016-08-01 2019-12-03 Institute For Development And Research In Banking Technology (Drbt) System and method for providing secure collaborative software as a service (SaaS) attestation service for authentication in cloud computing
US10796591B2 (en) * 2017-04-11 2020-10-06 SpoonRead Inc. Electronic document presentation management system
US10798129B2 (en) 2017-07-10 2020-10-06 Ebay Inc. Constraint-based multiuse certificates
US11223605B2 (en) * 2018-02-05 2022-01-11 Onboard Security, Inc. Method and system for connected vehicle communication
US11164206B2 (en) * 2018-11-16 2021-11-02 Comenity Llc Automatically aggregating, evaluating, and providing a contextually relevant offer
FR3091107A1 (fr) * 2018-12-24 2020-06-26 Orange Procédé et système de génération de clés pour un schéma de signatures anonymes
PT115479B (pt) 2019-04-29 2021-09-15 Mediceus Dados De Saude Sa Sistema de computador e método de operação para gerir dados pessoais anonimizados
US10790990B2 (en) * 2019-06-26 2020-09-29 Alibaba Group Holding Limited Ring signature-based anonymous transaction
US11451519B2 (en) * 2019-11-25 2022-09-20 Electronics And Telecommunications Research Institute Anonymous credential authentication system and method thereof

Family Cites Families (22)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US6055518A (en) * 1996-02-01 2000-04-25 At&T Corporation Secure auction systems
US5815665A (en) * 1996-04-03 1998-09-29 Microsoft Corporation System and method for providing trusted brokering services over a distributed network
EP0804003A3 (fr) * 1996-04-26 2000-11-15 Canon Kabushiki Kaisha Procédé de signature numérique et système de communication
US6397329B1 (en) * 1997-11-21 2002-05-28 Telcordia Technologies, Inc. Method for efficiently revoking digital identities
US6363365B1 (en) * 1998-05-12 2002-03-26 International Business Machines Corp. Mechanism for secure tendering in an open electronic network
JP2001202013A (ja) * 2000-01-21 2001-07-27 Nec Corp 匿名参加権限管理システム
US7383206B2 (en) * 1999-02-19 2008-06-03 Ariba, Inc. Method and apparatus for multiple variable bidding in an online auction
AU4442601A (en) * 2000-03-17 2001-09-24 Decode Genetics Ehf Automatic identity protection system with remote third party monitoring
DE60114833T2 (de) * 2000-03-24 2006-04-13 Dategrity Corp., Bellevue Überprüfbare, geheime mischung von verschlüsselten daten wie z. b. elgamal-verschlüsselte daten für gesicherte mehrinstanzwahlen
US20030158960A1 (en) * 2000-05-22 2003-08-21 Engberg Stephan J. System and method for establishing a privacy communication path
US7360080B2 (en) * 2000-11-03 2008-04-15 International Business Machines Corporation Non-transferable anonymous credential system with optional anonymity revocation
US7251833B2 (en) * 2000-12-29 2007-07-31 International Business Machines Corporation Digital media delivery with local cache and streaming tokens
US20020087473A1 (en) * 2000-12-29 2002-07-04 Shlomi Harif System, method and program for creating an authenticatable, non-repudiatable transactional identity in a heterogeneous network
US8005965B2 (en) * 2001-06-30 2011-08-23 International Business Machines Corporation Method and system for secure server-based session management using single-use HTTP cookies
US20030014631A1 (en) * 2001-07-16 2003-01-16 Steven Sprague Method and system for user and group authentication with pseudo-anonymity over a public network
US20030028470A1 (en) * 2001-07-26 2003-02-06 International Business Machines Corporation Method for providing anonymous on-line transactions
US7234059B1 (en) * 2001-08-09 2007-06-19 Sandia Corporation Anonymous authenticated communications
GB2380368B (en) * 2001-09-27 2005-06-22 Ibm A method and system for communication via a computer network
US7392390B2 (en) * 2001-12-12 2008-06-24 Valve Corporation Method and system for binding kerberos-style authenticators to single clients
US20030190046A1 (en) * 2002-04-05 2003-10-09 Kamerman Matthew Albert Three party signing protocol providing non-linkability
US20080301298A1 (en) * 2002-07-29 2008-12-04 Linda Bernardi Identifying a computing device
WO2005074551A2 (fr) * 2004-01-30 2005-08-18 Rabenold Nancy J Systeme de soumission anonyme

Non-Patent Citations (5)

* Cited by examiner, † Cited by third party
Title
BYOUNGCHEON LEE; KWANGJO KIM; JOONGSOO MA: "Efficient Public Auction with One-Time Registration and Public Verifiability", INDOCRYPT 2001, SECOND INTERNATIONAL CONFERENCE ON CRYPTOLOGY IN INDIA, 16 December 2001 (2001-12-16) - 20 December 2001 (2001-12-20), Indian Institute of Technology, Madras, Chennai, India, pages 162 - 174, XP002247413, Retrieved from the Internet <URL:http://citeseer.nj.nec.com/cs> [retrieved on 20030704] *
KOBAYASHI K; MORITA H: "EFFICIENT SEALED-BID AUCTION BY USING ONE-WAY FUNCTIONS", IEICE TRANSACTIONS ON FUNDAMENTALS OF ELECTRONICS, COMMUNICATIONS AND COMPUTER SCIENCES, INSTITUTE OF ELECTRONICS INFORMATION AND COMM. ENG., vol. e84-A, no. 1, 1 January 2001 (2001-01-01), TOKYO, JP, pages 289 - 294, XP001006551 *
RIVEST R L ET AL: "PAY WORD AND MICROMINT: TWO SIMPLE MICROPAYMENT SCHEMES", SECURITY PROTOCOLS. INTERNATIONAL WORKSHOP PROCEEDINGS, XX, XX, 1997, pages 69 - 87, XP000677143 *
SUZUKI K ; KOBAYASHI K ; MORITA H: "Efficient sealed-bid auction using hash chain", INFORMATION SECURITY AND CRYPTOLOGY - ICISC 2000. THIRD INTERNATIONAL CONFERENCE. PROCEEDINGS (LECTURE NOTES IN COMPUTER SCIENCE VOL.2015, SPRINGER VERLAG), 9 December 2000 (2000-12-09), Seoul, South Korea, pages 183 - 191, XP002247412, ISBN: 3-540-41782-6 *
ZHANG N ET AL: "Anonymous public-key certificates for anonymous and fair document exchange", IEE PROCEEDINGS: COMMUNICATIONS, INSTITUTION OF ELECTRICAL ENGINEERS, GB, vol. 147, no. 6, 11 December 2000 (2000-12-11), pages 345 - 350, XP006014002, ISSN: 1350-2425 *

Also Published As

Publication number Publication date
US20060155985A1 (en) 2006-07-13
US7840813B2 (en) 2010-11-23
WO2004047362A1 (fr) 2004-06-03
EP1561302A1 (fr) 2005-08-10

Similar Documents

Publication Publication Date Title
FR2847401A1 (fr) Procede d&#39;acces a un service avec authentification rapide et anonymat revocable et systeme d&#39;ouverture et de maintien de session
EP2441207B1 (fr) Procédé cryptographique d&#39;authentification anonyme et d&#39;identification séparée d&#39;un utilisateur
EP1368930B1 (fr) Authentification cryptographique par modules ephemeres
WO2003056750A2 (fr) Systeme cryptographique de signature de groupe
FR3041195A1 (fr) Procede d&#39;acces a un service en ligne au moyen d&#39;un microcircuit securise et de jetons de securite restreignant l&#39;utilisation de ces jetons a leur detenteur legitime
WO2011117486A1 (fr) Infrastructure non hierarchique de gestion de bi-cles de securite de personnes physiques
WO2003061193A1 (fr) Procede et dispositif de signature anonyme au moyen d&#39;une cle privee partagee
FR2937484A1 (fr) Procede de signature numerique en deux etapes
EP1908215A1 (fr) Procédé de contrôle de transactions sécurisées mettant en oeuvre un dispositif physique unique à bi-clés multiples, dispositif physique, système et programme d&#39;ordinateur correspondants
EP1612991A1 (fr) Procédé et système de vote électronique en réseau à haute sécurité
WO2007012583A1 (fr) Procede de controle de transactions securisees mettant en oeuvre un dispositif physique unique, dispositif physique, systeme, et programme d&#39;ordinateur correspondants
CN110533417B (zh) 一种数字资产管理装置、发行方法及系统
KR100985660B1 (ko) 사용자 신뢰성 확립 방법 및 컴퓨터 판독가능 매체
Cha et al. A blockchain-based privacy preserving ticketing service
FR3046271A1 (fr) Deuxieme authentification dynamique d&#39;une signature electronique utilisant un module materiel securise
EP1466304A1 (fr) Procede cryptographique de revocation a l&#39;aide d&#39;une carte a puce
EP3262553A1 (fr) Procede de transaction sans support physique d&#39;un identifiant de securite et sans jeton, securise par le decouplage structurel des identifiants personnels et de services
WO2021122186A1 (fr) Procédé et dispositif de contrôle d&#39;accès anonyme à une plateforme collaborative d&#39;anonymisation
Soni et al. PAKE PROTOCOL WITH OTSP AND IMAGE BASED PASSWORD AUTHENTICATION.
CA2831167C (fr) Infrastructure non hierarchique de gestion de bi-cles de securite de personnes physiques ou d&#39;elements (igcp/pki)
US20240205013A1 (en) Privacy preserving authentication augmented with physical biometric proof
EP4241190A1 (fr) Procede d&#39;authentification securise par le decouplage structurel des identifiants personnels et de services
JP2005005778A (ja) 認証装置及び認証方法
EP3672193A1 (fr) Procédé et système d&#39;authentification d&#39;un terminal client par un serveur cible, par triangulation via un serveur d&#39;authentification
Mitsunaga Cryptographic Protocols for Secure Electronic Commerce