WO2011027071A1 - Procédé cryptographique d'abonnement anonyme a un service - Google Patents

Procédé cryptographique d'abonnement anonyme a un service Download PDF

Info

Publication number
WO2011027071A1
WO2011027071A1 PCT/FR2010/051802 FR2010051802W WO2011027071A1 WO 2011027071 A1 WO2011027071 A1 WO 2011027071A1 FR 2010051802 W FR2010051802 W FR 2010051802W WO 2011027071 A1 WO2011027071 A1 WO 2011027071A1
Authority
WO
WIPO (PCT)
Prior art keywords
receipt
entity
user entity
service
complementary
Prior art date
Application number
PCT/FR2010/051802
Other languages
English (en)
Inventor
Amandine Jambert
Sébastien CANARD
Original Assignee
France Telecom
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by France Telecom filed Critical France Telecom
Publication of WO2011027071A1 publication Critical patent/WO2011027071A1/fr

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/04—Network architectures or network communication protocols for network security for providing a confidential data exchange among entities communicating through data packet networks
    • H04L63/0407—Network architectures or network communication protocols for network security for providing a confidential data exchange among entities communicating through data packet networks wherein the identity of one or more communicating identities is hidden
    • H04L63/0421—Anonymous communication, i.e. the party's identifiers are hidden from the other party or parties, e.g. using an anonymizer
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/32—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L2209/00—Additional information or applications relating to cryptographic mechanisms or cryptographic arrangements for secret or secure communication H04L9/00
    • H04L2209/42—Anonymization, e.g. involving pseudonyms

