FR2949932A1 - Procede cryptographique d'abonnement anonyme a un service - Google Patents

Abstract

L'invention concerne un procédé d'abonnement anonyme d'une entité utilisatrice (U ) auprès d'au moins un service (S ) fourni par une entité fournisseuse de service (SP). L'entité utilisatrice (U ) envoie (120) à l'entité fournisseuse (SP) au moins une première donnée d'engagement (C ), générée à partir au moins d'une clé secrète (sk ) propre à ladite entité utilisatrice et d'au moins un nombre aléatoire (s'), et au moins une données d'indentification (S ) associée à ce service (S ). En retour, l'entité fournisseuse (SP) envoie (130) à l'entité utilisatrice (U ) au moins un reçu (S,σ ) généré à partir d'au moins une partie des données d'engagement (C ) et de la donnée d'identification (S ) reçue, ce reçu (S,σ ) permettant à l'entité utilisatrice d'accéder audit service (S ). L'invention concerne également un procédé d'accès anonyme à un service suite à un tel procédé d'abonnement anonyme, ainsi qu'un système cryptographique pour mettre en oeuvre un tel procédé.

Description

Procédé cryptographique d'abonnement anonyme à un service

L'invention concerne un procédé cryptographique permettant à un utilisateur de s'abonner anonymement à un service. Le domaine de la cryptographie a connu récemment un développement important. Diverses tâches cryptographiques peuvent être effectuées comme la signature d'un message par un émetteur, l'authentification de l'émetteur d'un message ou l'identification de l'émetteur d'un message par une unité vérificatrice.

Ces tâches contribuent à garantir certains niveaux de sécurité à des services qui les utilisent. Cependant, il peut exister des tâches qui requièrent un certain niveau d'anonymat. Par exemple, un utilisateur peut souhaiter souscrire, de façon anonyme, à un ou plusieurs services auprès d'un fournisseur de services. Par la suite, ce même utilisateur peut souhaiter requérir et bénéficier de ces services de façon anonyme sans que quiconque, y compris le fournisseur de services, ne puisse l'identifier. Ce type de besoin, l'anonymat, est lié à une problématique de protection de la vie privée (on parle habituellement de "privacy"). La plupart des solutions d'abonnement existantes ne considèrent pas le cas où l'utilisateur souhaite rester anonyme et ne répondent donc pas à la problématique exposée ci-avant de façon satisfaisante. Les tâches cryptographiques précitées ne permettent pas non plus de répondre à cette problématique. Il existe certaines solutions d'abonnement, par prépaiement, permettant à l'utilisateur de payer un abonnement pour un certain nombre d'accès pendant une période de temps considérée, tout en permettant à l'utilisateur de conserver son anonymat dans une certaine limite. Une de ces solutions (appelée Anonymask ) consiste à créer, auprès d'un tiers, un compte permettant au client de payer de façon anonyme le fournisseur. Une autre solution consiste à obtenir, de façon anonyme et aveugle, la certification d'une suite de jetons correspondant à un nombre précis d'accès autorisés, lesquels seront par la suite envoyés un par un au fournisseur. Dans toutes ces solutions, bien qu'elles aillent dans le sens d'une amélioration de l'anonymat de l'utilisateur en ce qui concerne la facturation des services, le fournisseur de services a connaissance des services souscrits par le client. Un anonymat total n'est donc pas garanti. De plus ces solutions ne permettent pas un abonnement illimité d'une durée limitée, puisqu'elles ne concernent que des cas de souscription d'un abonnement d'un certain nombre de tickets pouvant être consommés a priori sans limite de temps. Il n'existe donc à ce jour aucune solution permettant à un utilisateur d'obtenir des services auprès d'un fournisseur de services tout en conservant son anonymat, notamment par rapport à ce fournisseur de services. A fortiori, lorsque le fournisseur de services souhaite analyser l'utilisation de ses services par un io utilisateur, il n'existe aucune solution permettant une telle analyse sans forcément lever l'anonymat de l'utilisateur. La présente invention vient améliorer la situation. En particulier, un objet de la présente invention est la mise en oeuvre d'un procédé cryptographique d'abonnement et d'utilisation anonymes d'un service is permettant à un utilisateur de souscrire anonymement un service auprès d'un fournisseur de services et de l'utiliser ultérieurement de façon anonyme, sans que ce fournisseur de services ne puisse identifier cet utilisateur. Un autre objet de l'invention consiste à permettre un certain niveau d'analyse, par un fournisseur de services, de l'utilisation d'un service par un 20 utilisateur anonyme, sans lever l'anonymat de ce dernier. Elle propose à cet effet un procédé d'abonnement anonyme d'une entité utilisatrice à au moins un service fourni par une entité fournisseur de service, dans lequel l'entité utilisatrice envoie à l'entité fournisseur au moins une première donnée d'engagement, générée à partir au moins d'une clé secrète propre à ladite 25 entité utilisatrice et d'au moins un nombre aléatoire, et au moins une données d'identification associée audit au moins un service, et dans lequel l'entité fournisseur envoie à l'entité utilisatrice au moins un reçu généré à partir d'au moins une partie des données d'engagement et de la donnée d'identification reçue, ledit reçu permettant à l'entité utilisatrice d'accéder audit service. 30 De préférence, l'étape d'envoi du reçu comprend la génération d'un reçu primaire à partir d'au moins une partie des données d'engagement et de la donnée d'identification reçue, la signature dudit reçu primaire en un reçu signé et la transmission dudit reçu signé vers l'entité utilisatrice.

Avantageusement, l'entité utilisatrice envoie à l'entité fournisseuse une deuxième donnée d'engagement prouvant que l'entité utilisatrice connaît la clé secrète qui lui est propre et ledit nombre aléatoire et l'entité fournisseur vérifie la deuxième donnée d'engagement avant d'envoyer le reçu à l'entité utilisatrice.