Definitions

  • the invention relates to a cryptographic method enabling a user to anonymously subscribe to a service.
  • One of these solutions (called “Anonymask”) is to create, with a third party, an account allowing the customer to pay anonymously the provider.
  • Another solution is to obtain anonymously and blindly the certification of a series of tokens corresponding to a precise number of authorized accesses, which will then be sent one by one to the supplier.
  • the present invention improves the situation.
  • an object of the present invention is the implementation of a cryptographic method of anonymous subscription and use of a service allowing a user to subscribe anonymously a service from a service provider and the service provider. use later anonymously, without this service provider can identify this user.
  • Another object of the invention is to allow a certain level of analysis, by a service provider, of the use of a service by an anonymous user, without removing the anonymity of the latter.
  • the step of sending the receipt comprises generating a primary receipt from at least part of the commitment data and the received identification data, signing said primary receipt in a signed receipt. and transmitting said signed receipt to the user entity.
  • the user entity sends to the supplying entity a second commitment data proving that the user entity knows the secret key of its own and said random number and the provider entity checks the second commitment data before the user entity. send the receipt to the user entity.
  • the user entity verifies the receipt transmitted by the provider entity.
  • At least one commitment data item generated in the user entity according to the secret key, at least one random number and identification data associated with said service, is sent to the provider entity, and a receipt, generated in the provider entity according to said received commitment data, is sent to the user entity.
  • a successive subscription mode prevents any profiling.
  • the identification data of the services is generated from the respective identification data of each of said services, and the user entity is able to accessing one of said services provided by the provider entity by means of said receipt.
  • the method comprises the following subsequent steps:
  • the user entity sends to the provider entity first complementary subscription data generated from at least the stored receipt, the secret key belonging to said user entity, the random number and at least one identification data item; associated with at least one additional service;
  • the provider entity sends to the user entity second complementary subscription data generated from at least part of the first complementary commitment data received;
  • the receipt is updated in the user entity by means of said second complementary subscription data.
  • the first complementary subscription data comprise at least a first piece of evidence generated from at least the stored receipt and a random number
  • the second complementary subscription data comprise at least one receipt.
  • the complementary receipt is then generated by signature of a primary complementary receipt, which is itself generated from at least the first piece of evidence, and the update of the receipt then includes the storage, in the user entity, of the complementary receipt instead of the signed receipt.
  • the use of signed receipts reinforces the anonymity of the user entity.
  • the method includes a step of verification of the complementary receipt by the user entity, which ensures the authenticity of it.
  • the receipt stored in the user entity comprises a signed receipt
  • the first complementary subscription data comprises at least a first piece of evidence generated according to this signed receipt
  • the second data of complementary subscription comprise witness data generated from this first piece of evidence
  • the updating of the receipt then comprises the generation of a complementary receipt from at least a part of the received control data and the storage, in the user entity, the complementary receipt instead of the signed receipt.
  • the first complementary subscription data includes a second piece of evidence generated from at least one piece of information associated with a service
  • this second piece of evidence is checked in the first instance. the supplying entity before transmitting the second complementary subscription data to the user entity.
  • the present invention further provides a method of anonymous access of a user entity to at least one service provided by a service provider entity, in which the user entity presents a receipt obtained by means of an anonymous subscription method. as described above.
  • the user entity sends at least one first piece of evidence generated based on said receipt and the provider entity provides access to the service to the user entity only if the first piece of evidence is validated.
  • the present invention also proposes a cryptographic system for the anonymous subscription of a user to at least one service, this system comprising at least one user entity and a service provider entity arranged to provide said service, and being able to implement the subscription cryptographic method above.
  • FIG. 1 is a block diagram illustrating a cryptographic system used by the invention
  • FIG. 2 illustrates the steps of an anonymous subscription method according to the invention
  • FIG. 2A illustrates the steps of an anonymous two-service anonymous subscription method according to the invention
  • FIG. 3A illustrates the steps of a complementary subscription method according to the invention
  • FIG. 3B illustrates the steps of a complementary subscription method according to a first embodiment of the invention
  • FIG. 3C illustrates the steps of a complementary subscription method according to a second embodiment of the invention.
  • FIG. 1 illustrates a cryptographic system 1 used by the present invention.
  • a plurality of user entities Ui, ..., Uj, ..., U n form a GU group of users.
  • These user entities Uj can subscribe to an SP service provider entity in order to access a number t of services Si, ..., S t . It is desirable that this subscription be carried out within the framework of the respect of the privacy of the entity U ,, that is to say that the entity U, can subscribe and subsequently access the services subscribed anonymously , without the service provider entity SP being able to trace the use of the service by the entity U ,.
  • the system may finally present a management entity M, whose role may be to initialize parameters and other keys, public or secret, necessary for the method of the present invention and assigned to the entities SP and O, and on the other hand register the U entities in the GU group of users.
  • a management entity M whose role may be to initialize parameters and other keys, public or secret, necessary for the method of the present invention and assigned to the entities SP and O, and on the other hand register the U entities in the GU group of users.
  • Such entities must be able to perform a number of cryptographic calculations.
  • such entities may include calculation means such as a processor, a microprocessor, or any other means for performing a calculation or generating a random value.
  • LRSW uses bilinear forms, that is to say a function e such that e: G x G ⁇ G *, where:
  • each element of G and G * can be represented by a single bit string
  • - gi is a generator of G.
  • the signature protocol "Camenisch-Lysyanskaya” type "LRSW” includes the following algorithms:
  • This algorithm allows the user to calculate a commitment on values, as well as a proof of knowledge on these values and the good construction of the commitment. It receives in input a number of values So,. . . , Si, as well as a public key pkcL and outputs an engagement S and a proof of knowledge ⁇ on the values s 0 , .., Si • CL.
  • Sign This algorithm allows to sign a commitment. It thus receives, as input, a commitment S, as well as the public key of the pkcL system and the secret key of the signatory signer, and outputs a signature ⁇ .
  • the management entity M exchanges, on the one hand, data with the identifying entity O in order to define a group public key pk G.
  • the management entity M can, on the other hand, exchange data with the service provider entity SP in order to define a secondary public key ch pk , for example a delegated public key or a chameleon function public key whose key correspondent secret may be held by the SP entity.
  • This initialization step 1 begins with a substep 1 1 1 of initialization of the schemas including the initialization of the public parameters, for example those of a Camenish-Lysyanskaya signature. It then comprises a substep 1 13 of registration made for each new user entity U, and which allows the registration of this new user entity U, the subscription service.
  • the provider entity SP initializes the system for a particular signature scheme, for example a Camenisch-Lysyanskaya signature scheme, in order to enable the signing of the signature scheme.
  • a commitment containing a number of values.
  • the signed commitment contains hereafter t + 3 values, where t is the number of services that the SP entity can provide, along with the three identification and anonymization parameters that are the secret key of the user and two random values hiding it).
  • the SP entity generates the elliptic curve parameters q, G, G * , gi, e.
  • the SP entity calculates the following public parameters, related to its secret key, for all i ranging from 1 to t + 3:
  • the entity SP chooses h 0 , ..., h t + 3 of the generators of the group G according to the signature Camenish-Lysyanskaya which will be used. In our case, we will fix for all i ranging from 0 to t + 3. In the case of signatures based on ACJT (named after the authors Ateniese, Camenisch, Joye and Tsudik) or BBS (named after the authors Boneh, Boyen and Shacham), the generators would be randomly selected among the generators of G.
  • a new user U subscribes to the subscription service.
  • This sub-step can for example proceed as follows: 1) Any new user entity U, cooperates with the management entity M to perform a protocol to join the user group GU.
  • a protocol may for example consist of a protocol for adding to a group sharing a group signature or a registration protocol as described in the French patent application FR953953 of the same applicant.
  • the user entity U then obtains a secret key sk u linked to a membership certificate A G , u-
  • the user entity U sends the service provider entity SP commitment data enabling it to subscribe to at least one of the services Si, .. ., S t provided by the SP provider entity.
  • a first commitment data C S ku is generated during a generation substep 121 by the user entity U, starting from at least:
  • a secret key sk u of its own obtained for example during the substep of registration 113 described above, to ensure the link between the subscribed service and the user entity;
  • this first commitment data C S k U can be achieved in several ways. In order to respect a very strong anonymity, this can be done according to the following commitment protocol:
  • a second commitment data Tr S k U proving that the user entity is well acquainted with sk u , ro 'and s' such that C S ku is well constructed, can be optionally generated during a substep of generation 123.
  • This second commitment datum may take the form of proof of knowledge on a product of discrete logarithms, for example, as follows:
  • this proof F S ku can be carried out as follows
  • the generators will be randomly selected from the generators of group G.
  • the user entity then sends, during a transmission sub-step 125, the first commitment data C S ku, possibly accompanied by the second commitment data TT sku , as well as the identification data or data. If corresponding to the service (s) to which the user entity wishes to subscribe.
  • the identification data or s may constitute a message used to generate a group sanitizabie signature, on the principle of what is described in the French patent application FR953953 of the same applicant, or a standard group signature (for example, ACJT or BBS).
  • the supplier entity SP will confirm the smooth running of the process anonymous subscription, during a step 130 of confirmation of the subscription, by building a receipt for the user entity.
  • the receipt can be constructed differently depending on the objective set.
  • a solution allowing to answer to several levels of anonymity, according to the way to use it, is possible thanks to the Camenisch-Lysyanskaya signatures.
  • the provider entity SP can firstly, if a second commitment data Tr sk has been generated and sent in step 120, check this second commitment data ir sku , when a verification sub-step 131.
  • the verification of this proof therefore consists in verifying this equality.
  • the provider entity SP will then generate a primary receipt S from the first received commitment data C S ku, as well as received identification data s, during a substep 133.
  • This substep can take the following form: 1) A random number is chosen in Z *
  • a primary receipt S is then calculated according to:
  • the primary receipt S obtained can be sent as such to the user entity U ,.
  • Such a substep of signature 135 can take the following form:
  • Or (a, ⁇ A, b, ⁇ Bi ⁇ , c, 1 ⁇ i ⁇ I).
  • the receipt is then sent to the user entity U, during a transmission sub-step 137. It is also possible to send to the user entity U, the receipt both in its primary form S and in its signed form ⁇ ⁇ .
  • the user entity U can then use it later to access the service S, which it has just subscribed anonymously.
  • a step 140 of verification of this signed receipt ⁇ ⁇ can advantageously be performed in the entity user U ,, for the purpose of verifying whether the signed receipt is valid before storing it in this user entity U ,.
  • a proof of knowledge is constructed using the following algorithm, corresponding to the CL.PoK algorithm of proof of knowledge according to the Camenisch-Lysyanskaya signature:
  • the signed receipt ⁇ ⁇ is valid. If one of these conditions is not fulfilled, the signed receipt ⁇ ⁇ is not valid and the process stops here. Once the receipt signed ⁇ ⁇ validated, it is stored by the user entity U, to be used later to access the (x) service (s) associated (s).
  • the method 100 is repeated for each subscription to a service S ,.
  • a respective receipt ⁇ ⁇ ⁇ , Or2, etc. is stored by the user entity U ,.
  • the user entity U wishes to later access a particular service S , it will then use the corresponding receipt ⁇ ⁇ ⁇ .
  • FIG. 2A Such a first embodiment is illustrated in FIG. 2A.
  • This figure shows a successive subscription process for two services Si and S 2
  • a first step 100 'of anonymous subscription to a first service Si is first performed, similarly to the method 100 of FIG. 2.
  • this step 100' comprises a step 120 'of sending of first commitment data C S k U i and TT sku i and an identification data Si of the service Si, from the user entity U, to the service provider entity SP, similarly to the step 120 ci -before.
  • a step 130 'of returning a signed receipt ⁇ ⁇ ⁇ to the user entity U, similar to step 130 above.
  • a verification step similar to step 140 above can then optionally be performed (not shown).
  • a second step 100 "of anonymous subscription to a second service S 2 is then performed, always similar to the method 100 of FIG. 2.
  • This step 100" also comprises a step 120 "of sending second commitment data C S k U 2 and TT skU 2 and an identification data s 2 of the service S 2 , from the user entity Uj to the service provider entity SP, similarly to the step 120 above, as well as a step 130 "of returning a signed receipt to the user entity U, similar to step 130 above.
  • a verification step similar to step 140 above can also be performed.
  • the user entity U has two receipts signed ⁇ ⁇ ⁇ and which enables it to access one of the services Si and S 2.
  • This example involving two services is Of course, those skilled in the art can extrapolate this example to any number of services to which they subscribe, successively.
  • Such an embodiment is particularly advantageous in that it prevents in particular any "profiling” on the part of the SP entity providing the services, that is to say that the latter can neither bind nor analyze the use of a service provided by a user.
  • the term "profiling” here refers to any technique that consists of analyzing, through various means, the "profile" of visitors to a site in order to determine their motivations, interests, age group, profession, etc. to better meet their expectations either through a real-time modification of the pages of the site or for their next visit.
  • the SP entity providing the services is not able to link two subscriptions between them.
  • This strong anonymity implies in return to store a signature by subscriber service, therefore potentially many signatures, and perform a process instance 100 per service, so potentially many exchanges during the subscription between user entities and service provider.
  • an instance of the method 100 is repeated by series of services to which it is desired to subscribe.
  • a first series of services Si, S 2 , ..., S k to which the user entity Uj subscribes a unique receipt ⁇ ⁇ , ⁇ is stored by this user entity U ,, and so on for each subsequent series of subscribed services.
  • the SP service provider entity will know the link between the services of the same series (the same user is interested in all the services of a series).
  • the SP entity will not be able to link different series of services, so the possibility of partial profiling offered to the SP entity is limited.
  • the SP entity will not be able to connect this subscription to its subsequent use, which reinforces the protection of the user's privacy.
  • the advantage of this second embodiment is to limit the number of signatures to be stored by the user entity U ,, as well as the number of exchanges required between the user entities U, and the provider entity SP during the subscription, to the detriment of a limited loss of anonymity. If the user knows from the outset the exhaustive list of services to which he wants to subscribe, this second embodiment allows to store a single receipt obtained with a single instance of the method 100.
  • the user may be required to subscribe to services provided by the SP entity at different times in time. It can certainly do it individually, according to the first embodiment, but it can also use a complementary subscription method.
  • FIG. 3A illustrates, in a general manner, such a complementary subscription method 200 according to the invention.
  • first complementary subscription data ⁇ P ⁇ are generated in the user entity U ,, to prove that it has already subscribed to a set of services Si, ..., If, and sent to the SP provider entity.
  • second complementary subscription data ⁇ P ' ⁇ are generated in the provider entity SP, thanks to the first complementary subscription data ⁇ P ⁇ , and sent to the user entity U ,.
  • a reconstruction step 230 is then performed, in the user entity Uj, to reconstruct a new receipt R, characterizing the old services Si, ..., Si and the newly subscribed services Si + i, ..., S k from the old receipt stored in the user entity Uj and complementary data ⁇ P ' ⁇ transmitted in step 220.
  • Figure 3B illustrates a complementary subscription method 300 according to a first embodiment of the general complementary subscription method 200 of the present invention.
  • the step 310 of sending evidence includes a first sub-step 311 of generating evidence, which proceeds according to the following protocol:
  • the primary receipt S is recovered, either directly because it was saved during the initial subscription process, or from the signed receipt saved during the initial subscription process, such as:
  • the identification data Si + i,. . . Sk, new services Si + i, ..., Sk to subscribe are further sent to the provider entity SP.
  • a step 320 for generating a new receipt follows, which may initially and optionally comprise a verification sub-step 321 of the second piece of evidence ⁇ in a manner similar to the validation performed during the step 131 above.
  • Step 320 is then completed by a transmission sub-step 327 of the complementary receipt obtained and the random number s associated with the user entity U ,.
  • Step 320 is then followed by a step 330 of reconstruction.
  • an optional step 331 of checking this signed additional receipt can then be performed in the user entity.
  • a proof of knowledge is constructed using the CL.PoK algorithm of proof of knowledge according to the Camenisch-Lysyanskaya signature.
  • This step is equivalent to the step 140 of the method 100, in which the signed receipt ⁇ ⁇ of the process 100 is replaced by the signed complementary receipt â and the values So, Si, ..., Si by the values s 0 , Si ,. . . Sk.
  • the reconstruction step 330 then ends with an update sub-step 333 where the receipt previously stored in the user entity is replaced by the new receipt.
  • this receipt S can be stored instead of the old receipt S stored in the user entity II ,, for later use.
  • this signed supplementary receipt ⁇ is stored in place of the old receipt signed o r in the user entity U ,.
  • the new value of s, calculated from the received variable s, is also stored in place of the old variable s in the user entity U ,.
  • the complementary receipt is developed in the provider entity SP and transmitted to the user entity U , or it can be optionally verified. Such a complementary subscription method 300 is advantageous when it is desired to reduce as much as possible the need for storage required in user entities U ,.
  • FIG. 3C illustrates a complementary subscription method 400 according to a second embodiment of the invention.
  • general complementary subscription method 200 of the present invention can be reproduced as often as necessary, since the receipt is simply updated during this process 300.
  • a method 400 is described having the following steps: 1) The method 400 starts with a step 410 of sending evidence to the provider entity SP. This step 410 comprises a first sub-step 41 1 of generating evidence, during which a proof of knowledge of the data Si, is built. . . , If identifying the services Si, ..., If already subscribed, using the CL.PoK algorithm of proof of knowledge according to the signature Camenisch-Lysyanskaya.
  • the step 410 of sending evidence is then completed by a second sub-step 413 transmission of evidence, wherein the first and second pieces of evidence ⁇ e ⁇ are sent to the entity SP provider.
  • the identification data Si + i,. . . Sk, new services Si + i, ..., Sk to subscribe are further sent to the provider entity SP.
  • Step 420 may then comprise a sub-step 423 for verifying the validity of the first piece of evidence, namely the blinded signature received ⁇ , from the public key pk C i_, of the blinded signature ⁇ and the second piece of evidence, thanks to the verification algorithm CL.Verify according to the signature Camenisch-Lysyanskaya as described in the verification step 140 of the method 100:
  • the method 400 stops here.
  • a first control element c is then calculated, according to the following formula:
  • Step 420 is then completed by a substep 427 transmission of all of this witness (c,, 3 ⁇ 4. ⁇ ⁇ -?,. ⁇ ) To the user entity U ,.
  • This new signed receipt ⁇ 'can then be stored, during a storage sub-step 433, in place of the old signed receipt ⁇ , in the user entity U, in order to be used later to access to one or more of the services
  • the new receipt is developed in the user entity U , and that the provider entity SP simply transmits a witness to it.
  • Such a complementary subscription method 400 is advantageous when the provider entity has little means of calculation compared to the number of user entities wishing to obtain services.
  • the need for storage of signatures is reduced on the side of user entities U ,.
  • Such a complementary subscription method 400 may be reproduced as often as necessary, since the receipt is simply updated during this method 400.
  • a user entity U subscribes to a set of services Si, ..., S k according to one of the methods described above, it can use to import any of these services, for example the service If, while remaining anonymous.
  • Camenisch-Lysyanskaya type signatures are used, such as signatures based on the ACJT signature as described in Jan Camenisch's A signature scheme with efficient protocols and Auna Lysyanskaya. (In Stelvio Cimato, Clemente Galdi, and Giuseppe Persiano, SCN, volume 2576 of Lecture Notes in Computer Science, pages 268-289, Springer, 2002), or those based on the BBS signature, the two additional CL.Add and CL algorithms .Agg are not necessarily necessary. They can be replaced by other equivalent algorithms that the skilled person can choose according to the signature considered.
  • FIG. 4 illustrates an example of method 500 of anonymous access to a service according to the present invention.
  • a first step 510 the user entity Ui uses the identification data Si,. . . , if respectively associated with the services Si, ..., Si to which this entity is subscribed, as well as the signed receipt ⁇ ⁇ stored, corresponding to these data Si,. .., Si, to generate a blinded signature ⁇ and a proof of partial knowledge ⁇ with the CL.PoK algorithm of proof of knowledge according to the Camenisch-Lysyanskaya signature already mentioned above.
  • This proof generation step 510 is substantially similar to the sub-step 3) of the verification step 140 described above, with the exception that the provider entity SP knows the service S, requested.
  • step 520 of transmission to the supplier entity SP, of this blinded signature ⁇ , of the corresponding partial knowledge proof ⁇ , and of the data s, corresponding to the service S, that the user entity wishes to use.
  • the supplier entity SP will then check, during a verification step 530, the blinded signature ⁇ and the corresponding partial knowledge proof ⁇ by means of the verification algorithm CL.Verify according to the Camenisch-Lysyanskaya signature, already mentioned. above.
  • This verification step 530 is similar to the sub-step 4) of the verification step 140 described above.
  • the provider entity SP gives access to the service S, to the user entity U ,.
  • the process 500 stops here.
  • Such a method of accessing a service 500 guarantees a high level of anonymity of the user and limits the profiling about the use of services to which the user is subscribed.
  • the transmission of the identification data If can be done in such a way that the billing of the required service is dissociated from the supply of the service, in order to prevent the knowledge, by an identifying entity O charging the service, of the service required from the service provider. SP service provider entity, while preventing the latter from knowing the identity of the user.

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Security & Cryptography (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Computer Hardware Design (AREA)
  • Computing Systems (AREA)
  • General Engineering & Computer Science (AREA)
  • Storage Device Security (AREA)

Abstract

L'invention concerne un procédé d'abonnement anonyme d'une entité utilisatrice (Ui,) auprès d'au moins un service (Si) fourni par une entité foumisseuse de service (SP). L'entité utilisatrice (Ui) envoie (120) à l'entité foumisseuse (SP) au moins une première donnée d'engagement (Csι<u)> générée à partir au moins d'une clé secrète (Csku) propre à ladite entité utilisatrice et d'au moins un nombre aléatoire (s'), et au moins une données d'indentification (si,) associée à ce service (Si). En retour, l'entité foumisseuse (SP) envoie (130) à l'entité utilisatrice (U1) au moins un reçu (S,σr) généré à partir d'au moins une partie des données d'engagement (Csku) et de la donnée d'identification (si,) reçue, ce reçu (S,σr) permettant à l'entité utilisatrice d'accéder audit service (Si). 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 œuvre 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 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 œuvre d'un procédé cryptographique d'abonnement et d'utilisation anonymes d'un service 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 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 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.
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é 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.
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.
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 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 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 .
4 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 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é 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 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 é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 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 œuvre 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 Ui,...,Uj,...,Un forment un groupe GU d'utilisateurs. Ces entités utilisatrices Uj peuvent s'abonner auprès d'une entité fournisseur de services SP afin d'accéder à un certain nombre t de services Si,..., 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 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 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 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 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. 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 anony- mous credentials from bilinear maps » de Jan Camenisch et Anna Lysyanskaya (CRYPTO, volume 3152 de Lecture Notes in Computer Science, pages 56-72. Springer, 2004). 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 : G x G→ G*, où :
- la fonction e est bilinéaire, i.e. VP,Q e G,Va,b <= Z,e(Pa , Qh ) = e(P,Q)ab ,
- la fonction e non dégénérée, i.e. 3P, Q <= G tels que e(P, Q)≠l 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*, gi, e) décrivant une courbe elliptique e : G x G→ G* telle que :
- G et G* soient deux groupes d'ordre premier q = 0(1 k),
- chaque élément de G et G* soit représentable par une unique chaîne de bits,
- gi soit un générateur de G.
Le protocole de signature « Camenisch-Lysyanskaya » de type « LRSW » comporte les algorithmes suivants :
• 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 pkCi_ ainsi qu'une clé secrète de signataire
Sksignataire-
• CLEngagement : Cet algorithme permet à l'utilisateur de calculer un 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 π sur les valeurs s0, .., 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 signataire, et fournit en sortie une signature σ.
• 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 σ et des valeurs s0)..., si et fournit en sortie une signature aveuglée σ , une preuve de connaissance π sur les valeurs So ¾, ainsi que deux nombres aléatoires r, r'.
• CL.Verify : Cet algorithme permet à n'importe quel individu ou entité de vérifier la validité d'une signature. Il reçoit pour cela, en entrée, une signature aveuglée σ et une preuve de connaissance π sur des valeurs, ainsi qu'une clé publique pkci_ et retourne une valeur « validée » ou « non validée ».
Lors d'une première étape d'initialisation 1 10, l'entité de gestion M é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 l'entité SP.
Cette étape 1 10 d'initialisation commence par une sous-étape 1 1 1 d'initialisation des schémas comprenant l'initialisation des paramètres publics, par exemple ceux d'une signature Camenish-Lysyanskaya. Elle comprend ensuite une sous-étape 1 13 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 1 1 1 , l'entité fournisseur SP, en tant 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ù 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*, gi, e.
2) L'entité SP choisit une clé secrète signataire = (x, y, {z,}) pour tout i allant de 1 à t+3 ;
3) L'entité SP calcule les paramètres publics suivants, liés à sa clé secrète, pour tout i allant de 1 à t+3 :
Figure imgf000011_0001
4) L'entité SP choisit h0, ... , 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
Figure imgf000011_0002
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*,gi,g2,e, X=gi x, Y=gi y, {Zi=gi zi}, {Wi=Yzi}; {h 1 <i <t+3).
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 ¾ et d'ajouter à la clé publique les valeurs Zj 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 : 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 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-
2) Ensuite, l'unité de gestion M communique des données d'identification IdUi 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é utilisatrice U, envoie à l'entité fournisseur de services SP des données d'engagement lui permettant de s'abonner à au moins un des services Si,...,St fournis par l'entité fournisseur SP.
Pour ce faire, une première donnée d'engagement CSku est générée lors 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 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 Z*
2) La première donnée d'engagement Cst<u est alors calculée selon : C = h0 h2
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 ê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 :
TTsku = ΡΚ{(χ ,ς,ρ) : Csku= hc f h }.
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 Crypto'89, volume 435 of LNCS, pages 239-252. Springer, 1989) ;
- M. Girault, G. Poupard, and J. Stem : "On the fly authentication and signature schemes based on groups of unknown order". (J. Cryptology, 19(4):463{487, 2006).
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=gAxhAz 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 the représentation 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).
On peut encore employer une preuve d'égalité de logarithme discret (x tel que y=gAx et t=hAx) 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 FSku peut être effectuée de la façon suivante
• Prendre aléatoirement trois valeurs wi , w2 et w3
. Calculer t^h^h^
• Calculer c=H(h0||hi||h2||CSku||t||m) où m est un message quelconque, éventuellement nul.
• Calculer vi=w csku, v2=w2-cro' et v3=w3-cs'
• La preuve π3ι<υ est alors le quadruplet (c,vi,v2,v3)
Cette preuve est dite valide si et seulement si c= H(h0||hi||h2||CSku| | CSkU c h0 v1hiv2h2 v3||m). La vérification de cette preuve consiste donc à vérifier cette égalité.
Il est avantageux de choisir les générateurs h0, h1 et h2 de manière à s'intégrer au mieux dans la signature Camenisch-Lysyanskaya choisie, par exemple :
Figure imgf000014_0001
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, la première donnée d'engagement CSku, éventuellement accompagnée de la deuxième donnée d'engagement TTsku, ainsi que de la ou des données d'identification Si 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 sanitizabie de groupe, sur le principe de ce qui 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 Trsku a été générée et envoyée au cours de l'étape 120, vérifier cette deuxième donnée d'engagement irsku, lors d'une sous-étape de vérification 131 . Dans notre exemple, la preuve (c,vi ,v2, 3) sur l'engagement CSku est dite valide si et seulement si c= H(h0||hi | | h2||CSku| | CSku c h0 v1hiv2h2 v3||m). La vérification de cette preuve consiste donc à vérifier cette égalité. 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 : 1 ) Un nombre aléatoire s" est choisi dans Z*
2) Un reçu primaire S est alors calculé selon :
Figure imgf000015_0001
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 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 Z* ;
2) On calcule les variables a et b, telles que a=ga et b=ay
3) On calcule, pour tout i allant de 1 à I, les variables Ai et B, telles que Ai=azi et Bi=Af y
4) On calcule la variable c telle que c=axS axy.
5) On obtient alors le reçu signé σΓ tel que :
Or = (a, {A , b, {Bi}, c; 1 < i < I).
On remarque ici que le reçu primaire S correspond à la sortie de l'algorithme CLEngagement recevant en entrée la clé publique pkcL, les valeurs aléatoires s=s'+s" et ro', ainsi que les données d'identification s0, ... ,Si. 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 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 or, 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 reçu à la fois sous sa forme primaire S et sous sa forme signée σΓ.
L'entité utilisatrice U,, munie d'un tel reçu, pourra alors l'utiliser ultérieurement pour accéder au service S, auquel elle vient de s'abonner de façon anonyme.
Lorsque le reçu signé σΓ est transmis lors de l'étape 137, une étape 140 de vérification de ce reçu signé σΓ peut avantageusement être réalisée, dans l'entité 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é σΓ 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 Z* ; b) les valeurs a,b ,c,c sont calculées telles que :
a - a ,b = b ,c— c ,c = c
c) pour tout i allant de 1 à I, on calcule les valeurs Ai , Bi telles que :
Àl = Al r , Bl = B,r
d) On obtient alors la signature aveuglée σ - (5,{À, }b {i?,. ];c;l < i≤ l) e) La preuve de connaissance partielle π sur les s, est alors construite de la façon suivante :
- 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
Figure imgf000017_0001
Bi )
- On calcule alors la preuve de connaissance partielle π sur r et les Sj telle que : π = PKj(£0, ip...,G, ) : (v, )' = νχ(ν^)Λ ή[(νν,)Λ | f) On obtient alors la preuve de connaissance { σ , π ,r,r').
3) On vérifie alors si le reçu signé σΓ est valide, à partir de la clé publique pkCi_, de la signature aveuglée σ et de la preuve de connaissance partielle ? , avec le protocole suivant correspondant à 1 £
16 l'algorithme de vérification CLVerify selon la signature Camenisch- Lysyanskaya :
a) On calcule les valeurs vx=e(X, à ), vxy=e(X, b ) et vs=e(g, c ) b) Pour tout i allant de 1 à I, on calcule Vxy,i=e(X, Bi ) 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, A,. ),
e(5 ,Y)=e(g,b),
e( A,. ,Y)=e(g, 5,. )
e) Si π est valide et les égalités ci-dessus sont toutes vérifiées, alors le reçu signé σΓ est valide. Si l'une de ces conditions n'est pas remplie, le reçu signé σΓ n'est pas valide et le procédé s'arrête ici. Une fois le reçu signé σΓ 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 S,. Ainsi, pour chaque service Si , S2, etc. auquel s'abonne l'entité utilisatrice U,, un reçu respectif σΓι, Or2, etc. est stocké par l'entité utilisatrice U,. Lorsque l'entité utilisatrice U, désirera accéder ultérieurement à un service particulier S,, elle utilisera alors le reçu σΓί correspondant.
Un tel premier mode de réalisation est illustré à la figure 2A. Cette figure montre un procédé d'abonnement successif à deux services Si et S2
Dans cette figure 2A, une première étape 100' d'abonnement anonyme à un premier service Si 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 TTskui et d'une donnée d'identification Si du service Si, depuis l'entité utilisatrice U, vers l'entité fournisseur de services SP, similairement à l'étape 120 ci-avant. S'ensuit une étape 130' de renvoi d'un reçu signé σΓι à 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 TTskU2 et d'une donnée d'identification s2 du service S2, depuis l'entité utilisatrice Uj 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é à 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 deux reçus signés σΓι et ce qui lui permet d'accéder à l'un des services Si 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ù 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 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 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 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 Si , S2,..., Sk auxquels s'abonne l'entité utilisatrice Uj, un unique reçu σΓ,ι 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 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.
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 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 Si,...,Si, et envoyées à l'entité fournisseur SP.
Lors d'une deuxième étape 220, des deuxièmes données d'abonnement 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,. Une étape de reconstruction 230 est alors effectuée, dans l'entité utilisatrice Uj, pour reconstruire un nouveau reçu R, caractérisant les anciens services Si,...,Si ainsi que les services nouvellement souscrits Si+i,...,Sk, à partir de l'ancien reçu stocké dans l'entité utilisatrice Uj 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 Uj, soit sous sa forme primaire S, soit sous sa forme signée σΓ>, les étapes sont effectuées comme suit :
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é sauvegardé lors du procédé d'abonnement initial, soit à partir du reçu signé sauvegardé lors du procédé d'abonnement initial, tel que :
S = h0 s " i, r" h2 s ]~J h- '~ b) Le nombre r est choisi aléatoirement dans Z*
c) On calcule f = ro'+r
d) On calcule un premier élément de preuve S'= S h r
e) On génère le deuxième élément de preuve π suivant : π = pkCL ) Λ S'= hx p■ hQ zh
Figure imgf000021_0001
f) Le nombre ro' prend la valeur du nombre f et est conservé comme partie privée par l'entité utilisatrice. 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' ,TT)), à l'entité fournisseur SP. Les données d'identification Si+i , . . . ,Sk des nouveaux services Si+i ,...,Sk à souscrire sont en outre envoyées à l'entité fournisseur SP. ) 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 ττ de manière similaire à la validation effectuée 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 5 , se décomposant comme suit : a) Un nombre s est choisi aléatoirement dans Z* b) On calcule un reçu complémentaire primaire s = S'-]"J '-'
i=l+4
5) Avantageusement, on peut signer S pour obtenir un reçu complémentaire signé â 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 â , ainsi qu'un nombre aléatoire s sont ainsi obtenus.
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 s associé à l'entité utilisatrice U,.
7) L'étape 320 est alors suivie d'une étape 330 de reconstruction. Dans le cas où un reçu complémentaire signé â 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é â peut être ensuite effectuée dans l'entité utilisatrice. 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 + 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é σΓ du procédé 100 par le reçu complémentaire signé â et les valeurs So,Si , ... ,Si par les valeurs s0,Si , . . . ,Sk.
On obtient en conséquence une signature aveuglée ô , une preuve de connaissances , 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é ô est valide, à partir de la clé publique pkCu de la signature aveuglée σ et de la preuve de connaissance partielle ir , 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.
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 II,, pour utilisation ultérieure.
Si par contre, le reçu complémentaire a été transmis sous sa forme signée ô lors de l'étape 327, et qu'il est jugé valide lors de l'étape 331 , alors ce reçu complémentaire signé ô est stocké à la place de l'ancien reçu signé or dans l'entité utilisatrice U,. La nouvelle valeur de s, calculée à partir de la variable s 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 U,, ou 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 U,.
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. 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 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 Si+i , ... ,Sk à partir d'une signature aveuglée σ et de la preuve de connaissance correspondante π .
• CL.Agg : Cet algorithme permet à un utilisateur d'ajouter les valeurs Si+i,...,sk à la signature σ qu'il connaît déjà, à partir de la connaissance de cette signature σ, des valeurs déjà engagées So, . .. ,Si, 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 σ et la 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 Z* au lieu de simplement Zq . Lorsque le nombre q est premier, 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 σΓ, 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 41 1 de génération d'éléments de preuve, durant laquelle on construit une preuve de connaissance des données Si , . . . ,Si identifiant les services Si ,... ,Si déjà souscrits, en utilisant l'algorithme CL.PoK de preuve de connaissance selon la signature Camenisch-Lysyanskaya.
On obtient en conséquence une signature aveuglée σ correspondant à un premier élément de preuve, une preuve de connaissance π correspondant à un deuxième élément de preuve, et deux nombres aléatoires r et r', similairement à 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 Ui. 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 σ e\ sont envoyés à l'entité fournisseur SP. Les données d'identification Si+i , . . . ,Sk des nouveaux services Si+i ,...,Sk à souscrire sont en outre envoyées à l'entité fournisseur SP.
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 π similairement à l'étape 131 ci-avant. 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 pkCi_, de la signature aveuglée σ et du deuxième élément de preuve, 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 :
- Si la signature aveuglée σ n'est pas valide, le procédé 400 s'arrête ici.
- Si la signature aveuglée σ est valide, elle présente alors la forme suivante :
Figure imgf000026_0001
5) S'ensuit alors une sous-étape 425 de génération d'un témoin pour les valeurs de services à ajouter, selon le protocole suivant : a) On calcule alors un premier élément témoin c, selon la formule suivante :
k
c, = à '-'
b) On calcule également, pour tout i allant de I+4 à k+3, les éléments témoins suivants :
Â, = a Zi et 5, = Ày
c) Le témoin des nouvelles valeurs de service Si+i , ... ,Sk est alors (c, , ¾ } {¾ } / + 4 < < 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 (c, , ¾.}{-?,.}) à l'entité utilisatrice U,.
7) Le procédé 400 se termine par une étape 430 de reconstruction du reçu, réalisée par l'entité utilisatrice Uj. Cette étape 430 comporte d'abord une sous- étape 431 de génération d'un nouveau reçu signé σ', selon le protocole suivant : a) On calculée, = ct r , et pour tout i allant de I+4 à k+3 : b) On décompose le reçu signé a = (a,{Aj},b,{B, },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é σ' tel que σ^ ^ , ^. ,ίι,^. },^ , ^) , basé sur l'engagement
Figure imgf000027_0001
8) Ce nouveau reçu signé σ' peut alors être stocké, lors d'une sous-étape de mémorisation 433, à la place de l'ancien reçu signé σ, dans l'entité utilisatrice U, afin d'être utilisé ultérieurement pour accéder à l'un ou plusieurs des services
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 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 à jour au cours de ce procédé 400.
Une fois qu'une entité utilisatrice U, est abonnée à un ensemble de services Si,...,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- 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, Clémente 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, 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é σΓ a été obtenu et 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 Ui utilise les données d'identification Si , . . . ,si associées respectivement aux services Si,...,Si auxquels cette entité est abonnée, ainsi que le reçu signé σΓ stocké, correspondant à ces données Si , . .. ,Si, pour générer une signature aveuglée σ et une preuve de connaissance partielle π 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 connaît le service S, demandé.
S'ensuit alors une étape 520 de transmission, vers l'entité fournisseur SP, de cette signature aveuglée σ , de la preuve de connaissance partielle π correspondante, et de la donnée s, correspondant au service S, que l'entité utilisatrice souhaite utiliser.
L'entité fournisseur SP va alors vérifier, au cours d'une étape de vérification 530, la signature aveuglée σ et la preuve de connaissance partielle π 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.
Si la signature aveuglée σ est validée au cours de l'étape 530, alors l'entité fournisseur SP donne accès au service S, à 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 Si 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, 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é à l'entité SP, sous la forme de données « caviardables » ou « sanitizables ».