Préférentiellement, l'entité utilisatrice vérifie le reçu transmis par l'entité fournisseur. Dans un mode particulier de réalisation dans lequel l'entité utilisatrice s'abonne successivement à plusieurs services, pour chaque service auquel l'entité utilisatrice s'abonne, au moins une donnée d'engagement, générée dans l'entité io utilisatrice en fonction de la clé secrète, d'au moins un nombre aléatoire et d'une donnée d'identification associée audit service, est envoyée à l'entité fournisseur, et un reçu , généré dans l'entité fournisseur en fonction de ladite donnée d'engagement reçue, est envoyé à l'entité utilisatrice. Un tel mode d'abonnement successif empêche tout profiling. is Dans un autre mode particulier de réalisation dans lequel l'entité utilisatrice s'abonne simultanément à plusieurs services, la donnée d'identification des services est générée à partir des données d'identification respectives de chacun desdits services, et l'entité utilisatrice est apte à accéder à l'un desdits services fournis par l'entité fournisseur au moyen dudit reçu. 20 Dans un mode préféré de réalisation, dans lequel le reçu est stocké dans l'entité utilisatrice, le procédé comporte les étapes ultérieures suivantes : - l'entité utilisatrice envoie à l'entité fournisseur des premières données d'abonnement complémentaire générées à partir au moins du reçu stocké, de la clé secrète propre à ladite entité utilisatrice, du nombre aléatoire et d'au moins une 25 donnée d'identification associée à au moins un service supplémentaire ; - l'entité fournisseur envoie à l'entité utilisatrice des deuxièmes données d'abonnement complémentaire générées à partir d'au moins une partie des premières données d'engagement complémentaires reçues ; - le reçu est mis à jour, dans l'entité utilisatrice, au moyen desdites deuxièmes 30 données d'abonnement complémentaire. Dans un mode de réalisation avantageux, les premières données d'abonnement complémentaire comportent au moins un premier élément de preuve généré à partir au moins du reçu stocké et d'un nombre aléatoire, les deuxièmes données d'abonnement complémentaire comportent au moins un reçu complémentaire généré à partir au moins du premier élément de preuve, et la mise à jour du reçu comprend la mémorisation dudit reçu complémentaire dans l'entité utilisatrice. De préférence, dans ce mode de réalisation avantageux, quand le reçu stocké dans l'entité utilisatrice comporte un reçu signé, le reçu complémentaire est alors généré par signature d'un reçu complémentaire primaire, lequel est lui-même généré à partir au moins du premier élément de preuve, et la mise à jour du reçu comprend alors la mémorisation, dans l'entité utilisatrice, du reçu complémentaire à la place du reçu signé. L'utilisation de reçus signés permet de renforcer io l'anonymat de l'entité utilisatrice. Dans un mode préféré de réalisation, le procédé comporte une étape de vérification du reçu complémentaire par l'entité utilisatrice, ce qui permet de garantir l'authenticité de celui-ci. Dans un autre mode de réalisation avantageux dans lequel le reçu stocké is dans l'entité utilisatrice comporte un reçu signé, les premières données d'abonnement complémentaire comportent au moins un premier élément de preuve généré en fonction de ce reçu signé, les deuxièmes données d'abonnement complémentaire comportent des données témoins générées à partir de ce premier élément de preuve, et la mise à jour du reçu comprend alors 20 la génération d'un reçu complémentaire à partir d'une partie au moins des données témoins reçues et la mémorisation, dans l'entité utilisatrice, du reçu complémentaire à la place du reçu signé. De préférence, dans ce mode de réalisation avantageux dans lequel les premières données d'abonnement complémentaire comportent un deuxième 25 élément de preuve généré à partir d'au moins une donnée d'information associée à un service, ce deuxième élément de preuve est vérifié dans l'entité fournisseuse avant de transmettre les deuxièmes données d'abonnement complémentaire à l'entité utilisatrice. La présente invention propose par ailleurs un procédé d'accès anonyme 30 d'une entité utilisatrice à au moins un service fourni par une entité fournisseur de services, dans lequel l'entité utilisatrice présente un reçu obtenu au moyen d'un procédé d'abonnement anonyme comme décrit ci-avant. Dans ce procédé d'accès, l'entité utilisatrice envoie au moins un premier élément de preuve généré en fonction du dudit reçu et l'entité fournisseur donne accès au service à l'entité utilisatrice seulement si le premier élément de preuve est validé. La présente invention propose aussi un système cryptographique pour l'abonnement anonyme d'un utilisateur à au moins un service, ce système comprenant au moins une entité utilisatrice et une entité fournisseur de services arrangée pour fournir ledit service, et étant apte à mettre en oeuvre le procédé cryptographique d'abonnement ci-avant. Les procédés et système, objets de l'invention, seront mieux compris à la lecture de la description et à l'observation des dessins ci-après dans lesquels : - la figure 1 est un schéma synoptique illustrant un système cryptographique utilisé par l'invention ; - la figure 2 illustre les étapes d'un procédé d'abonnement anonyme selon l'invention ; - la figure 2A illustre les étapes d'un procédé d'abonnement anonyme successivement à deux services selon l'invention ; - la figure 3A illustre les étapes d'un procédé d'abonnement complémentaire selon l'invention ; - la figure 3B illustre les étapes d'un procédé d'abonnement complémentaire selon un premier mode de réalisation de l'invention ; - la figure 3C illustre les étapes d'un procédé d'abonnement complémentaire selon un deuxième mode de réalisation de l'invention ; et - la figure 4 illustre les étapes d'un procédé d'utilisation anonyme d'un service selon la présente invention.

On se réfère d'abord à la figure 1 sur laquelle est illustré un système cryptographique 1 utilisé par la présente invention.

Sur cette figure 1, une pluralité d'entités utilisatrices forment un groupe GU d'utilisateurs. Ces entités utilisatrices U; peuvent s'abonner auprès d'une entité fournisseur de services SP afin d'accéder à un certain nombre t de services S,,..., St. Il est souhaitable que cet abonnement soit effectué dans le cadre du respect de la vie privée de l'entité U;, c'est-à-dire que l'entité U; puisse s'abonner et accéder ultérieurement aux services souscrits de manière anonyme, sans que l'entité fournisseur de services SP ne puisse tracer l'utilisation du service par l'entité U;. Le système peut présenter par ailleurs une entité identificatrice O, dont la fonction est d'identifier l'entité utilisatrice U;, dans le but par exemple de lui facturer le service fourni par l'entité fournisseur SP, sans que l'entité identificatrice O ne connaisse la nature de ce service, ou simplement en cas d'abus d'un service. Le système peut enfin présenter une entité de gestion M, dont le rôle peut être d'initialiser des paramètres et autres clés, publiques ou secrètes, nécessaires au procédé de la présente invention et affectés aux entités SP et O, et d'autre part io d'enregistrer les entités U; dans le groupe GU des utilisateurs. Les différentes entités présentées ci-avant doivent être aptes à effectuer un certain nombre de calculs cryptographiques. Pour ce faire, de telles entités peuvent comporter des moyens de calculs comme un processeur, un microprocesseur, ou toute autre moyen permettant d'effectuer un calcul ou de is générer une valeur aléatoire.

On se réfère maintenant à la figure 2, laquelle illustre les étapes d'un procédé d'abonnement anonyme 100 selon l'invention ; Dans le procédé cryptographique de la présente invention, des signatures 20 de type "Camenisch-Lysyanskaya" sont utilisées. Outre les propriétés classiques des signatures électroniques, ces signatures possèdent, entre autres, les deux propriétés suivantes :

1) Il existe un algorithme permettant au signataire d'une telle signature de 25 signer un engagement sur certaines valeurs sans pour autant connaître les valeurs engagées. 2) Il existe une preuve de connaissance d'une signature sur un bloc de message sans révéler ni la signature, ni les valeurs signées.

30 Dans ce qui suit, on utilise à titre purement illustratif une signature basée sur le problème "LRSW" proposée dans l'article Signature schemes and anonymous credentials from bilinear maps de Jan Camenisch et Anna Lysyanskaya (CRYPTO, volume 3152 de Lecture Notes in Computer Science, pages 56-72. Springer, 2004). 5 En effet, cette solution permet de proposer un procédé supplémentaire permettant à un utilisateur connaissant une signature sur des valeurs engagées d'obtenir auprès du signataire un complément d'information lui permettant d'agréger des valeurs supplémentaires. La solution "LRSW" utilise des formes bilinéaires, c'est-à-dire une fonction e telle que e:GxG-*G*, où:

- la fonction e est bilinéaire, i.e. VP,QE G,da,bE Z,e(P°,Qb) =e(P,Q)ab, io - la fonction e non dégénérée, i.e. P,QE G tels que e(P,Q) ≠ 1 où 1 est l'identité de G.

On peut définir ici un algorithme e.Setup qui à partir d'un paramètre de sécurité k retourne les paramètres (q, G, G*, g,, e) décrivant une courbe elliptique 15 e:GxG_*G*telle que:

- G et G* soient deux groupes d'ordre premier q = 8(1 k), - chaque élément de G et G* soit représentable par une unique chaîne de bits, 20 - g, soit un générateur de G.

Le protocole de signature Camenisch-Lysyanskaya de type LRSW comporte les algorithmes suivants :

25 • CL.Setup : Cet algorithme permet au signataire d'initialiser le système afin de permettre la signature d'un engagement contenant au maximum t valeurs. Il fournit en sortie une clé publique du système pkcL ainsi qu'une clé secrète de signataire Sksignataire• CL.Engagement : Cet algorithme permet à l'utilisateur de calculer un 30 engagement sur des valeurs, ainsi qu'une preuve de connaissance sur ces valeurs et la bonne construction de l'engagement. Il reçoit en entrée un certain nombre de valeurs so,..., si, ainsi qu'une clé publique pkcL et fournit en sortie un engagement S et une preuve de connaissance rr sur les valeurs so,..., si . • CL. Sign : Cet algorithme permet de signer un engagement. Il reçoit ainsi, en entrée, un engagement S, ainsi que la clé publique du système pkcL et la clé secrète du signataire sksignataire, et fournit en sortie une signature a. • CL.PoK : Cet algorithme permet à une personne connaissant une signature et des valeurs engagées dans un engagement de prouver qu'elle connaît bien ces valeurs ainsi qu'une signature de celles-ci. Il reçoit en entrée une signature a et des valeurs so,..., si et fournit en sortie une signature aveuglée d, une preuve de connaissance sur les valeurs so,..., s,, ainsi que deux nombres aléatoires r, r'. • CL.Verify : Cet algorithme permet à n'importe quel individu ou entité de vérifier io la validité d'une signature. Il reçoit pour cela, en entrée, une signature aveuglée 6 et une preuve de connaissance Yi sur des valeurs, ainsi qu'une clé publique pkcL et retourne une valeur validée ou non validée .

Lors d'une première étape d'initialisation 110, l'entité de gestion M 15 échange, d'une part, des données avec l'entité identificatrice O afin de définir une clé publique de groupe pkG. L'entité de gestion M peut, d'autre part, échanger des données avec l'entité fournisseur de services SP afin de définir une clé publique secondaire chpk, par exemple une clé publique déléguée ou une clé publique de fonction caméléon dont la clé secrète correspondante pourra être détenue par 20 l'entité SP.

Cette étape 110 d'initialisation commence par une sous-étape 111 d'initialisation des schémas comprenant l'initialisation des paramètres publics, par exemple ceux d'une signature Camenish-Lysyanskaya. Elle comprend ensuite une 25 sous-étape 113 d'inscription effectuée pour chaque nouvelle entité utilisatrice U; et qui permet l'inscription de cette nouvelle entité utilisatrice U; au service d'abonnement. Ces étapes peuvent se dérouler de la façon suivante :

Dans la sous-étape d'initialisation 111, l'entité fournisseur SP, en tant 30 que signataire, initialise le système pour un schéma de signature particulier, par exemple un schéma de signature Camenisch-Lysyanskaya, afin de permettre la signature d'un engagement contenant un certain nombre de valeurs. Par exemple, à titre d'exemple non limitatif, l'engagement signé contient ci-après t+3 valeurs, où 15 20 t est le nombre de services que l'entité SP peut fournir, accompagné des trois paramètres d'identification et d'anonymisation que sont la clé secrète de l'utilisateur et deux valeurs aléatoires la cachant).

On applique alors le protocole CL.Setup suivant :

1) L'entité SP génère les paramètres de courbe elliptique q, G, G*, g1, e. 2) L'entité SP choisit une clé secrète sksignataire = (x, y, {z;}) pour tout i allant de 1 à t+3 ; io 3) L'entité SP calcule les paramètres publics suivants, liés à sa clé secrète, pour tout i allant de 1 à t+3 : X=gx, Y=gY, {Z;=gz'} {W;=YZ'}

4) L'entité SP choisit ho, ... , ht+3 des générateurs du groupe G en fonction de la signature Camenish-Lysyanskaya qui sera utilisée. Dans notre cas, on fixera h;=Z; pour tout i allant de 0 à t+3. Dans le cas de signatures à base d'ACJT (du nom des auteurs Ateniese, Camenisch, Joye et Tsudik) ou de BBS (du nom des auteurs Boneh, Boyen et Shacham), les générateurs seraient choisis aléatoirement parmi les générateurs de G.

5) Enfin, l'entité SP obtient la clé publique pkcL du système selon : pkcL = (q,G,G*,g1 g2, e, X=g1X, Y=g1Y, {Zi=g1Z'}, {Wi=Yz'}; {h,} 1 <_i <_t+3).

25 Ainsi, à l'issue de ce protocole, on obtient une clé publique du système pkcL, ainsi qu'une clé secrète sksignataire de l'entité fournisseur SP. La valeur t, correspondant au nombre de services proposés par l'entité fournisseur SP, peut être augmentée à tout moment par l'entité fournisseur SP signataire. Il suffit alors de générer aléatoirement de nouveaux z; et d'ajouter à la clé publique les valeurs 30 Z; et W; correspondantes.

Ensuite, lors de la sous-étape 113 d'inscription, un nouvel utilisateur U; s'inscrit au service d'abonnement. Cette sous-étape peut par exemple se dérouler de la façon suivante : 30 l0 1) Toute nouvelle entité utilisatrice U; coopère avec l'entité de gestion M afin d'effectuer un protocole pour rejoindre le groupe d'utilisateurs GU. Un tel protocole peut par exemple consister en un protocole d'ajout à un groupe partageant une s signature de groupe ou encore en un protocole d'enregistrement tel que décrit dans la demande de brevet française FR953953 du même déposant. A l'issue de ce protocole, l'entité utilisatrice U; obtient alors une clé secrète sku liée à un certificat d'appartenance AG,u.

io 2) Ensuite, l'unité de gestion M communique des données d'identification IdU; de l'entité s'enregistrant et le certificat AG,u obtenus précédemment à l'entité identificatrice O, par exemple servant à la facturation, qui les stocke.

Ensuite, lors d'une deuxième étape 120 de requête en abonnement, l'entité 15 utilisatrice U; envoie à l'entité fournisseur de services SP des données d'engagement lui permettant de s'abonner à au moins un des services S1,...,St fournis par l'entité fournisseur SP.

Pour ce faire, une première donnée d'engagement Csku est générée lors 20 d'une sous-étape de génération 121 par l'entité utilisatrice U; à partir au moins : - d'une clé secrète sku qui lui est propre, obtenue par exemple lors de la sous-étape d'inscription 113 précédemment décrite, afin d'assurer le lien entre le service souscrit et l'entité utilisatrice ; - d'au moins un nombre aléatoire s', voire de deux nombres aléatoire ro' et 25 s', afin de garantir l'anonymat de l'entité utilisatrice.