Claims

Revendications
1. Procédé d'abonnement anonyme d'une entité utilisatrice (U,) à au moins un service (S,) fourni par une entité fournisseur de services (SP), caractérisé en ce que :
- l'entité utilisatrice (Ui) 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 moins un service (S,) ;
- l'entité fournisseur (SP) envoie (130) à l'entité utilisatrice (U,) au moins un reçu (S,or) 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,or) permettant à l'entité utilisatrice d'accéder audit service (Si).
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 signé (σΓ) et la transmission (137) dudit reçu signé (σΓ) vers l'entité utilisatrice (U,).
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 d'engagement (TTsku) 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 ( Sku) avant d'envoyer (125) le reçu à l'entité utilisatrice.
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. Procédé selon l'une quelconque des revendications précédentes, dans lequel l'entité utilisatrice s'abonne successivement à plusieurs services (Si,S2), caractérisé en ce que, pour chaque service auquel l'entité utilisatrice s'abonne, au moins une donnée d'engagement (CSku,i , 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 (Si ,s2) associée audit service, est envoyée à l'entité fournisseur, et en ce qu'un reçu (σΓ,ι,σΓ,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. Procédé selon l'une quelconque des revendications précédentes, dans lequel l'entité utilisatrice s'abonne simultanément à plusieurs services (Si,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. Procédé selon l'une quelconque des revendications précédentes, dans lequel le reçu (S,or) 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 (si+i ) associée à au moins un service (Si+i) 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 (Ui), au moyen desdites deuxièmes données d'abonnement complémentaire ({P'}).
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 élément de preuve (S') généré à partir au moins du reçu stocké (S, σΓ) et d'un nombre aléatoire ( r ), en ce que les deuxièmes données d'abonnement complémentaire comportent au moins un reçu complémentaire { S , â ) 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 complémentaire dans l'entité utilisatrice (U,).
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é (or), caractérisé en ce que ledit reçu complémentaire ( â ) est généré par signature (325) d'un reçu 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 ( â ) à la place du reçu signé (σΓ).
10. Procédé selon la revendication précédente, comprenant la vérification (331 ) du reçu complémentaire ( â ) par l'entité utilisatrice.
1 1 . Procédé selon la revendication 7, dans lequel le reçu stocké dans l'entité utilisatrice (Uj) comporte un reçu signé (or), caractérisé en ce que les premières données d'abonnement complémentaire comportent au moins un premier élément de preuve ( σ ) généré (41 1 ) en fonction du reçu signé (σΓ), en ce que les deuxièmes données d'abonnement complémentaire comportent des données témoins (c, , ¾ } {fir ]) générées (425) à partir dudit premier élément de preuve ( σ ), en ce que la mise à jour (430) du reçu comprend la génération (431 ) d'un reçu complémentaire (σ') à partir d'une partie au moins des données témoins (?, , {¾ } {_?,. )) reçues et la mémorisation (433), dans l'entité utilisatrice (U,), dudit reçu complémentaire (σ') à la place du reçu signé (σΓ).
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é (41 1 ) à partir d'au moins une donnée d'information (s,) 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 (427) les deuxièmes données d'abonnement complémentaire à l'entité utilisatrice (Uj).
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é utilisatrice (U,) présente un reçu signé (σΓ) 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é (σΓ), et en ce que l'entité fournisseur (SP) donne accès au service à l'entité utilisatrice si le premier élément de preuve ( & ) est validé (530).
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 (Uj) et une entité fournisseur de services (SP) arrangée pour fournir ledit service, caractérisé en ce que le système est apte à mettre en œuvre un procédé selon l'une des revendications précédentes.
PCT/FR2010/051802 2009-09-04 2010-08-31 Procédé cryptographique d'abonnement anonyme a un service WO2011027071A1 (fr)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
FR0956056A FR2949932A1 (fr) 2009-09-04 2009-09-04 Procede cryptographique d'abonnement anonyme a un service
FR0956056 2009-09-04

Publications (1)

Publication Number Publication Date
WO2011027071A1 true WO2011027071A1 (fr) 2011-03-10

Family

ID=42244111

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/FR2010/051802 WO2011027071A1 (fr) 2009-09-04 2010-08-31 Procédé cryptographique d'abonnement anonyme a un service

Country Status (2)

Country Link
FR (1) FR2949932A1 (fr)
WO (1) WO2011027071A1 (fr)

Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
FR953953A (fr) 1945-04-19 1949-12-16 Dispositif pour obtenir des jets mobiles et éventuellement tournants, dans les appareils destinés à insuffler de l'air contre des plaques ou objets en verre à tremper
US20070255661A1 (en) * 2004-10-19 2007-11-01 Takuya Yoshida Anonymous order system, an anonymous order apparatus, and a program therefor
WO2009028794A2 (fr) * 2007-08-24 2009-03-05 Electronics And Telecommunication Research Institute Procédé de fourniture d'une infrastructure de clé publique anonyme et d'un service correspondant

Patent Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
FR953953A (fr) 1945-04-19 1949-12-16 Dispositif pour obtenir des jets mobiles et éventuellement tournants, dans les appareils destinés à insuffler de l'air contre des plaques ou objets en verre à tremper
US20070255661A1 (en) * 2004-10-19 2007-11-01 Takuya Yoshida Anonymous order system, an anonymous order apparatus, and a program therefor
WO2009028794A2 (fr) * 2007-08-24 2009-03-05 Electronics And Telecommunication Research Institute Procédé de fourniture d'une infrastructure de clé publique anonyme et d'un service correspondant

Non-Patent Citations (8)

* Cited by examiner, † Cited by third party
Title
"Lecture Notes in Computer Science", 2004, SPRINGER, pages: 56 - 72
"Practical anonymous divisible e-cash from bounded accumulators", CRYPTOLOGY EPRINT ARCHIVE, REPORT 2007/459, 2007
C.P. SCHNORR: "Crypto'89, volume 435 of LNCS", vol. 435, 1989, SPRINGER, article "Efficient identification and signatures for smart cards", pages: 239 - 252
D. CHAUM; T.P. PEDERSEN: "Eurocrypt'92, volume 658 of LNCS", vol. 658, 1992, SPRINGER, article "Transferred cash grows in size", pages: 390 - 407
DAMGARD; E. FUJISAKI: "Asiacrypt 2002, volume 2501 of LNCS", vol. 2501, 2002, SPRINGER-VERLAG, article "A Statistically-Hiding Integer Commitment Scheme Based on Groups with Hidden Order", pages: 143 - 159
DE JAN CAMENISCH; AUNA LYSYANSKAYA: "Lecture Notes in Computer Science", vol. 2576, 2002, SPRINGER, article "A signature scheme with efficient protocols", pages: 268 - 289
M. GIRAULT; G. POUPARD; J. STERN: "On the fly authentication and signature schemes based on groups of unknown order", J. CRYPTOLOGY, vol. 19, no. 4, 2006, pages 463 - 487, XP019440584, DOI: doi:10.1007/s00145-006-0224-0
STEFAN A. BRANDS: "Technical report", 1993, THE NETHERLANDS, article "An efficient off-line electronic cash system based on the representation problem"

Also Published As

Publication number Publication date
FR2949932A1 (fr) 2011-03-11

Similar Documents

Publication Publication Date Title
EP2116000B1 (fr) Procéée d&#39;authentification unique d&#39;un utilisateur auprès de fournisseurs de service
EP2656538B1 (fr) Accès anonyme a un service au moyen de certificats agrégés
EP2441207B1 (fr) Procédé cryptographique d&#39;authentification anonyme et d&#39;identification séparée d&#39;un utilisateur
JP4639084B2 (ja) セキュア認証の暗号方法および暗号装置
EP2891268B1 (fr) Signature de groupe utilisant un pseudonyme
FR2822002A1 (fr) Authentification cryptographique par modules ephemeres
EP1523824B1 (fr) Procede de signature de liste et application au vote electronique
FR3091108A1 (fr) Procédé et système de vote électronique
Küpçü Official arbitration with secure cloud storage application
EP3965361B1 (fr) Echange de données entre un client et un dispositif distant, par exemple un module sécurisé
WO2003060841A1 (fr) Procede cryptographique de revocation a l&#39;aide d&#39;une carte a puce
WO2021122186A1 (fr) Procédé et dispositif de contrôle d&#39;accès anonyme à une plateforme collaborative d&#39;anonymisation
WO2011027071A1 (fr) Procédé cryptographique d&#39;abonnement anonyme a un service
FR2950213A1 (fr) Procede de generation d&#39;un certificat numerique
EP3063898B1 (fr) Signature à pseudonyme pour carte à puce
FR2962286A1 (fr) Procede d&#39;authentification permettant de renforcer l&#39;anonymat entre un fournisseur d&#39;identites et un fournisseur de services
Kaim Privacy preserving post-quantum cryptography
WO2008081151A2 (fr) Procede de signature de liste anonyme et correlable
FR3070517A1 (fr) Systeme et procede d&#39;authentification et de signature numerique
WO2008087359A2 (fr) Procédé de signature de liste anonyme et traçable sans levée d&#39;anonymat
WO2007093680A1 (fr) Procede de certification de cle publique par un prestataire non accredite

Legal Events

Date Code Title Description
121 Ep: the epo has been informed by wipo that ep was designated in this application

Ref document number: 10763776

Country of ref document: EP

Kind code of ref document: A1

NENP Non-entry into the national phase

Ref country code: DE

122 Ep: pct application non-entry in european phase

Ref document number: 10763776

Country of ref document: EP

Kind code of ref document: A1