En fonction de l'objectif choisi, la génération de cette première donnée d'engagement Csku peut être réalisée de plusieurs façons. Afin de respecter un anonymat très fort, cela peut être fait selon le protocole d'engagement suivant : 1) Les nombres aléatoires ro' et s' sont choisis dans Zq 2) La première donnée d'engagement Csku est alors calculée selon : C=hskähr°,hs' s~ o i z Une deuxième donnée d'engagement Trsku, permettant de prouver que l'entité utilisatrice connaît bien sku, ro' et s' tels que Csku est bien construit, peut s être optionnellement générée lors d'une sous-étape de génération 123. Cette deuxième donnée d'engagement peut prendre la forme d'une preuve de connaissance sur un produit de logarithmes discrets, par exemple, de la façon suivante : 10 Trsku = PK{(X,ç,P) : Csku= hô h1çh2P}. Des exemples de preuve de connaissance sur un produit de logarithme discrets (x tel que y=gAx) sont illustrés dans les articles suivants : - C.P. Schnorr : "Efficient identification and signatures for smart cards" (In 15 Crypto'89, volume 435 of LNCS, pages 239-252. Springer, 1989) ; - M. Girault, G. Poupard, and J. Stern : "On the fly authentication and signature schemes based on groups of unknown order". (J. Cryptology, 19(4):463{487, 2006). 20 D'autres exemples de preuve de connaissance peuvent être utilisés ici, par exemple une preuve de connaissance d'une représentation (x,z tels que y=g"xh"z et éventuellement beaucoup plus que 2 éléments), comme décrit dans les articles suivants : - Stefan A. Brands : "An efficient off-line electronic cash system based on 25 the representation problem" (Technical report, Amsterdam, The Netherlands, The Netherlands, 1993). - I. Damgard and E. Fujisaki : "A Statistically-Hiding Integer Commitment Scheme Based on Groups with Hidden Order" (Asiacrypt 2002, volume 2501 of LNCS, pages 143-159. Springer-Verlag, 2002). 30 On peut encore employer une preuve d'égalité de logarithme discret (x tel que y=gAx et t=h"x) comme décrit dans l'article de D. Chaum and T.P.

Pedersen : "Transferred cash grows in size". (In Eurocrypt'92, volume 658 of LNCS, pages 390-407. Springer, 1992).

A titre d'exemple, cette preuve Trsku peut être effectuée de la façon suivante • Prendre aléatoirement trois valeurs w1, w2 et w3 • Calculer t=how1h1w2h2w3 • Calculer c=H(hoIIh111h211CskulItIlm) où m est un message quelconque, éventuellement nul. io • Calculer v1=w1-csku, v2=w2-cro' et v3=w3-cs' • La preuve Trsku est alors le quadruplet (c,v1,v2,v3) Cette preuve est dite valide si et seulement si c= H(hoIIh111h211Cskull Csku c hov1hiv2h2v311m). La vérification de cette preuve consiste donc à vérifier cette égalité. 15 Il est avantageux de choisir les générateurs ho, h1 et h2 de manière à s'intégrer au mieux dans la signature Camenisch-Lysyanskaya choisie, par exemple : ho=g; h1=Z, ;h2=Z2.

20 Dans le cas d'une signature Camenisch-Lysyanskaya différente, par exemple pour les solutions basées sur ACJT ou BBS, les générateurs seront pris aléatoirement parmi les générateurs du groupe G.

L'entité utilisatrice envoie alors, lors d'une sous-étape de transmission 125, 25 la première donnée d'engagement Csku, éventuellement accompagnée de la deuxième donnée d'engagement Trsku, ainsi que de la ou des données d'identification s; correspondant au(x) service(s) auquel l'entité utilisatrice veut souscrire. La ou les données d'identification s; peuvent constituer un message servant à générer une signature sanitizable de groupe, sur le principe de ce qui 30 est décrit dans la demande de brevet française FR953953 du même déposant, ou bien d'une signature de groupe standard (par exemple ACJT ou BBS). En retour, l'entité fournisseur SP va confirmer le bon déroulement du processus

d'abonnement anonyme, lors d'une étape 130 de confirmation de l'abonnement, en construisant un reçu destiné à l'entité utilisatrice.

De la même manière que pour la première donnée d'engagement, le reçu peut être construit de manière différente en fonction de l'objectif fixé. Une solution permettant de répondre à plusieurs niveaux d'anonymat, en fonction de la façon de l'utiliser, est possible grâce aux signatures Camenisch-Lysyanskaya. D'autres possibilités existent cependant comme par exemple l'utilisation d'une signature d'accumulateur dynamique, par exemple en s'inspirant de la solution proposée par Au et al. pour un procédé de monnaie électronique anonyme dans l'article Practical anonymous divisible e-cash from bounded accumulators , Cryptology ePrint Archive, Report 2007/459, 2007. Pour ce faire, l'entité fournisseur SP peut tout d'abord, si une deuxième donnée d'engagement rrsku a été générée et envoyée au cours de l'étape 120,

1s vérifier cette deuxième donnée d'engagement rrsku, lors d'une sous-étape de vérification 131. Dans notre exemple, la preuve (c,v1,v2,v3) sur l'engagement Csku est dite valide si et seulement si c= H(hoIIh1IIh2IICskull Csku c ho~'hiv2h2v311m). La vérification de cette preuve consiste donc à vérifier cette égalité. 20 L'entité fournisseur SP va ensuite générer un reçu primaire S à partir de la première donnée d'engagement reçue Csku, ainsi que des données d'identification s; reçues, lors d'une sous-étape 133. Cette sous-étape peut prendre la forme suivante : 25 1) Un nombre aléatoire s" est choisi dans Zq 2) Un reçu primaire S est alors calculé selon : 1+3 S =Csku . hZ"fJ h i=3 30 Le reçu primaire S obtenu peut être envoyé tel quel à l'entité utilisatrice U;. Cependant, il est préférable de le signer, lors d'une sous-étape 135 de signature, ce qui permet alors de fournir une validation, par l'entité fournisseur SP, du fait 30 que celle-ci autorise l'entité utilisatrice à accéder ultérieurement au(x) service(s) requis.

Une telle sous-étape de signature 135 peut prendre la forme suivante : 1) Un nombre a est choisi aléatoirement dans Zq ; 2) On calcule les variables a et b, telles que a=g° et b=ay 3) On calcule, pour tout i allant de 1 à I, les variables A; et B; telles que A;=az' et B;=A1 10 4) On calcule la variable c telle que c=axS °Xy.

5) On obtient alors le reçu signé ar tel que : ar = (a, {A;}, b, {B;}, c; 1 i ≤I).

1s On remarque ici que le reçu primaire S correspond à la sortie de l'algorithme CL.Engagement recevant en entrée la clé publique pkcL, les valeurs aléatoires s=s'+s" et ro', ainsi que les données d'identification so,...,s,. Ceci est obtenu tout en garantissant que l'entité fournisseur SP signataire n'apprenne ni la clé secrète sku de l'entité utilisatrice U;, ni l'aléa ro' que l'entité utilisatrice U; a 20 choisi pour cacher sa clé, ni l'aléa s=s'+s" construit conjointement.

Le reçu, soit sous sa forme primaire S, soit de préférence sous sa forme signée ar, est alors envoyé à l'entité utilisatrice U; lors d'une sous-étape de transmission 137. Il est aussi envisageable d'envoyer à l'entité utilisatrice U; le 25 reçu à la fois sous sa forme primaire S et sous sa forme signée ar.

L'entité utilisatrice U;, munie d'un tel reçu, pourra alors l'utiliser ultérieurement pour accéder au service Si auquel elle vient de s'abonner de façon anonyme. Lorsque le reçu signé ar est transmis lors de l'étape 137, une étape 140 de vérification de ce reçu signé ar peut avantageusement être réalisée, dans l'entité 510 utilisatrice U;, dans le but de vérifier si le reçu signé est valide avant de le stocker dans cette entité utilisatrice U;.

Cette vérification peut s'effectuer selon le protocole suivant :

1) Si le reçu signé 6r a été transmis lors de l'étape 137 sans être accompagné du reçu primaire S, la variable s est calculée telle que s = s' + s". On peut ainsi recalculer le reçu primaire S. 2) On construit une preuve de connaissance en utilisant l'algorithme suivant, correspondant à l'algorithme CL.PoK de preuve de connaissance selon la signature Camenisch-Lysyanskaya : a) les nombres r et r' sont choisis aléatoirement dans Zq ; b) les valeurs â,b,c,c sont calculées telles que : â = ar,b = br,c = cr,c = c r, 15 c) pour tout i allant de 1 à I, on calcule les valeurs Ai,Bz telles que : AZ = AZ r ,Bi = B. r d) On obtient alors la signature aveuglée 6 = (â, {Ai }, b., {Bi }, c;l i l) e) La preuve de connaissance partielle sur les s; est alors construite de la façon suivante : 20 - On calcule les valeurs vX=e(X, ), vxy=e(X, b ) et vs=e(g, c ) - Pour tout i allant de 1 à I, on calcule VXy,;=e(X, Bz ) - On calcule alors la preuve de connaissance partielle Yi= sur r et les s; telle que : = PK (ço,ç~,...,ç~,P): (vs)P =vx(v 25 f) On obtient alors la preuve de connaissance (6 , ,r,r').

3) On vérifie alors si le reçu signé 6r est valide, à partir de la clé publique pkcL, de la signature aveuglée et de la preuve de connaissance partielles , avec le protocole suivant correspondant à 10 l'algorithme de vérification CL.Verify selon la signature Camenisch-Lysyanskaya: a) On calcule les valeurs vX=e(X, â ), vxy=e(X, b ) et vs=e(g, ê) b) Pour tout i allant de 1 à I, on calcule VXy,;=e(X, Bz ) c) On vérifie que est valide, de manière similaire à la validation effectuée lors de l'étape 131 ci-avant. d) On vérifie les égalités suivantes : e(â ,Zi)=e(g, À), e(â ,Y)=e(g,b), e(Az ,Y)=e(g, Bz ) e) Si Yi est valide et les égalités ci-dessus sont toutes vérifiées, alors le reçu signé 6r est valide. Si l'une de ces conditions n'est pas remplie, le reçu signé 6r n'est pas valide et le procédé s'arrête ici.

is Une fois le reçu signé 6r validé, il est stocké par l'entité utilisatrice U; pour être utilisé ultérieurement afin d'accéder au(x) service(s) associé(s). Dans un premier mode de réalisation présentant un anonymat fort, le procédé 100 est répété pour chaque abonnement à un service Si. Ainsi, pour chaque service S,, S2, etc. auquel s'abonne l'entité utilisatrice U;, un reçu respectif 20 6r1, 6r2, etc. est stocké par l'entité utilisatrice U;. Lorsque l'entité utilisatrice U; désirera accéder ultérieurement à un service particulier Si, elle utilisera alors le reçu 6r; correspondant. Un tel premier mode de réalisation est illustré à la figure 2A. Cette figure montre un procédé d'abonnement successif à deux services S, et S2 25 Dans cette figure 2A, une première étape 100' d'abonnement anonyme à un premier service S, est d'abord réalisée, similairement au procédé 100 de la figure 2. En particulier, cette étape 100' comporte une étape 120' d'envoi de premières données d'engagement Cskui et rrskul et d'une donnée d'identification si du service S,, depuis l'entité utilisatrice U; vers l'entité fournisseur de services SP, 30 similairement à l'étape 120 ci-avant. S'ensuit une étape 130' de renvoi d'un reçu signé cri à l'entité utilisatrice U; similaire à l'étape 130 ci-avant. Une étape de vérification similaire à l'étape 140 ci-avant peut alors éventuellement être effectuée (non illustrée).

Une deuxième étape 100" d'abonnement anonyme à un deuxième service S2 est ensuite réalisée, toujours similairement au procédé 100 de la figure 2. Cette étape 100" comporte également une étape 120" d'envoi de deuxièmes données d'engagement CSku2 et Trsku2 et d'une donnée d'identification s2 du service S2, depuis l'entité utilisatrice U; vers l'entité fournisseur de services SP, similairement à l'étape 120 ci-avant, ainsi qu'une étape 130" de renvoi d'un reçu signé 6r2 à l'entité utilisatrice U; similaire à l'étape 130 ci-avant. Une étape de vérification similaire à l'étape 140 ci-avant peut également être effectuée. A l'issue de cette deuxième étape 100", l'entité utilisatrice U; dispose de io deux reçus signés art et 6r2, ce qui lui permet d'accéder à l'un des services S, et S2. Cet exemple impliquant deux services est bien entendu non limitatif. L'homme du métier peut extrapoler cet exemple à un nombre quelconque de services auxquels s'abonner, de façon successive. Un tel mode de réalisation est particulièrement avantageux dans le sens où 15 il empêche en particulier tout profiling de la part de l'entité SP fournissant les services, c'est-à-dire que cette dernière ne peut ni lier, ni analyser l'utilisation d'un service fourni par un utilisateur. On entend ici par profiling toute technique qui consiste à analyser, grâce à divers moyens, le "profil" des visiteurs d'un site afin de déterminer leurs motivations, leurs centres d'intérêt, leur tranche d'âge, leur 20 profession, etc. en vue de mieux répondre à leurs attentes soit grâce à une modification en temps réel des pages du site soit pour leur prochaine visite. En effet, grâce à l'engagement choisi, l'entité SP fournissant les services n'est pas capable de relier deux abonnements entre eux. Cet anonymat fort implique en contrepartie de stocker une signature par service abonné, donc 25 potentiellement de nombreuses signatures, et d'effectuer une instance de procédé 100 par service, donc potentiellement de nombreux échanges lors de l'abonnement entre entités utilisatrice et fournisseur de services.

Dans un deuxième mode de réalisation présentant un anonymat un peu 30 moins fort que le premier mode de réalisation, une instance du procédé 100 est répétée par série de services auxquels on désire s'abonner. Ainsi, pour une première série de services S,, S2,..., Sk auxquels s'abonne l'entité utilisatrice U;, un unique reçu 6r,1 est stocké par cette entité utilisatrice U;, et ainsi de suite pour chaque série suivante de services souscrits.

Dans ce deuxième mode de réalisation, l'entité SP fournisseur de services connaîtra le lien entre les services d'une même série (un même utilisateur est intéressé par tous les services d'une série). Néanmoins l'entité SP ne sera pas capable de faire le lien entre différentes séries de services, la possibilité de profiling partiel offerte à l'entité SP se trouve donc limitée. En outre, l'entité SP ne saura pas non plus relier cet abonnement à son utilisation ultérieure, ce qui renforce la protection de la vie privée de l'utilisateur. L'avantage de ce deuxième mode de réalisation est de limiter le nombre de signatures à stocker par l'entité utilisatrice U;, ainsi que le nombre d'échanges nécessaires entre les entités utilisatrice U; et l'entité fournisseur SP lors de l'abonnement, au détriment d'une perte limitée en anonymat. Si l'utilisateur connaît d'emblée la liste exhaustive des services auxquels il veut souscrire, ce deuxième mode de réalisation permet de ne stocker qu'un reçu unique obtenu 1s avec une seule instance du procédé 100. Cependant, l'utilisateur peut être amené à s'abonner à des services fournis par l'entité SP à différents moments dans le temps. Il peut certes le faire de façon individuelle, selon le premier mode de réalisation, mais il peut aussi utiliser un procédé d'abonnement complémentaire. 20 La figure 3A illustre, de façon générale, un tel procédé d'abonnement complémentaire 200 selon l'invention.

Lors d'une première étape 210, des premières données d'abonnement 25 complémentaires {P} sont générées dans l'entité utilisatrice U;, afin de prouver que celle-ci est bien déjà abonnée à un ensemble de services S,,...,S,, et envoyées à l'entité fournisseur SP.

Lors d'une deuxième étape 220, des deuxièmes données d'abonnement 30 complémentaires {P'} sont générées dans l'entité fournisseur SP, grâce aux premières données d'abonnement complémentaires {P}, et envoyées à l'entité utilisatrice U;. 10 Une étape de reconstruction 230 est alors effectuée, dans l'entité utilisatrice U;, pour reconstruire un nouveau reçu R, caractérisant les anciens services S1,...,S1 ainsi que les services nouvellement souscrits 51+1,...,Sk, à partir de l'ancien reçu stocké dans l'entité utilisatrice U; et des données complémentaires {P'} transmises lors de l'étape 220.

La figure 3B illustre un procédé d'abonnement complémentaire 300 selon un premier mode de réalisation du procédé général d'abonnement complémentaire 200 de la présente invention. Dans ce premier mode de réalisation du procédé général d'abonnement complémentaire 200, dans lequel un reçu a été sauvegardé dans l'entité utilisatrice U;, soit sous sa forme primaire S, soit sous sa forme signée 6r,, les étapes sont effectuées comme suit : 15 1) L'étape 310 d'envoi d'éléments de preuve comporte une première sous-étape 311 de génération d'éléments de preuve, qui se déroule selon le protocole suivant : a) On récupère le reçu primaire S, soit directement parce qu'il a été 20 sauvegardé lors du procédé d'abonnement initial, soit à partir du reçu signé sauvegardé lors du procédé d'abonnement initial, tel que : 1+3 S=h0skuhroh s hsi-3 1 z i=3 b) Le nombre T. est choisi aléatoirement dans Zq c) On calcule P = 25 d) On calcule un premier élément de preuve S'= S . h1r e) On génère le deuxième élément de preuve rr suivant : 1+3 76=PK (E,x,p',P,So,...,ç1):E=CL.Sign(hoxhlnhzsT7his, ,.i,Pkcz,)AS'=h1P hoxhIP i=33 f) Le nombre ro' prend la valeur du nombre î et est conservé comme partie privée par l'entité utilisatrice. 1+3 i=3 30 20

2) L'étape 310 est alors complétée par une deuxième sous-étape de transmission 313 d'éléments de preuve, composée des premier et deuxième éléments de preuve (i.e. P=(S',rr)), à l'entité fournisseur SP. Les données d'identification s,+,,...,5k des nouveaux services S1+1,...,Sk à souscrire sont en outre envoyées à l'entité fournisseur SP. 3) Une étape 320 de génération d'un nouveau reçu s'ensuit, laquelle peut comporter initialement, et de façon optionnelle, une sous-étape de vérification 321 du deuxième élément de preuve rr de manière similaire à la validation effectuée

io lors de l'étape 131 ci-avant. 4) L'étape 320 comporte une sous-étape 323 de génération d'un nouveau reçu complémentaire S, se décomposant comme suit : 15 a) Un nombres est choisi aléatoirement dans Zq

k+3 b) On calcule un reçu complémentaire primaire S = S'. f i=1+4 5) Avantageusement, on peut signer S pour obtenir un reçu complémentaire signé 6 au cours d'une sous-étape 325 de signature, de la même façon que ce qui a été fait lors de l'étape 135 du procédé d'abonnement 100 ci-avant. Un reçu complémentaire, soit sous sa forme primaire S , soit avantageusement dans sa version signée 6 , ainsi qu'un nombre aléatoires sont ainsi obtenus.

25 6) L'étape 320 est alors complétée par une sous-étape de transmission 327 du reçu complémentaire obtenu et du nombre aléatoire associé à l'entité utilisatrice U;.

7) L'étape 320 est alors suivie d'une étape 330 de reconstruction. Dans le cas 30 où un reçu complémentaire signé 6 est généré et transmis lors de l'étape précédente, une étape optionnelle 331 de vérification de ce reçu complémentaire signé 6 peut être ensuite effectuée dans l'entité utilisatrice. 15 20 Cette sous-étape de vérification 331 peut s'effectuer selon le protocole suivant :

a) La variable s est calculée telle que s = s + . b) On construit une preuve de connaissance en utilisant l'algorithme CL.PoK de preuve de connaissance selon la signature Camenisch-Lysyanskaya. Cette étape est équivalente à l'étape 140 du procédé 100, dans laquelle on remplace le reçu signé 6r du procédé 100 par le reçu complémentaire signé 6 et les valeurs par les io valeurs

On obtient en conséquence une signature aveuglée 6 , une preuve de connaissance, et deux nombres aléatoires r et r', similairement à l'étape 140 du procédé 100.

c) On vérifie alors si le reçu complémentaire signé 6 est valide, à partir de la clé publique pkcL, de la signature aveuglée 6 et de la preuve de connaissance partiellek , grâce à l'algorithme de vérification CL.Verify selon la signature Camenisch-Lysyanskaya tel que décrit dans l'étape de vérification 140 du procédé 100.

8) L'étape de reconstruction 330 se termine alors par une sous-étape 333 de mise à jour où le reçu stocké précédemment dans l'entité utilisatrice est remplacé par le nouveau reçu. 25 Si le reçu complémentaire a été transmis sous sa forme primaire S lors de l'étape 327, ce reçu S peut être stocké à la place de l'ancien reçu S mémorisé dans l'entité utilisatrice U;, pour utilisation ultérieure. Si par contre, le reçu complémentaire a été transmis sous sa forme signée 6 lors de l'étape 327, et qu'il est jugé valide lors de l'étape 331, alors ce reçu 30 complémentaire signé 6 est stocké à la place de l'ancien reçu signé 6r dans l'entité utilisatrice U;. La nouvelle valeur de s, calculée à partir de la variable reçue, est par ailleurs aussi stockée à la place de l'ancienne variable s dans l'entité utilisatrice U;.

On voit bien que dans ce mode de réalisation, le reçu complémentaire est élaboré dans l'entité fournisseur SP et transmis à l'entité utilisatrice U1, où il peut être éventuellement vérifié. Un tel procédé d'abonnement complémentaire 300 est avantageux quand on cherche à réduire autant que possible le besoin de stockage nécessaire dans les entités utilisatrices U1. Par ailleurs, ce procédé d'abonnement complémentaire peut être reproduit aussi souvent que nécessaire, puisque le reçu est simplement mis à jour au cours de ce procédé 300.

io La figure 3C illustre un procédé d'abonnement complémentaire 400 selon un deuxième mode de réalisation du procédé général d'abonnement complémentaire 200 de la présente invention.

Dans ce deuxième mode de réalisation du procédé d'abonnement 15 complémentaire, deux algorithmes supplémentaires de protocole entre l'entité utilisatrice et l'entité fournisseur sont ajoutés aux algorithmes de la signature Camenisch-Lysyanskaya de type LRSW déjà évoqués ci-avant. Il s'agit de : • CL.Add : Cet algorithme permet à un signataire de générer un témoin pour des valeurs à ajouter s1+1,...,sk à partir d'une signature aveuglée 6 et de la preuve 20 de connaissance correspondante . • CL.Agg : Cet algorithme permet à un utilisateur d'ajouter les valeurs s1+1,...,sk à la signature a qu'il connaît déjà, à partir de la connaissance de cette signature a, des valeurs déjà engagées d'un témoin généré par l'algorithme CL.Add et des valeurs aléatoires r et r' choisies pour générer la signature aveuglée d et la 25 preuve de connaissance correspondante .

Lorsque l'on utilise ces deux algorithmes supplémentaires, il est préférable de choisir les nombres aléatoires r et r' parmi les nombres inversibles de Zq , c'est-à-dire dans Zq au lieu de simplement Zq . Lorsque le nombre q est premier, 30 il suffit de choisir r et r' différents de 0.

Dans ce deuxième mode de réalisation du procédé 200, dans lequel le reçu a été sauvegardé dans l'entité utilisatrice, soit sous sa forme primaire S, soit sous sa forme signée 6r, un procédé 400 est décrit présentant les étapes suivantes : 1) Le procédé 400 démarre par une étape 410 d'envoi d'éléments de preuve à l'entité fournisseur SP. Cette étape 410 comporte une première sous-étape 411 de génération d'éléments de preuve, durant laquelle on construit une preuve de connaissance des données identifiant les services S,,...,S, déjà souscrits, en utilisant l'algorithme CL.PoK de preuve de connaissance selon la signature io Camenisch-Lysyanskaya.

On obtient en conséquence une signature aveuglée 6 correspondant à un premier élément de preuve, une preuve de connaissance Ji correspondant à un deuxième élément de preuve, et deux nombres aléatoires r et r', similairement à is l'étape 140 du procédé 100.

Les nombres aléatoires r et r' sont conservés comme partie privée par l'entité utilisatrice U;.

20 2) L'étape 410 d'envoi d'éléments de preuve est alors complétée par une deuxième sous-étape de transmission 413 d'éléments de preuves, dans laquelle les premier et deuxième éléments de preuve 6 etir sont envoyés à l'entité fournisseur SP. Les données d'identification s,+1,...,5k des nouveaux services S,+,,...,Sk à souscrire sont en outre envoyées à l'entité fournisseur SP. 25 3) S'ensuit une étape 420 d'envoi d'un témoin, laquelle peut comporter initialement, et de façon optionnelle, une sous-étape de vérification 421 du deuxième élément de preuve Yi similairement à l'étape 131 ci-avant.

30 4) L'étape 420 peut ensuite comporter une sous-étape 423 de vérification de la validité du premier élément de preuve, à savoir de la signature aveuglée reçue , à partir de la clé publique pkcL, de la signature aveuglée 6 et du deuxième élément de preuve, grâce à l'algorithme de vérification CL.Verify selon la signature 20 Camenisch-Lysyanskaya tel que décrit dans l'étape de vérification 140 du procédé 100 :

- Si la signature aveuglée 6 n'est pas valide, le procédé 400 s'arrête ici. - Si la signature aveuglée 6 est valide, elle présente alors la forme suivante : 5) S'ensuit alors une sous-étape 425 de génération d'un témoin pour les io valeurs de services à ajouter, selon le protocole suivant : a) On calcule alors un premier élément témoin et selon la formule suivante : k _t (1js,zi+3) ' c = a z=!+1 15 b) On calcule également, pour tout i allant de 1+4 à k+3, les éléments témoins suivants : 4=a' z et Bi = A~y c) Le témoin des nouvelles valeurs de service s1+1,...,5k est alors(ct,{ÀUId,l+4 <_ i <_ k+3). 6) L'étape 420 est alors complétée par une sous-étape de transmission 427 de l'intégralité de ce témoin (ct,{ÂZ},{Éj) à l'entité utilisatrice U;. 7) Le procédé 400 se termine par une étape 430 de reconstruction du reçu, 25 réalisée par l'entité utilisatrice U;. Cette étape 430 comporte d'abord une sous-étape 431 de génération d'un nouveau reçu signé a', selon le protocole suivant : a) On calculect = ct1/r,, et pour tout i allant de 1+4 à k+3 : AZ = AZ1/r' et Bi = BZ1/r'

b) On décompose le reçu signé o- =(a,{Ai},b,{Bi},c) stocké dans l'entité utilisatrice U;, afin de calculer la variable c telle que c'= c . c c) On obtient ainsi un nouveau reçu signé a' tel que 6-'= (ai,{Ai}l<i<k,c'), basé sur l'engagement

k+3 S'=h skuhr°h s h. i=3

8) Ce nouveau reçu signé a' peut alors être stocké, lors d'une sous-étape de mémorisation 433, à la place de l'ancien reçu signé a, dans l'entité utilisatrice U; afin d'être utilisé ultérieurement pour accéder à l'un ou plusieurs des services S-i,...,Sk.

On voit bien que dans ce mode de réalisation, le nouveau reçu est élaboré dans l'entité utilisatrice U;, et que l'entité fournisseur SP se contente de transmettre un témoin à celle-ci. Un tel procédé d'abonnement complémentaire 400 est avantageux quand l'entité fournisseur dispose de peu de moyens de

1s calcul au regard du nombre d'entités utilisatrices désirant obtenir des services. En outre, avec ce procédé, le besoin de stockage des signatures est réduit du côté des entités utilisatrices U;.

Encore une fois, un tel procédé d'abonnement complémentaire 400 peut être reproduit aussi souvent que nécessaire, puisque le reçu est simplement mis à 20 jour au cours de ce procédé 400.

Une fois qu'une entité utilisatrice U; est abonnée à un ensemble de services 51,...,Sk selon l'une des méthodes décrites ci-avant, elle peut utiliser n'importer lequel de ces services, par exemple le service Si, tout en restant anonyme.

Il convient de noter ici que lorsque d'autres signatures de type Camenisch-

25 Lysyanskaya sont utilisées, comme par exemple les signatures basées sur la signature ACJT telle que décrite dans A signature scheme with efficient protocols de Jan Camenisch et Auna Lysyanskaya. (In Stelvio Cimato, Clemente Galdi, and Giuseppe Persiano, SCN, volume 2576 of Lecture Notes in Computer Science, pages 268-289. Springer, 2002), ou celles basées sur la signature BBS,

30 les deux algorithmes supplémentaires CL.Add et CL.Agg ne sont pas forcément nécessaires. Ils peuvent être remplacés par d'autres algorithmes équivalents que l'homme du métier pourra choisir en fonction de la signature considérée.

Par contre, les entrées et les sorties des autres algorithmes seront identiques à celles décrites ci-avant, à une exception près : l'algorithme de preuve de connaissance de signature CL.PoK ne retournera pas, dans ces autres propositions, les aléas r et r' qui sont spécifiques à la solution "LRSW" décrite présentement.

La figure 4 illustre un exemple de procédé 500 d'accès anonyme à un service selon la présente invention. Dans l'exemple qui suit, on considère qu'un reçu signé 6r a été obtenu et io stocké dans une entité utilisatrice grâce à un procédé d'abonnement et/ou d'abonnement complémentaire tel que décrit ci-avant. Lors d'une première étape 510, l'entité utilisatrice U; utilise les données d'identification s,,...,s, associées respectivement aux services 5,,...,S1 auxquels cette entité est abonnée, ainsi que le reçu signé 6r stocké, correspondant à ces is données pour générer une signature aveuglée d et une preuve de connaissance partielle ir avec l'algorithme CL.PoK de preuve de connaissance selon la signature Camenisch-Lysyanskaya déjà évoqué ci-avant. Cette étape de génération de preuve 510 est quasi-similaire à la sous-étape 3) de l'étape de vérification 140 décrite ci-avant, à l'exception du fait que l'entité fournisseur SP 20 connaît le service Si demandé. S'ensuit alors une étape 520 de transmission, vers l'entité fournisseur SP, de cette signature aveuglée 6 , de la preuve de connaissance partielle ir correspondante, et de la donnée s; correspondant au service Si que l'entité utilisatrice souhaite utiliser. 25 L'entité fournisseur SP va alors vérifier, au cours d'une étape de vérification 530, la signature aveuglée 6 et la preuve de connaissance partielle ic correspondante grâce à l'algorithme CL.Verify de vérification selon la signature Camenisch-Lysyanskaya, déjà évoqué ci-avant. Cette étape de vérification 530 est similaire à la sous-étape 4) de l'étape de vérification 140 décrite ci-avant. 30 Si la signature aveuglée 6 est validée au cours de l'étape 530, alors l'entité fournisseur SP donne accès au service Si à l'entité utilisatrice U;. Dans le cas contraire, le procédé 500 s'arrête ici.

Un tel procédé d'accès 500 à un service garantit un niveau poussé d'anonymat de l'utilisateur et permet de limiter le profiling au sujet de l'utilisation des services auquel l'utilisateur est abonné. Bien entendu, l'invention n'est pas limitée aux exemples de réalisation ci- dessus décrits et représentés, à partir desquels on pourra prévoir d'autres modes et d'autres formes de réalisation, sans pour autant sortir du cadre de l'invention. La transmission des données d'identification s; peut se faire de telle sorte que la facturation du service requis soit dissociée de la fourniture du service, afin d'empêcher la connaissance, par une entité identificatrice O facturant le service, io du service requis auprès de l'entité fournisseur de services SP, tout en empêchant cette dernière de connaître l'identité de l'utilisateur. Pour ce faire, une technique telle que développée dans la demande de brevet française FR953953 du même déposant peut être employée, dans laquelle les données d'identification s; sont transmises, au sein d'un message destiné à 15 l'entité SP, sous la forme de données caviardables ou sanitizables .

Claims (14)

1. Revendications1. Procédé d'abonnement anonyme d'une entité utilisatrice (U;) à au moins un service (Si) fourni par une entité fournisseur de services (SP), caractérisé s en ce que: - l'entité utilisatrice (U;) envoie (120) à l'entité fournisseur (SP) au moins une première donnée d'engagement (Csku), générée à partir au moins d'une clé secrète (sku) propre à ladite entité utilisatrice et d'au moins un nombre aléatoire (s'), et au moins une données d'identification (s;) associée audit au 10 moins un service (Si) ; - l'entité fournisseur (SP) envoie (130) à l'entité utilisatrice (U;) au moins un reçu (S,Qr) généré à partir d'au moins une partie des données d'engagement (Csku) et de la donnée d'identification (s;) reçue, ledit reçu (S,Qr) permettant à l'entité utilisatrice d'accéder audit service (Si). 15
2. 2. Procédé selon la revendication 1, caractérisé en ce que l'étape d'envoi (130) du reçu comprend la génération (133) d'un reçu primaire (S) à partir d'au moins une partie des données d'engagement (Csku) et de la donnée d'identification (s;) reçue, la signature (135) dudit reçu primaire en un reçu 20 signé (Or) et la transmission (137) dudit reçu signé (Or) vers l'entité utilisatrice (Ui).
3. 3. Procédé selon la revendication 1 ou 2, caractérisé en ce que l'entité utilisatrice (U;) envoie (110) à l'entité fournisseur (SP) une deuxième donnée 25 d'engagement (rrsku) prouvant que l'entité utilisatrice connaît la clé secrète (sku) qui lui est propre et ledit nombre aléatoire (s'), caractérisé en ce que l'entité fournisseur (SP) vérifie (121) la deuxième donnée d'engagement (rrskU) avant d'envoyer (125) le reçu à l'entité utilisatrice.
4. 4. Procédé selon l'une quelconque des revendications précédentes, caractérisé en ce que l'entité utilisatrice (U;) vérifie (140) le reçu transmis par l'entité fournisseur (SP).
5. 5. Procédé selon l'une quelconque des revendications précédentes, dans lequel l'entité utilisatrice s'abonne successivement à plusieurs services (S1,S2), caractérisé en ce que, pour chaque service auquel l'entité utilisatrice s'abonne, au moins une donnée d'engagement (Csku,1, Csku,2), générée dans l'entité utilisatrice en fonction de la clé secrète (sku), d'au moins un nombre aléatoire et d'une donnée d'identification (s1,s2) associée audit service, est envoyée à l'entité fournisseur, et en ce qu'un reçu (ar,1,ar,2), généré dans l'entité fournisseur en fonction de ladite donnée d'engagement reçue, est envoyé (120) à l'entité utilisatrice.
6. 6. Procédé selon l'une quelconque des revendications précédentes, dans lequel l'entité utilisatrice s'abonne simultanément à plusieurs services (S1,S2), caractérisé en ce que la donnée d'identification des services est générée à partir des données d'identification respectives de chacun desdits services, et en ce que l'entité utilisatrice est apte à accéder à l'un desdits services fournis par l'entité fournisseur au moyen dudit reçu.
7. 7. Procédé selon l'une quelconque des revendications précédentes, dans lequel le reçu (S,ar) est stocké dans l'entité utilisatrice (U;), caractérisé par les étapes ultérieures suivantes : - l'entité utilisatrice envoie (210) à l'entité fournisseur des premières données d'abonnement complémentaire ({P}) générées à partir au moins du reçu stocké, de la clé secrète propre à ladite entité utilisatrice, du nombre aléatoire et d'au moins une donnée d'identification (s,+1) associée à au moins un service 3o (S,+1) supplémentaire ;- l'entité fournisseur envoie (220) à l'entité utilisatrice des deuxièmes données d'abonnement complémentaire ({P'}) générées à partir d'au moins une partie des premières données d'engagement complémentaires reçues ; - le reçu est mis à jour (230), dans l'entité utilisatrice (U;), au moyen desdites deuxièmes données d'abonnement complémentaire ({P'}).
8. 8. Procédé selon la revendication 7, caractérisé en ce que les premières données d'abonnement complémentaire comportent au moins un premier io élément de preuve (S') généré à partir au moins du reçu stocké (S,ar) et d'un nombre aléatoire (17), en ce que les deuxièmes données d'abonnement complémentaire comportent au moins un reçu complémentaire (S ,d-) généré (323) à partir au moins du premier élément de preuve (S'), et en ce que la mise à jour du reçu comprend la mémorisation (333) dudit reçu 15 complémentaire dans l'entité utilisatrice (U;).
9. 9. Procédé selon la revendication précédente, dans lequel le reçu stocké dans l'entité utilisatrice (U;) comporte un reçu signé ((Jr), caractérisé en ce que ledit reçu complémentaire (6) est généré par signature (325) d'un reçu 20 complémentaire primaire (S ), lequel est généré (323) à partir au moins du premier élément de preuve (S'), et en ce que la mise à jour du reçu comprend la mémorisation (333), dans l'entité utilisatrice (U;), du reçu complémentaire (6) à la place du reçu signé (Qr). 25
10. 10. Procédé selon la revendication précédente, comprenant la vérification (331) du reçu complémentaire (6) par l'entité utilisatrice.
11. 11. Procédé selon la revendication 7, dans lequel le reçu stocké dans l'entité utilisatrice (U;) comporte un reçu signé (Or), caractérisé en ce que les 30 premières données d'abonnement complémentaire comportent au moins unpremier élément de preuve (6) généré (411) en fonction du reçu signé (Or), en ce que les deuxièmes données d'abonnement complémentaire comportent des données témoins (c,, {Â, }, {B, }) générées (425) à partir dudit premier élément de preuve Cd), en ce que la mise à jour (430) du reçu comprend la 5 génération (431) d'un reçu complémentaire (o') à partir d'une partie au moins des données témoins (c,, {Â; }, {B, }) reçues et la mémorisation (433), dans l'entité utilisatrice (U;), dudit reçu complémentaire (Q') à la place du reçu signé (Or) 10
12. 12. Procédé selon la revendication précédente, dans lequel les premières données d'abonnement complémentaire comportent un deuxième élément de preuve ) généré (411) à partir d'au moins une donnée d'information (si) associée à un service, caractérisé en ce que ledit deuxième élément de preuve est vérifié (421) dans l'entité fournisseuse (SP) avant de transmettre 15 (427) les deuxièmes données d'abonnement complémentaire à l'entité utilisatrice (U;).
13. 13. Procédé d'accès anonyme d'une entité utilisatrice (U;) à au moins un service fourni par une entité fournisseur de services (SP), dans lequel l'entité 20 utilisatrice (U;) présente un reçu signé (Or) obtenu au moyen des étapes d'un procédé d'abonnement anonyme selon l'une des revendications précédentes, caractérisé en ce que l'entité utilisatrice envoie (520) au moins un premier élément de preuve (â) généré (510) en fonction du dudit reçu signé (Or), et en ce que l'entité fournisseur (SP) donne accès au service à l'entité utilisatrice si 25 le premier élément de preuve (6) est validé (530).
14. 14. Système cryptographique (1) pour l'abonnement anonyme d'un utilisateur à au moins un service, le système comprenant au moins une entité utilisatrice (U;) et une entité fournisseur de services (SP) arrangée pour fournirledit service, caractérisé en ce que le système est apte à mettre en oeuvre un procédé selon l'une des revendications précédentes.