Methods and devices for managing the revocation of cryptographic accreditations

Abstract

The invention relates to an accreditation management device (d-FI) that generates an anonymous verifiable accreditation (VC) relating to attributes of a user (d-USR), including an identifier (y) of this accreditation. It also manages a list of these identifiers and a cryptographic accumulator in which the valid identifiers are accumulated. It calculates a witness (C) representative of the membership of the identifier (y) of an accreditation in this a list, and a proof (Π c ) associated with this witness (c). The user can calculate a proof (Π yok ) of non-revocation of the identifier (y) of their anonymous verifiable accreditation and use their certified attributes to exert a right, for example, to access to a service, subject to verification of this proof and the validity of the accreditation.

Description

[0001]Description Title of the invention: Methods and devices for managing the revocation of cryptographic accreditations Prior art The invention lies in the field of digital identity management. More specifically, the invention relates to a method for managing digital identity that preserves the privacy of users. For example, many service providers, online or in a face-to-face relationship with the user, require the provision of identity elements from the user, more generally in order to deliver their service. Traditionally, in a non-digital world, this provision of identity elements is carried out using (physical) titles issued by official authorities (identity cards, driving licenses, etc.) and supporting documents issued by recognized third-party certifiers (electricity bill, telecom bill, medical certificate, etc.). In particular,A mechanism is known in which an authority issues cryptographic credentials to certify attributes of its users, whereby a service provider can obtain proof of the validity of such a credential before granting access to its service. Traditionally, revocation systems are associated with authentication schemes. For example, in a public key infrastructure, certificates with a limited validity period must be renewed regularly. In certain circumstances,The entity holding a certificate may have to change the information contained in its certificate or be excluded from the infrastructure. The certificate it holds must be excluded from certificates considered valid. RFC 5280 defines different revocation methods (https: / / www.rfc-editor.org / rfc / pdfrfc / rfc5280.txt.pdf). OAuth 2.0 (https: / / www.rfc-editor.org / rfc / rfc6749) is a synchronous access authorization system in the sense that the user obtains a token from a central system, a token that allows them to access a resource. Revocation is described in RFC 7009 (https: / / www.rfc-editor.org / rfc / rfc7009). The service provider managing the resource can systematically query the central system to ensure the validity of the token. In such a system, tokens can be revoked upon expiry of their validity date,to the declaration by the service provider or the user to a dedicated endpoint on the central system, or even by the central system itself on its own criteria (security or related to system management). Often, in this type of architecture, the system stores the valid tokens it has issued in its database, an erasure process being activated when their validity date expires or upon voluntary deletion. In other more asynchronous systems, the service provider may be required to manage a blacklist comprising the set of revoked tokens, or a whitelist comprising the set of valid tokens, both lists being fed by the central system. Finally, in systems where the user's equipment is controlled by the central system,the deletion of the token can be carried out on the user's equipment by the central system. The token non-revocation proofs of the current state of the art either do not offer any anonymity to the user, or a computational anonymity that could be lifted by attackers with powerful quantum computers, or are too costly to be generated by devices (such as smart cards) with limited computing power or even involve operations not supported by these devices (bilinear couplings for example). The present disclosure aims to improve these revocation mechanisms and in particular, in at least certain embodiments, to offer a cryptographic solution that is both anonymous (the token non-revocation proofs do not reveal any information about the owner of the token),involving only classical mathematical operations and resistant to attacks by quantum computers or more generally having unlimited computing power. Purpose and summary of the invention Thus, and according to a first aspect, the present disclosure relates to a method for managing at least one anonymous verifiable accreditation, the method being implemented by an accreditation management device and comprising the following steps: - generation of an anonymous verifiable accreditation relating to a plurality of attributes, one of which is an identifier of this accreditation; - updating a list of accreditation identifiers accumulated in a cryptographic accumulator by adding or removing said identifier (^^) and the value ^^^^ from the accumulator,said list being: (i) either a white list containing valid identifiers; (ii) or a black list containing invalid identifiers; - calculation of a witness representing: (i) the membership of said identifier in a white list; or (ii) the non-membership of said identifier in a black list and (iii) a proof associated with said witness; - sending to a user: (i) said anonymous verifiable accreditation (ii) a proof of the validity of said anonymous verifiable accreditation; (iii) said identifier of said anonymous verifiable accreditation; and (iv) said witness and the proof associated with said witness. Correlatively,the disclosure relates to an accreditation management device comprising: - a module for generating an anonymous verifiable accreditation relating to a plurality of attributes, one of which is an identifier of this accreditation; - a module for updating a list of accreditation identifiers accumulated in a cryptographic accumulator by adding or removing said identifier and the value of the accumulator,said list being: (i) either a white list containing valid identifiers; (ii) or a black list containing invalid identifiers; - a module for calculating a witness representing: (i) the membership of said identifier in a white list; or (ii) the non-membership of said identifier in a black list and (iii) proof associated with said witness; - a module for sending to a user: (i) said anonymous verifiable accreditation (ii) proof of the validity of said anonymous verifiable accreditation; (iii) said identifier of said anonymous verifiable accreditation; (iv) said witness and the proof associated with said witness. Thus, and in general, the accreditation generation device can, preferably after having authenticated a user, generate an accreditation, in other words certify or attest that attributes of this user are valid. These attributes can be public attributes, for example sovereign (name,first name, date of birth, address, etc.). In a particular embodiment, one of said attributes is a commitment relating to a secret attribute of the user, for example a secret key of the user. In which case, the user does not provide the secret attribute as such but a commitment (or pledge) on this secret attribute. The pledge schemes are mechanisms known to those skilled in the art of cryptography and will be recalled below. Very advantageously, the present disclosure proposes to manage the list of valid or revoked accreditation identifiers by cryptographic accumulators. The list of valid or revoked identifiers is thus a compressed list whose size is not a function of the number of identifiers it represents. In one embodiment of the present disclosure, to generate the compressed list of revoked (respectively non-revoked) identifiers,we use the dynamic universal accumulator proposed by reference [1] with the adaptations presented below so that it can be supported by constrained devices such as secure elements (SE) which do not implement certain mathematical operations such as the couplings classically used by this type of accumulator). [1]: Giuseppe Vitto, Alex Biryukov: Dynamic Universal Accumulator with Batch Update over Bilinear Groups. CT-RSA 2022: 395-426. In a particular embodiment: (i) the value ^^ of the accumulator after adding a value ^^ (or ^^, ^ ) to a black or white list is calculated by ^^ ൌ ^^ᇱ௬ାఈ ;- the witness of belonging of said identifier to said white list is calculated by ^^ ൌ ^^௬,^ ൌ - the evidence Π^ associated with this witness ^^௬,^ is Π^ ൌ Πఠ^,ೇ=PoK^^^: ^^ - the value ^^ of the accumulator after removing a value ^^ (or ^^ ^) to a blacklist is భwhite is calculated by ^^ ൌ ^^ᇱ ^శ^ ; - the witness of non-membership of said identifier ^^^^ to said black list is calculated by - the evidence Π^ associated with this witness ^ഥ^ ఈ௬,^ is Π^ ൌ Πఠഥ ఈ ^,ೇ=PoK^^^: ^^ ൌ ^ഥ^௬,^ ⋀ ^^^ ൌ ^^^^ where :- ^^, ^^^, ^^ଶ are public generators of said accumulator ;- ^^ is an integer belonging to {1, 2,…, p-1}, the private key ^^^^ of the credential management device for managing the accumulator is equal to ^^- ^^ ൌ ^ ఈ ఈ^ ^^ , ^^ଶ ൌ ^^ଶ- the public key ^^^^ for managing the accumulator is ^^^^ ൌ ^^^^, ^^ଶ^- ^^=^^^^ ି௬ =^^ ఈ - ^^ ᇱ is the value of the accumulator before said update ;- ^^ ൌ ^^^^െ^^^ where ^^^ is a polynomial defined by being a list of secret values ​​used to initialize the accumulator and ^^ ^the set of elements accumulated in the accumulator V excluding the initialization elements- ^^^ is an initial value of the accumulator: ^^^ ൌ In a particular embodiment of the present disclosure, the anonymous verifiable credential is a blind signature computed using a private key of the said credential management system. It is recalled that accreditations are personal attestations allowing a user to convince a third party that he or she has a particular authorization or qualification. They are specific to an individual and generated by a trusted entity, via the use of digital signatures. However, standard digital signature mechanisms require revealing the entirety of the certified data, even to prove the authenticity of only part of it, and allow users to be traced. In the present disclosure, an anonymous accreditation mechanism as introduced by Chaum (David Chaum: Showing Credentials Without Identification: SIgnatures Transferred Between Unconditionally Unlinkable Pseudonyms. EUROCRYPT 1985: 241-244 ) can be used. Such a system allows a user to prove that his or her attributes (surname, first name, date of birth, address, gender, etc.) have been certified, without revealing any superfluous information. Very advantageously, it should be noted that the accreditation manager generates the accreditation using a blind signature calculated with its private key so that any service provider can verify its validity using the public key of the accreditation manager. In a particular embodiment, the blind signature is a message authentication code with a group structure, known to those skilled in the art as an algebraic MAC. It is recalled that a MAC is a cryptographic primitive that allows messages to be authenticated but where a single secret key is used for both its generation and its verification. This primitive therefore differs from the digital signature which can be verified by everyone, using a public key.In a particular embodiment, the present disclosure uses more specifically the anonymous credentials scheme with key verification proposed by Barki et al. in section 4.3 of the document Amira Barki, Solenn Brunet, Nicolas Desmoulins, Jacques Traoré: Improved Algebraic MACs and Practical Keyed-Verification Anonymous Credentials. SAC 2016: 360-38. This allows the credential manager to generate anonymous credentials that any service provider can verify using the manager's public key. This scheme is particularly advantageous in the context of the present disclosure, because the successive use of the same credential cannot be detected, which avoids any risk of tracing. It also makes it possible to certify certain attributes without revealing them, this signature scheme making it possible to sign pledged messages and on the other hand to efficiently prove knowledge of a signature without revealing it.In a particular embodiment, the management method further comprises calculating a proof of the validity of the verifiable accreditation and sending said proof to the user. This proof makes it possible to convince the user of the validity of the accreditation. In a particular embodiment, the proof is a proof with a designated verifier, such that only the user can be convinced of the validity of the accreditation. The zero-knowledge proof mechanism is a mechanism known to those skilled in the art of cryptography and is recalled below. In a particular embodiment of the present disclosure, said anonymous verifiable accreditation is a pair ^^^, ^^^ calculated according to the BBS+ protocol defined by public parameters ^^^^ with ^^^^ ൌ^^^, ^^^, ^^ଶ, ^^், ^^, ^^, ^^, ^^^, ^^^, ^^ଶ, .. , ^^^, ^^^ା^, ℎ^, ℎଶ, .., ℎ^, ℎ, ^^, ^^^, ^^ଶ^ where: - denotes a bilinear environment for which the problem q SDH is difficult; - p is a prime integer which denotes the order of the cyclic groups ^^. ^ , ^^ ଶ and ^^ ் - ^^, ^^^, ^^^, ^^ଶ, .. , ^^^, ^^^ା^ designate n+3 randomly chosen ^^^ generators, each ^ ^^^ ^ ^ ^ ୀ^ being associated with a specific attribute type; are the public generators of said accumulator; - ℎ denotes a generator of ^^ ଶ , and in which: ^^ ᇱᇱ ^, ^^^ ᇱᇱ , ^^ ଶ ᇱᇱ ,…, ^^ ᇱᇱ^ , ^^ ∈ ^^∗^ are random values ​​chosen by said accreditation management device. According to a second aspect, the disclosure relates to a method implemented by a user device, this method comprising the following steps: - receiving, from an accreditation management device: (i) at least one anonymous verifiable accreditation relating to a plurality of attributes, one of which is an identifier of this accreditation; (ii) proof of the validity of said anonymous verifiable accreditation; (iii) the identifier of said anonymous verifiable accreditation; (iv) a witness of the membership of said identifier in a white list of valid identifiers or of the non-membership of said identifier in a black list of invalid identifiers, said white or black list being a list of elements accumulated in a cryptographic accumulator; (v) proof associated with said witness;- obtaining proof of non-revocation of the identifier of said anonymous verifiable accreditation of interest consisting of: (i) proof that said identifier of said anonymous verifiable accreditation of interest belongs to said white list or by (ii) proof that said identifier of said anonymous verifiable accreditation of interest does not belong to said black list; - use of at least one of said attributes to exercise a user right at least on condition of obtaining proof of the validity of said accreditation and of the non-revocation of said identifier. Correlatively, the disclosure relates to a device comprising: - a receiving module, from an accreditation management device: (i) at least one anonymous verifiable accreditation relating to a plurality of attributes, one of which is an identifier of this accreditation; (ii) proof of the validity of said anonymous verifiable accreditation;(iii) the identifier of said anonymous verifiable accreditation; (iv) a witness of the membership of said identifier in a white list of valid identifiers or of the non-membership of said identifier in a black list of invalid identifiers, said white or black list being a list of elements accumulated in a cryptographic accumulator; (v) a proof associated with said witness; - a module for obtaining a proof of non-revocation of the identifier of said anonymous verifiable accreditation of interest consisting of: (i) a proof that said identifier of said anonymous verifiable accreditation of interest belongs to said white list or by (ii) a proof that said identifier of said anonymous verifiable accreditation of interest does not belong to said black list;- a module for using at least one of said attributes to exercise a user right at least on condition of obtaining proof of the validity of said accreditation and of the non-revocation of said identifier. In a particular embodiment, this method is a method for requesting access to a service in which said at least one anonymous verifiable accreditation relates to a plurality of attributes of the user, said method further comprising the following steps; - selecting at least one said anonymous verifiable accreditation called "of interest" relating to at least one attribute of interest for a provider of said service; - sending, to said service provider: (i) a verifiable presentation comprising at least one refreshed accreditation obtained from said anonymous verifiable accreditation of interest allowing the service provider to obtain said at least one attribute of interest;(ii) said proof of non-revocation of the identifier of said anonymous verifiable accreditation of interest. In a particular embodiment: (i) proof that said identifier ^^ of said anonymous verifiable accreditation of interest; ^ ^^ ூ^ belongs to the said white list is of the type ^^^^ ൌ ^^^, ^^^, ^^ோா^^, with: ^^ ൌ ^^^, where ^^ ∈ ^^∗^ (note that this value ^^ should not be confused with the value ^^ of equation (EQ) presented later). Let A^=C୪^ ൌ A^ and A^ =Aି^. We therefore have A^ ൌ V୪A^ୟ^^^ = PoΚ^^ ^ ^ ^௬ோா^ ^, ^^^ : ^^ ൌ ^^ ^^ ^(ii) the proof that said identifier ^^^ ൌ ^^^^ of said anonymous verifiable accreditation of interest ^^^^^ூ^ does not belong to said blacklist is of the type ^^^^ ൌ ^^^, ^^^, ^^ோொ^, with: where :- ^^, ^^^, ^^ଶ are public generators of said accumulator ;- ^^ is an integer belonging to {1, 2,…, p-1}, the private key ^^^^ of the credential management device for managing the accumulator being equal to ^^- ^^ ൌ ఈ ఈ^ ^^^ , ^^ଶ ൌ ^^ଶ- the public key ^^^^ for managing the accumulator is ^^^^ =(^^ ^ , ^^ ଶ ) - ^^=^^^^ ି௬ =^^ ఈ - ^^ ᇱ is the value of the accumulator before said update ;- ^^ ൌ ^^^^െ^^^ where ^^^ is a polynomial defined by ^^^^^^^ ൌ ∏௬∈^^ೇ∪^^ೇబ ^^^ ^ ^^^ , ^^^బ being a list of secret values ​​used to initialize the accumulator- ^^^ is an initial value of the accumulator: ^^^ ൌ To check the validity of π ^^ , we must ensure that the following equality is satisfied e^A, f ^ ଶ ^ ൌ e^A^, fଶ^ and on the other hand that πୖ^^ is valid. The verification algorithm of thisZKP (π ୖ^^) being relatively classic for those skilled in the art, we will not detail it in this document. For more information; those skilled in the art can refer to the document David Chaum, Torben P. Pedersen: Wallet Databases with Observers. CRYPTO 1992: 89-105 If π ^^ is valid then, we easily demonstrate that we necessarily know C and a ୬ ^such that C ൌ ω^,^ ൌ V ൗ ^^ା^^ and therefore that, under the q-SDH hypothesis, y is indeed accumulated in V. Furthermore and very advantageously, we demonstrate mathematically that the proof π ^^ defined in this way does not reveal any information about the value ^^ (for example about the user's accreditation identifier, including for a user with unlimited computing power and therefore a fortiori for an attacker with a quantum computer). ^ S oit C′ ൌ V ൗ ^^ᇱା^^, the witness of belonging to the identifier (y′) of the accreditation of a user ^^′ (different from the user ^^ having generated the proof π ^^ ), to the list of valid identifiers. We have of course y′ ് y. On the one hand, we will demonstrate that the user ^^′ could just as easily have generated the same proof π ^^ (i.e. by producing exactly the same values ​​A, A^ and πୖ^^) and on the other hand that no one, including an attacker with unlimited computing power, is able to know which of ^^ or ^^′ generated the proof: π^^ ൌ ^A, A^, πୖ^^^. As C′ is an element of a cyclic group of order p and C′ is different from 1 (the neutral element of this group), this implies that there exists an integer l′ ∈ Z∗ ୪ ᇲ ୮such that A ൌ C′. ୪ ᇲ We therefore have A ൌ V ൗ ^^ᇱା^^ and therefore that A^ᇱା^ ൌ V୪ᇲ. This implies, by reusing the notations above, that A^ ൌ V୪ᇲA^^ᇱ. We have therefore just shown that ^^′ could also have produced the values ​​A and A^ . Since the proof π ୖ^^ , which is, let us recall, classic for those skilled in the art, is statistically proven ZK, it therefore reveals no information, even when faced with an attacker with unlimited computing power, on the secret pair (l, y) used to produce the proof π ୖ^^ . Therefore, an attacker, even one with unbounded computing power, has no way of determining which of ^^ or ^^′ generated the proof: π^^ ൌ ^A, A^,π ୖ^^ ^. This therefore concludes the demonstration that π ୖ^^ guarantees eternal confidentiality (Everlasting Privacy). Similarly, to check the validity of π ^^ , we must on the one hand ensure that the following equality is satisfied e^A, f^ଶ ^ ൌ e^A^, fଶ^ and on the other hand that π^^^ is valid. The verification algorithm of this ZKP (π ^^^^ being relatively classic for those skilled in the art (see for example [2] and [3]), we will not detail it in this document. [2]: David Chaum, Torben P. Pedersen: bWallet Databases with Observers. CRYPTO 1992: 89-105 [3]: Stefan Brands: Rapid Demonstration of Linear Relations Connected by Boolean Operators. EUROCRYPT 1997: 318-333 If π ^^ is valid then, we easily demonstrate that the user necessarily knows values ​​C, d ് 0 and y such that C ൌ ωഥ ^,^ ൌ and therefore that, under the q-SDH hypothesis, a ୬ is not accumulated in V. It is understood that the user will have to, in addition to his VP, also transfer this proof of knowledge π ^^ to the service provider in order to convince them that the VP does indeed contain an unrevoked VC. The eternal confidentiality provided by π ^^ is demonstrated in the same way as in the previous case with π ^^.It should be noted that the state-of-the-art ZKP zero-knowledge proofs for π ^^ or π ^^ , either offer no anonymity to the user, or computational anonymity (which could be lifted by attackers with powerful quantum computers), or are too expensive to be generated by devices (such as smart cards) with limited computing power or even involve operations not supported by these devices (bilinear couplings for example). The π proofs ^^ or π ^^on the other hand, in this disclosure do not reveal any information about the user who presents it (including for an attacker with unlimited computing power) and only involve classic mathematical operations (addition of points or scalar multiplications on elliptic curves) and are sufficiently efficient to be executed by smart cards.According to a third aspect, the disclosure relates to a method for controlling access to a service by a user, said method being implemented by a service provider and comprising the following steps: - obtaining a verifiable presentation comprising an anonymous verifiable accreditation of interest relating to attributes of interest of the user and proof of non-revocation of an identifier of said anonymous verifiable accreditation of interest; - verification of said at least one attribute of interest; - verification of the validity of said proof of non-revocation; - verification of said anonymous verifiable accreditation of interest included in said verifiable presentation, - a positive result of a verification of said at least one attribute and obtaining proof of the validity of said accreditation and of the non-revocation of said identifier being necessary conditions for authorizing the user to access said service.Correlatively, the disclosure relates to a device for controlling access to a service by a user, said device comprising: - a module for obtaining a verifiable presentation comprising an anonymous verifiable accreditation of interest relating to attributes of interest of the user and proof of non-revocation of an identifier of said anonymous verifiable accreditation of interest; - a module for verifying said at least one attribute of interest; - a module for verifying the validity of said proof of non-revocation; - a module for verifying said anonymous verifiable accreditation of interest included in said verifiable presentation, - a positive result of a verification of said at least one attribute and obtaining proof of the validity of said accreditation and of the non-revocation of said identifier being necessary conditions for authorizing the user's access to said service.Thus, in at least one embodiment, all of the cryptographic mechanisms implemented by the invention make it possible to constitute a compressed list of revoked accreditation identifiers, and to prove that the identifier of an accreditation held by the user is not present in this list. This zero-knowledge proof does not reveal any information about the identifier used by the user. In other words, even an attacker with a quantum computer or unlimited computing power will not be able to identify the user at the origin of this ZKP. Typically, if to access a service, the user must present to the service provider a valid (i.e. non-revoked) proof of majority issued by an accredited identity provider, this user will have the guarantee that no one will be able to know that in the past he accessed this service.The user's privacy is therefore maximally protected with unlimited confidentiality (this type of protection is known as Everlasting Privacy). The disclosure also relates to a computer program comprising instructions for carrying out the steps of a method as described above when said program is executed by a computer. This program may use any programming language, and be in the form of source code, object code, or intermediate code between source code and object code, such as in a partially compiled form, or in any other desirable form. The disclosure also relates to a computer-readable information carrier comprising instructions of a computer program as mentioned above. The information carrier may be any entity or device capable of storing the program.For example, the medium may comprise a storage means, such as a ROM, a non-volatile memory of the flash type or a magnetic recording means, for example a hard disk. Furthermore, the information medium may be a transmissible medium such as an electrical or optical signal, which may be conveyed via an electrical or optical cable, by radio or by other means. The program according to the disclosure may in particular be downloaded from a network such as the Internet. Alternatively, the information medium may be an integrated circuit in which the program is incorporated, the circuit being adapted to execute or to be used in the execution of the method in question. Brief description of the drawings: Other characteristics and advantages of the present invention will emerge from the description given below, with reference to the appended drawings which illustrate exemplary embodiments thereof without any limiting character. In the figures: [Fig.1] Figure 1 represents a system comprising a device for managing at least one anonymous verifiable accreditation, a device for requesting access to a service and a device for controlling access to a service in accordance with particular embodiments of the present disclosure; [Fig. 2] Figure 2 represents in the form of flowcharts steps of a method for managing at least one anonymous verifiable accreditation, a method for requesting access to a service and a method for controlling access to a service in accordance with particular embodiments of the present disclosure; [Fig. 3] Figure 3 represents the hardware architecture of the devices of Figure 1 in a particular embodiment of the present disclosure. As a preliminary, we recall cryptographic tools used in the present disclosure. 1.Pledging Schemes Pledging a value is a cryptographic process that allows an issuer to commit a value to a recipient without revealing it at first glance and in such a way that this commitment cannot be modified later. This value can be, if necessary, revealed subsequently by the issuer. Thus, the recipient has the assurance that once the commitment is published, the issuer can no longer change its mind about the value contained in this commitment. In a particular embodiment, the present disclosure may use the pledging scheme proposed by Pedersen in 1992 (Torben P. Pedersen. Non-interactive and information-theoretic secure verifiable secret sharing. In Joan Feigenbaum, editor, CRYPTO'91, volume 576 of LNCS, pages 129–140.Springer, Heidelberg, August 1992), which has the particularity of producing perfectly indistinguishable commitments (perfectly hiding in English) and computationally collision-resistant. Presentation of the Pedersen pledging scheme In a Pedersen pledging scheme we consider a cyclic group ^^ of prime order ^^ and ^^ and ℎ two arbitrary generators of ^^. We assume that the discrete logarithm of ℎ in base ^^ is unknown. For a "pledging" operation in which a sender commits to a message ^^ ∈ ^^. ^ from a recipient, the sender chooses a random value ^^ ∈ ^^ ^,calculates ^^ ൌ ^^^ℎ^ and sends it to the recipient. For an "open" operation, the sender sends the recipient the message ^^ and the random value ^^ so that the latter checks the equality: ^^ ൌ ^^^ℎ^. The above process can be easily generalized by pledging several messages, for example ^^ messages (^^^, ^^ଶ, … , ^^^^. Let ^^ be a cyclic group of prime order ^^ and ^^ ^ 1 be any generators of ^^ :^^^, ^^ଶ, … , ^^^ and ℎ. To commit to messages ^^^, ^^ଶ, … , ^^^ ∈ ^^^ of its choice, the sender chooses a random value ^^ ∈ ^^^ and calculates ^^ ൌ ^^ ^భ ^ ൈ ^^ ^మ ଶ ൈ⋅⋅⋅ൈ ^^ ^^^ ൈ ℎ^ and sends it to the recipient. For the opening operation, the sender sends the messages ^and the random value ^^ to the recipient so that the latter checks the equality: ^^ ൌ ^^ ^భ ^ ^ ൈ ^^ଶ మ ൈ⋅⋅ 2. Zero-Knowledge Proofs It is recalled that a so-called Zero-Knowledge Proof (ZKP) allows a verifier to convince himself that a certain prover knows a secret S satisfying a given predicate P, the proof revealing no information to the verifier about the secret S in question other than the fact that the latter verifies the given predicate P. Subsequently, to represent zero-knowledge proofs, we will sometimes use the usual notationPoK^α, β, …: predicate on α, β, … ^. In certain embodiments, the present invention further uses the designated verifier proof mechanism notably described in (Markus Jakobsson, Kazue Sako, Russell Impagliazzo: Designated Verifier Proofs and Their Applications. EUROCRYPT 1996: 143-154). 3.Group Signatures and Anonymous Signatures In a particular embodiment, some devices may use an anonymous signature scheme (a variant of a group signature scheme), such schemes allowing a requester to prove its membership in a group (here a group of service providers) without revealing its exact identity. In particular, group signatures have the particularity of being anonymous (the signatory cannot be identified) and untraceable (it is not possible to determine whether two signatures were issued by the same person or by two distinct people). The validity of a group signature can be verified by anyone using a public key characterizing the group (called a "group public key"). To be part of the group, a requester must register with a group manager.During this registration phase, the future member blindly obtains a group private key that will allow them to sign messages on behalf of the group. "Blindly" means in this context that the group manager does not know the private key obtained by the requester. As is well known, only a trusted authority (called a revocation authority or simply RA) has the power to revoke the anonymity of a group signature, thanks to a trapdoor (a private key) that only it possesses. In practice, this trapdoor is shared between several trusted authorities (generally called revocation authorities) and it is necessary for them all to cooperate to lift the anonymity of a signature. The group member is thus protected against abusive anonymity liftings. In such a scheme, the group manager (^^^^) has a pair of keys, private and public (denoted ^^^^^ெீ, ^^^^ெீ^^ and a digital signature algorithm.During the registration phase, the group member (noted ^^) receives from the group manager ^^^^ a signature ^^ on a public key PK generated for the occasion (of which only he knows the associated private key SK: ^^ ൌ ^^^^^^^^ௌ^ಾಸ^^^^^^ . The group public key is ^^^^ெீ. while the user's private key is SK and his membership certificate is (^^^^, ^^). To prove to a service provider or any other third party that he is indeed part of the group managed by ^^^^ , the user ^^ encrypts his public key PK using the public key^^^^ோ^ of the revocation authority RA ( ^^^ ൌ ^^^^ೃಲ^^^^^^ ), then encrypts ^^ ( ^^ଶ ൌ ^^^^ೃಲ^^^^ )always with the public key ^^^^. ோ^ . The user generates a zero-knowledge proof ^^ demonstrating that he knows the plaintext of ^^ on the one hand ^ (i.e. ^^^^) but also the private key corresponding to this plain text (i.e. ^^^^) and on the other hand that the plain text of ^^ ଶ(i.e. ^^) is indeed a signature of ^^^^ on the plaintext of ^^ ^ (i.e. PK). The group signature consists of (^^ ^ , ^^ ଶ, ^^). In a particular embodiment, the Delerablée-Pointcheval group signature algorithm may be used (Cécile Delerablée, David Pointcheval: Dynamic Fully Anonymous Short Group Signatures. VIETCRYPT 2006: 193-210). For this algorithm, the revocation authority has a key pair of the El-Gamal encryption algorithm (El Gamal, T.: A public key cryptosystem and a signature scheme based on discrete logarithms. In: Blakely, G.R., Chaum, D. (eds.) CRYPTO 1984. LNCS, vol. 196, pp. 10–18. Springer, Heidelberg (1985)). Any other group signature scheme may, however, be implemented in this disclosure. 4. Cryptographic accumulator 4.1 Principle We recall that a cryptographic accumulator makes it possible to aggregate several different values ​​from a finite set into a fixed-length digest (typically 256 bits) called the accumulator value.Unlike hash functions, cryptographic accumulators provide different methods to easily check whether an element is accumulated (respectively not accumulated) in a given accumulator value via membership (respectively non-membership) witnesses. In other words, given a membership witness ^^ for an accumulated element ^^ and the current accumulator value ^^, it is possible to efficiently check that the element ^^ is indeed part of the accumulated list. Cryptographic accumulators that only support membership witnesses are called positive accumulators, those that only support non-membership witnesses are called negative accumulators, while those that support both are called universal accumulators.A common requirement for cryptographic accumulators is the ability to modify the set of accumulated elements, which allows for accumulator updates. In the embodiment described here, a cryptographic accumulator manager entity defines the public parameters of this cryptographic accumulator: ^^^^ ൌ^^^, ^^^, ^^ଶ, ^^், ^^, ^^, ^^^, ^^ଶ^ where: - e: a bilinear matching defined from ^^^ ൈ ^^ଶ to a set ^^் where ^^^, ^^ଶ and ^^் denote cyclic groups of order ^^, ^^ being a prime number. For simplification, we assume that the group law in ^^. ^ and ^^ ଶ is multiplication; - ^^ and ^^ ^ designate two generators of ^^ ^ chosen randomly, so that the discrete logarithm of one of these generators is unknown relative to another of these generators; and - ^^ ଶ denotes a generator of ^^ ଶrandomly chosen In the following, all calculations involving exponents will be performed modulo ^^. 4.2 Key Generations: In one embodiment of the present disclosure, the cryptographic accumulator manager randomly generates an integer ^^ belonging to {1, 2,…, p-1} and calculates ^^^ ൌ ^^ఈ ^ as well as ^^ଶ ൌ ^^ఈଶ . The private key ^^^^ of the cryptographic accumulator manager can be chosen equal to ^^ and its public key ^^^^ can consist of the paireAs is known to those skilled in the art of cryptography, the value of the accumulator evolves according to the values ​​that can be added or removed from it. We denote ^^ the value of the accumulator at a given time and ^^^ the list of values ​​accumulated in the accumulator ^^. 4.3 Initialization of the accumulator In one embodiment of the present disclosure, the accumulator manager generates a certain number of random values ​​^^^ ∈ ^^^ which must remain secret. We denote ^^ ^బ this list of secret values ​​and by ^^ ^ the initial value of the accumulator: ^^ ∏ ^௬ା ఈ ^ ൌ ^^ ^∈^^ೇబ ^ . 4.4 State of the accumulator The state of the accumulator ^^ at a given instant is characterized by a pair (^^, ^^ ^ ) where ^^ ∈ ^^ ^ is the value of the accumulator and where ^^ ^ denotes the set of elements accumulated in ^^, excluding elements 4. 5 Updating the Accumulator In one embodiment of the present disclosure, to add an element ^^ to the accumulator in the current state (^^ ', ^^^ᇱ), the accumulator manager performs the following calculation: ^^ ൌ ^^′௬ାఈ. The new state of the accumulator becomes (^^, ^^௩) where ^^௩ = ^^௩ᇱ ∪^^^^. In one embodiment of the present disclosure, to remove an element ^^ from the accumulator in the current state (^^′, ^^ ^ᇱ ), the accumulator manager performs the following ^calculation: ^^ ൌ ^^′ ൗ ^௬ାఈ^ . The new state of the accumulator becomes (^^, ^^ ௩ ) where ^^ ௩ = ^^ ௩ᇱ \^^^^. 4. 6 Calculation of a membership witness Let ( ^^ , ^^^ ) be the current state of the accumulator and ^^ be a value belonging to ^^^ and accumulated in ^^, we note the certificate or witness of ^^'s membership in the list ^^ ^and relative to the current value ^^ of the accumulator. This ownership witness can be generated by the accumulator manager and used by the user to prove, using a zero-knowledge proof of knowledge, that the value ^^ belongs to ^^ ^ and is therefore accumulated in ^^. In one embodiment of the present disclosure, the witness ^^ ௬,^ of ^^'s membership in the list ^^ ^ is calculated as follows by the accumulator manager: In one embodiment of the disclosure, the accumulator manager generates a zero-knowledge proof, denoted Π ఠ^,ೇ proving the validity of this witness ^^ ௬,^or ^^ of membership in the accumulator ^^. We can notice that ^^ ൌ ^^௬ାఈ . Let us denote by ^^ = ^^^^ି௬ = ^^ఈ . The membership witness ^^ is therefore valid if the discrete logarithm of ^^ in the base ^^ is equal to the discrete logarithm of ^^^ in the base ^^^: ఈ ൌ ^^^ ^. Since only the accumulator manager knows ^^ , only it can generate this proof. In a particular embodiment, the accumulator manager can transmit the ownership witness ^^ (or and the proof to a user who can verify the validity of His witness ^^ will only be valid if the proof is also. 4. 7 Calculation of a non-membership witness Let (^^, ^^ ^ ) the current state of the accumulator and ^^ a value not belonging to ^^ ^ and therefore not accumulated in ^^. In one embodiment, we designate by ^^^^^^^, the polynomial ^^^ ^^^^. We note ^^ ൌ ^^^^െ^^^ . If ^^ ് 0, we denote by ^ഥ^௬,^ the certificate or witness of non-membership of ^^ to the list ^^^ and relative to the current value ^^ of the accumulator. This witness of non-membership can be generated by the accumulator manager and used by a user to prove using a zero-knowledge proof of knowledge, that this value ^^ does not belong to ^^ ^ and is therefore not accumulated in ^^. In one embodiment of the present disclosure, the witness ^ഥ^ ௬,^ of the non-membership of ^^ to the list ^^^ is calculated in the following way, for example by the accumulator manager: ^ ^^ ൌ ^ഥ^௬,^ ൌ ^^ ൗ ^௬ାఈ^ ିௗ ^^ ൗ ௬ାఈ . In one embodiment of the disclosure, the accumulator manager generates a zero-knowledge proof, denoted proving the validity of this witness of non-membership in the accumulator ^^. We can note that ^^^^ିௗ ൌ ^^௬ାఈ. Let us denote by ^^=^^^^ିௗ^^ି௬=^^ఈ. The witness ^^ will therefore be valid if the discrete logarithm of ^^ in the base ^^ is equal to the discrete logarithm of ^^ ^ in the base ^^ ఈ ^ : ൌ ^^^ ^ . Since only the accumulator manager knows ^^, only it is able to generate this proof. The accumulator manager can transmit the witness ^^ (or ^ഥ^ ௬,^ ) and ^^ as well as the proof Πఠഥ ^,ೇ to the user. After receiving ^^ and Πఠഥ ^,ೇ , the user can check the validity of Π ఠഥ ^,ೇ . His witness ^^ will only be valid if the proof Π ఠഥ ^,ೇ is also and that ^^ ് 0. It is remarkable to note that the evidence and Π ఠഥ ^,ೇ can be verified by constrained devices such as secure elements, because it only involves operations in the group ^^ ^, (which are supported by these devices) unlike the proofs proposed by the state of the art which require pairing calculations not supported by such devices. 4. 8 Updating a Membership or Non-Membership Witness In the embodiment described here, the membership or non-membership witness of a user must be updated each time the list is modified. The witness can be updated by the accumulator manager; the user can then obtain it from the manager. Alternatively, the user can himself, that is to say without calling the accumulator manager, update his membership (respectively non-membership) witness in the case where a new value is added to or removed from the accumulator.In the paragraphs below, we will assume that a user has already received a membership or non-membership witness for a value ^^∗ , and we will note (^^ , ^^^ ) the current state of this accumulator. 4.8.1 Updating a membership witness by adding a value: We assume that a value ^^′ is added to the accumulator which therefore passes from the state (^^, ^^. ^ ) to the new state ( ^^′ , ^^ ᇱ ௬ᇱାఈ^ᇲ ) where ^^ ൌ ^^ . The user can update his / her membership witness by performing the following calculation: ^^′ ൌ ൈ ^^ where ^^ denotes the current value of the user's membership witness and ^^ ∗ the user's value. 4.8.2 Updating a membership witness by removing a value: We assume that a value ^^′ is removed from the accumulator which therefore passes from the state (^^, ^ ^^^) to the new state (^^′, ^^^ᇲ) where ^^′ ൌ ^^ ൗ ^௬ᇱାఈ^ The user can update his / her membership witness by performing the following calculation: where ^^ denotes the current value of the user's membership witness and ^^ ∗ the value for which this accumulator was created. 4.8.3 Updating a non-membership indicator by adding a value: We assume that a value ^^′ is added to the accumulator which therefore passes from the state (^^, ^^ ^ ) to the new state ( ^^′ , ^^^ᇲ ) where ^^ᇱ ൌ ^^௬ᇱାఈ. The user can update his / her membership witness by performing the following calculation: ^^′ ൌ ^^^௬ᇲି௬∗^ ൈ ^^ where ^^ denotes the current value of the user's non-membership witness and ^^ ∗ the value for which this accumulator was created and ^^ᇱ ൌ ^^ ൈ ^^^ᇱ െ ^^∗^.4.8.4 Updating a non-membership indicator by removing a value: We assume that a value ^^′ is removed from the accumulator which therefore passes from the state (^^, ^^ ^ )to the new state ( ^^′ , ^^^ᇲ ) where The user can update his / her membership witness by performing the following calculation: where ^^ denotes the current value of the user's non-membership witness and ^^ ∗ the value for which this accumulator was created and ^^ᇱ ൌ ௬ ᇲ ି௬. First example of implementing the disclosure In a first example of implementing the disclosure, we consider an identity provider, a service provider and a user. Identity provider In at least one embodiment, an identity provider is an entity whose role is to issue anonymous verifiable credentials (in English Verifiable Credential VC) to users, relating to their identity elements, after having authenticated them. The latter will be able to present them upon access to a service either to prove who they are or one or more of their qualities. In a particular embodiment of this disclosure, the identity provider can use the BBS+ protocol to certify the attributes of the users.In a particular embodiment, the identity provider also manages a compressed list of revoked anonymous verifiable credentials VC (or a list of non-revoked credentials) through a cryptographic accumulator. In a particular embodiment, the identity provider can provide users, following the delivery of their anonymous verifiable credential VC, with their membership (respectively non-membership) witnesses to the compressed list of valid (respectively revoked) verifiable credentials. Service provider In one embodiment, a service provider delivers a service to users after ensuring that the latter actually meet the conditions for accessing this service. For example, for access to an adult content site, the service provider has a legal obligation to ensure that the user is of legal age.The user must therefore provide proof of his or her majority through a Verifiable Presentation (VP) generated from an anonymous verifiable credential, certifying his or her age, issued by an identity provider trusted by the service provider. In one embodiment of the present disclosure, the service provider must verify that the Verifiable Presentation (VP) presented to him or her was indeed generated from a valid, i.e., unrevoked, anonymous verifiable credential (VC).Users In one embodiment of the present disclosure, users have one or more anonymous verifiable credentials and their respective membership (or non-membership) witnesses to the compressed list of valid credentials (or to the compressed list of revoked credentials), allowing them to prove their identity or qualities (majority, seniority, qualifications, etc.) to a service provider, in order to access the service offered by this provider. In one embodiment, users have a digital identity wallet (ID Wallet) allowing them to store and manage their various anonymous verifiable credentials and to generate the VP verifiable presentations for access to the services of the service providers.The private keys and secrets of users used in particular by users to prove that the anonymous verifiable credentials VC that they present belong to them are preferably stored in secure devices such as secure elements (Secure Element), hardware security modules (HSM) or in trusted execution environments (TEE). We will now describe an example of implementation of this disclosure in which a D-FI identity provider generates an anonymous verifiable credential VC relating to secret attributes and public attributes of a D-USR user, using his private key ^^^^. ^. In this example, when the identity provider produces a credential ^^^^ for a user, it inserts the identifier (e.g., a serial number) of this credential among the aforementioned public attributes. In this example, the identity provider also manages a whitelist containing the identifiers of valid credentials or a blacklist containing the identifiers of invalid or revoked credentials. It also manages a cryptographic accumulator in which the identifiers of the whitelist or the blacklist are accumulated. The identity provider provides the user with their anonymous credential ^^^^, a witness that the identifier of their credential is on the whitelist or a witness that this identifier is not on the blacklist, and a proof associated with this witness.In this example, the user refreshes this credential ^^^^ and sends the refreshed credential to a D-FS service provider in a verifiable presentation VP along with attributes of interest requested by the D-FS service provider. In the embodiment described herein, the user also sends to the service provider a proof of non-revocation of the identifier of his credential. In this example, the service provider verifies the proof of non-revocation of the identifier of the user's credential, signs the verifiable presentation VP with a group private key ^^^^. ோ^and validates the credential of the verifiable presentation VP using the identity provider's public key. In this example, the service provider D-FS verifies the validity of the requested attributes and waits for proof of the credential validity to authorize the user's access to said service. Figure 1 represents a system SYS comprising a D-FI anonymous credential management device implemented by an identity provider FI, a D-FS service access control device implemented by a service provider FS and a D-USR device implemented by a user USR to request access to said service. To simplify the description, the D-FI anonymous credential management device will sometimes be called the "D-FI device of the identity provider FI". Similarly, the D-FS service access control device will sometimes be called the "D-FS service provisioning device".Similarly, the D-USR device for requesting access to a service will sometimes be called the “D-USR user device”. Similarly, instead of saying “DX device”, we can simply say “X”. In other words, the service provider FS can designate the D-FS device, the identity provider FI can designate the D-FI device for managing anonymous accreditation and the user USR can designate the D-USR device for requesting access to a service. Figure 2 represents the main steps of a method for managing at least one anonymous verifiable accreditation, the main steps of a method for requesting access to a service and the main steps of a method for controlling access to this service. In the embodiment described here, during a step not shown, the identity provider D-FI defines the public parameters pp of a BBS+ type signature system. In the embodiment described herein: pp ൌ ^e, G^, Gଶ, G^, p, n, g, g^, g^, gଶ, .., g୬, g୬ା^, h^, hଶ, .. , h୪, h, f, f^, fଶ^ where^e, G^, Gଶ, G^^ denotes a bilinear environment, for which we will assume that the q-SDH problem is difficult. p is a prime number which denotes the order of the cyclic groups G. ^ , G ଶ and G ^ n the number of attributes ^a^, … , a୬^ to be certified. In a particular embodiment, the attributes ^a^, … , a୬ି^^ are sovereign attributes and a୬ is a serial number of the anonymous VC accreditation. g, g^, g^, gଶ, .. , g୬, g୬ା^ designate n+3 generators of G^ chosen randomly (such that no one knows the discrete logarithm of one of these generators with respect to another of these generators). Each ^ g ୧ ^୬ ୧ ୀ^ is associated with a specific attribute type (e.g. g ^ will be associated with the attribute “name”, g ଶ to the “first name” attribute, g ଷ to the attribute “age”, g ସto the "gender" attribute, etc.). This will allow us to differentiate the attributes and avoid any ambiguity. f, f^, fଶ correspond to the public generators of the accumulator managed by the D-FI identity provider h^, hଶ, .. , h୪ denote l additional generators of G^ chosen randomly (so that no one knows the discrete logarithm of one of these generators with respect to another of these generators). Each ^h ୧ ^ ୪ ୧ ୀ^ will be associated with a secret attribute (additional to a ^ ) of the user. The exact number of additional secret attributes depends on the use case. h denotes a generator of G ଶ. In the following, all calculations involving exponents will be performed modulo p (modp). We will denote by params ൌ ℋ^pp^ where ℋ will denote a cryptographically secure hash function (e.g. SHA-256). Key generation: In the embodiment described here, the D-FI identity provider randomly generates an integer sk୍ belonging to {1, 2,…, p െ 1} and calculates PK୍ ൌ h^୩^. Its private key will be sk୍ andPK ୍its public key. In the embodiment described here, the identity provider FI also acts as manager of a cryptographic accumulator and generates the public parameters of this accumulator whose role will be to accumulate identifiers of revoked anonymous verifiable credentials in the case of blacklist management, or valid serial numbers if it is a whitelist. To do this, it randomly generates an integer α belonging to {1, 2,…, p} and calculates P ^ ^^ ൌ f^ as well as Pଶ ൌ fଶ . We will also assume that each user U also has a pair of private and public keys (sk ^୩^, PK^ ൌ g ^) certified by a certification authority. The user's D-USR device knows the public parameters pp of the BBS+ system and the public key PK ୍of the D-FI identity provider In the embodiment described here, the user's D-USR device comprises an M-AUTH module for authenticating the user to the D-FI device for managing at least one anonymous verifiable credential. In the embodiment described here, the D-USR device comprises a COM3 communication module. This module can be used to send a commitment ^^^^^^ relating to secret attributes of the user to the D-FI device and receive an anonymous verifiable credential ^^^^ relating to these attributes and to public attributes of the user.In the described embodiment, the D-USR device of the user USR comprises a WAL cryptographic module, for example an electronic identity wallet configured to store at least one anonymous verifiable accreditation ^^^^ issued by an identity provider FI and to generate a verifiable presentation VP to be presented to the service provider FS to access a service while protecting the confidentiality of its attributes. The WAL cryptographic module may in particular also store a witness ^^ of the belonging of the identifier ^^ of this accreditation ^^^^ to a white list of valid identifiers or a witness of the non-belonging of this identifier ^^ to a black list of invalid identifiers. The WAL cryptographic module is for example configured to obtain a proof Π. ௬ை^of non-revocation of this identifier ^^. In the embodiment described here, the communication module COM3 of the D-USR device can be used to send this proof to a D-FS service provider. In the embodiment described here, the D-USR device comprises a MUT module configured to use at least one of the certified attributes of the user to access a service of the D-FS service provider. In the embodiment described here, the D-FI anonymous accreditation management device comprises a communication module COM1. This module can in particular be used by the D-FI device to obtain the commitment on the secret attributes of the user, send him a VC accreditation, send proofs, receive a verifiable presentation. In the embodiment described here, the D-FI accreditation management device comprises a cryptographic module M-CRY1.This module can be used to authenticate a user, generate and verify the validity of an anonymous verifiable credential ^^^^ based on attributes and in the form of a blind signature using the private key ^^^^. ^, calculate proofs, verify signatures, in particular group signatures. The cryptographic module M-CRY1 can also be configured to manage a white or black list of accreditation identifiers and to calculate a witness ^^ of the belonging of the identifier ^^ of an accreditation ^^^^ to a white list of valid identifiers or a witness of the non-belonging of this identifier ^^ to a black list of invalid identifiers. In the embodiment described here, the D-FS device comprises a communication module COM2. This module can in particular be used by the device to request attributes from the user, obtain these attributes or information allowing it to obtain these attributes, obtain a verifiable presentation VP comprising an anonymous verifiable accreditation relating to attributes of a user, a proof Π ௬ை^of non-revocation of an identifier ^^ of this accreditation. In the embodiment described here, the D-FS device comprises a cryptographic module M-CRY2 configured in particular to verify the validity of the proof Π ௬ை^ , and to sign the verifiable presentation VP with a group private key. The COM2 module of the D-FS device can be used to send a request to a credential management device for verifying an anonymous verifiable credential. Figure 2 represents in the form of a flowchart the main steps of a method for managing at least one anonymous verifiable credential implemented by the identity provider FI, the main steps of a method for requesting access to a service implemented by a user USR and the main steps of an access control method implemented by a service provider FS. In this example, it is assumed that the user USR has ^^ ^ 1 secret attributes In this example, the USR user uses a D-USR device to request the D-FI device of an identity provider FI to provide him with an anonymous verifiable credential ^^^^covering the ^^ ^ 1 secret attributes and ^^ public attributes ^^^, … , ^^^. In the example described here, the ^^ public attributes include ^^ െ 1 sovereign attributes and an attribute ^^ ^ corresponding to an identifier, for example a serial number, of the verifiable anonymous accreditation ^^^^. In the embodiment described here, the FI service provider manages a cryptographic accumulator. To this end, it implements the procedures presented previously in section “4. Cryptographic accumulator”. We note ^^ ^the list of elements accumulated in this cryptographic accumulator and ^^ the current value of this accumulator During a step U4, the user USR uses his key pair ^^^^^^, ^^^^^^ to authenticate himself with the identity provider FI. In the embodiment described here, if the identity provider FI does not authenticate the user USR, the result of a test I4 is negative and the method stops. If the authentication succeeds, during a step U5, the device D-USR of the user USR calculates a pledge (or commitment) ^^^^^^^ on all of his secret values ​​and a proof ^^ ௨ that he knows how to open this commitment. In the embodiment in which the user would like the verifiable anonymous accreditation ^^^^ to only concern 1 secret attribute, we would have: ^ ൌ ^^ ^ ᇲ ^ ^^^^ బ ^ೆ ^ ^^ ^ା^In the embodiment described here, the pledge ^^^^^^ is generated with the Pedersen pledge scheme. For more information on this scheme, the person skilled in the art may refer to Torben P. Pedersen: Non-interactive and information-theoretic secure verifiable secret sharing. In Joan Feigenbaum, editor, CRYPTO'91, volume 576 of LNCS, pages 129–140. Springer, Heidelberg, August 1992. In a step U6, the user USR transmits to the identity provider FI his public key ^^^^ ௨ , the commitment ^^^^^^ and the proof ^^ ௨ . The FI service provider checks the validity of the proof ^^ ^during a step U7. In the embodiment described here, if the proof is not valid, the method for issuing a verifiable anonymous accreditation stops. During a step I8, the service provider FI determines an identifier ^^ of the anonymous verifiable accreditation ^^^^ that it will generate for the user USR. During a step I10, the service provider updates the cryptographic accumulator. This operation notably includes updating the list ^^ ^ accumulated elements or the addition of the identifier ^^ (sometimes noted ^^ ^ in the document) to the list ^^ ^if this list is a white list containing valid identifiers, or the removal of the identifier ^^ from this list if this list is a black list containing invalid identifiers. This operation also includes the updating of the value ^^ of the accumulator. An example of the implementation of these operations was presented in chapter "4. 5 Updating the accumulator". During a step I12, the service provider calculates a witness ^^ which represents: (i) the fact that the identifier ^^ of the verifiable anonymous accreditation belongs to the list ^^ ^ accumulated elements if this list is a white list. In this case, the witness ^^ can be calculated by the formula ^^ presented in section “4. 6 Calculation of a membership witness”; or (ii) the fact that the identifier ^^ of the verifiable anonymous accreditation does not belong to the list ^^ ^accumulated elements if this list is a blacklist. In this case, the witness ^^ can be calculated by the formula ^^ ൌ ^ഥ^௬,^ ൌ ^^ ൗ ^^ ିௗ ^ ାఈ^ ^^ ൗ ^^ାఈ presented in section “4.7 Calculation of a non-membership witness”. During this same step I12, the service provider calculates a proof Π ^ associated with the witness ^^. In the embodiment described here, and as previously described in sections “4. 6 Calculation of a membership witness” and “4. 7 Calculation of a non-membership witness”: (i) when the witness ^^ is a membership witness of the identifier ^^ to a white list of the form ^^ ൌ ^^௬,^ ൌ ^^ ൗ ^^^ାఈ^ , the proof Π ^ associated with this witness ^^ ௬,^ maybe : Π ఈ ^ ൌ Πఠ ఈ ^,ೇ=PoK^^^: ^^ ൌ ^^௬,^ ⋀ ^^^ ൌ ^^^^ and (ii) when the witness ^^ is a witness of non-membership of the identifier ^^ to a listening room, of the form ^^ ൌ ^ഥ^௬,^ ൌ proof Π ^associated with this witness ^ഥ^ ௬,^ can be :is Π^ ൌ Πఠഥ ^,ೇ=PoK^^^: ^^ ൌ ^ഥ^ ఈ௬,^ ⋀ ^^^ ൌ ^^^ ఈ ^. In the embodiment described here, the identity provider FI generates the anonymous verifiable credential ^^^^ during a step I14. In the embodiment described here, this anonymous verifiable credential ^^^^ relates to the commitment ^^^^^^ calculated from the ^^ ^ 1 secret attributes of the user and to ^^ public attributes ^^^, … , ^^^ comprising ^^ െ 1 sovereign attributes ^^^, … , ^^^ି^ and the identifier ^^ (or ^^^) of the anonymous verifiable credential ^^^^. In the embodiment described here, this signature is a blind signature calculated using a private key ^^^^ ^of the rights management entity FI. It is recalled that a blind signature is a security mechanism used in cryptography to allow a party to sign a message without knowing the content of this message so that the confidentiality of the message is preserved. In such a mechanism, the party wishing to obtain a blind signature combines the message to be signed with a randomly generated blinding factor and sends the result of this combination to the signer. The signer signs the message without knowing its actual content, and sends the resulting signature to the requester. The requester can use the blinding factor to "unblind" the signature, i.e. to cancel the effect of the blinding factor and obtain the signature of the original message. In the embodiment described here, this signature is calculated using the BBS+ protocol.For more information on this standard, the person skilled in the art can refer to the standard itself (https: / / identity.foundation / bbs-signature / draft-irtf-cfrg-bbs- signatures.html) or to the document “Barki, A., Brunet, S., Desmoulins, N., and J. Traore, "Improved Algebraic MACs and Practical Keyed-Verification Anonymous Credentials", In International Conference on Selected Areas in Cryptography, 1016,<https: / / link.springer.com / chapter / 10.1007 / 978-3-319-69453-5_20> . In the embodiment described herein, the anonymous verifiable credential ^^^^ is a pair ^^^, ^^^ computed according to the BBS+ protocol defined by public parameters ^^^^ with ^^^^ ൌ^^^, ^^^, ^^ଶ, ^^், ^^, ^^, ^^, ^^^, ^^^, ^^ଶ, .. , ^^^, ^^^ା^, ℎ^, ℎଶ, .. , ℎ^, ℎ, ^^, ^^^, ^^ଶ^ where :- ^^^, ^^^, ^^ଶ, ^^்^ denotes a bilinear environment for which the q-SDH problem is hard ;= - p is a prime integer that denotes the order of the cyclic groups ^^. ^ , ^^ ଶ and ^^ ்- ^^, ^^^, ^^^, ^^ଶ, .. , ^^^, ^^^ା^ designate n+3 randomly chosen ^^^ generators, each ^^^ ^ ^ ^ ^ ୀ^ being associated with a specific attribute type;- ^^, ^^^, ^^ଶ are the public generators of said accumulator;- ℎ denotes a generator of ^^ ଶ , and in which: ^^ ᇱᇱ ^, ^^^ ᇱᇱ , ^^ ଶ ᇱᇱ ,…, ^^ ᇱᇱ ^ , ^^ ∈ ^^∗^ are random values ​​chosen by said rights management entity. In the embodiment in which the user would like the verifiable anonymous accreditation ^^^^ to only concern 1 secret attribute, we would have:^^ ൌ ^^^^^^^^^^^^ ^ ᇲ బᇲ ^ ∏^ ^ ^ ^ / ^^^ ^ୀ^ ^^ ^ା^^ ^ ^, where ^^^ ൌ ^^′^ ^ ^^′′^ and ^^′^ represents the value committed in Com. In the embodiment described here, during a step I16, the identity provider FI calculates a proof ^^ ௩^^^ௗof the validity of the anonymous verifiable accreditation ^^^^. The person skilled in the art understands that ^^ ൌ ^^^^^^^^^^^ ^ implies that: that By noting ^^^ ൌ ^^^^^ ൌ ^^^^ି^ the identity provider can compute a knowledge-disclosure proof ^^௩^^^ௗ, for example Schnorr Π ௩^^^ௗ demonstrating that ^^ has indeed been calculated correctly, in other words that the discrete logarithm of ^^^ in the base ^^ is equal to the discrete logarithm of ^^^^ ூ in the ℎ base. For more information on Schnorr proofs, the person skilled in the art can refer to the document Claus-Peter Schnorr: Efficient Identification and Signatures for Smart Cards. CRYPTO 1989: 239-252. During a step I18, the identity provider FI sends to the user: (i) the anonymous verifiable accreditation ^^^^; (ii) the proof ^^ ௩^^^ௗof the validity of this accreditation; (iii) the identifier ^^ of this anonymous verifiable accreditation ^^^^; (iv) the witness ^^ of membership or non-membership of this identifier to a list and the proof Π ^ associated with this witness. In the embodiment described here, the identity provider also sends, in the same message, the random values ​​^^ᇱᇱ ᇱᇱ ᇱᇱ ᇱᇱ^, ^^^, ^^ଶ,…, ^^^ . These elements are received by the user USR during the same step. During a step U20, the user's D-USR device:- calculates ^^ ൌ ᇱ ᇱᇱ ᇱ ᇱᇱ^ ^^^ ^ ^^^ ^mod ^^^ and ^^^ ൌ ^^^ ^ ^^^ ^mod ^^^ and- unblinds the anonymous verifiable credential ^^^^ and obtains an anonymous verifiable credential also noted ^^^^ for simplicity. During a step U22, it checks the validity of the signature ^^^, ^^^ by verifying the proof^^ ௩^^^ௗ and the proof Π ^ associated with the witness of belonging (proof Π ఠ^,ೇ) or to the witness of non-membership (proof This unblinded signature of the message consisting of the commitment ^^^^^^ on the secret attributes (^^′ ^^′^, … , public attributes ^^^^, … , ^^^ି^^ of this user and the identifier ^^=^^ ^of the anonymous verifiable accreditation ^^^^ can be verified either via a ZKP generated by the identity provider FI or more directly using its public key. In the mode described here, it is stored in the WAL wallet. We will now describe the main steps implemented by the different stakeholders (user, service provider, identity provider) when the user USR wishes to access a service offered by the service provider FS. During a step U22, the user USR connects anonymously to the service provider FS. In the exemplary embodiment described here, we will assume that the service provider FS requests, during a step S24, attributes from the user USR (called attributes of interest) that it wishes to verify before allowing the user USR to access its service.In a preferred embodiment, this request is authenticated, in other words signed by the service provider FS. We will designate by ^^, the list of indices of the attributes of interest ^^^. ^ ^ ^∈^^ requested by the service provider FS and in this example ^^ ൌ ^1, 2^. During a step U26, the user USR selects from the anonymous verifiable credentials ^^^^ received from the identity provider FI, one or more anonymous verifiable credentials of interest ^^^^ ூ carrying the attributes of interest of the FS service provider. For the sake of simplification, we consider that a single accreditation ^^^^ ூ relates to the set of attributes of interest. In the embodiment described here, the user USR generates a verifiable presentation VP (in English "verifiable presentation") from this accreditation of interest ^^^^ ூ. In the embodiment described here, the user USR calculates a pledge ^^ on all of its certified public attributes ^^^, … , ^^^. For the sake of simplification, we will assume that it actually calculates ^^ pledges, one pledge per public attribute: ^^ ൌ^^^^, ^^ଶ, … , denotes a pledge on the attribute ^^^. In the embodiment described here, the service provider FS will ask the identity provider FI to provide proof that it has indeed certified the user's attributes. The identity provider FI should therefore verify, with its private key ^^^^ ூ , the accreditation of interest ^^^^ ூproduced in step I14. In the embodiment described here, it is not desired that the identity provider FI be able to make the connection with the user USR who communicated his secret attributes to him (step U6) for the calculation of this accreditation, the user USR calculates a refreshed anonymous verifiable accreditation ^^^^′ ூ from the accreditation of interest ^^^^ ூ . This new refreshed verifiable accreditation ^^^^′ ூ always relates to the secret attributes ^^^′^,^^′^, … , ^^′^^, the public attributes ^^^^, … , ^^^ି^^ of this user and to the identifier^^ of the accreditation of interest ^^^^ ூ but it cannot be compared, in particular by the identity provider FI, with the accreditation ^^^^ produced by the identity provider FI in step I14. In the embodiment described here, the user USR generates a proof ^^ ^with zero disclosure of knowledge demonstrating that he knows how to reveal the ^^ pledges ^^ ^ and that the anonymous verifiable credential ^^^^is valid on the set of pledged values ​​^^^, ^^^, ^^ଶ, … , ^^^. During a step U28, the user USR generates a verifiable presentation VP including the refreshed verifiable credential ^^^^′ ூ . In the described embodiment, the verifiable presentation VP comprises the public key ^^^^ ூ from the FI identity provider, the verifiable accreditation ^^^^′ ூ , the pledges ^^ ^ and the proof ^^ ^ zero-knowledge disclosure:^^^^ ൌ ^^^^^ ூ ^ூ, ^^^^′ ,^ ^^^^^ୀ^ , ^^^).As mentioned earlier, in the embodiment described herein, the service provider FS needs to check the public attributes of interest ^^ ^ ^^^^ ^^ ଶ ^ ^ ^^ ^ ^ ^∈^^^ requested and the user must therefore provide information to obtain them. In the embodiment described here, this information includes the data necessary to reveal the pledges ^^^, only for ^^ ∈ ^^. This data is hereinafter called opening data and noted ^^^^^^^^^^^ ^ ^ ^∈^^ . When using a pledging scheme based on a hash function ℋ, the pledge can be of the type ^^^ ൌ ^^^^ where ^^^ is a random number. In this example ^^^ and ^^^constitute the opening data ^^^^^^^^^^^^ ^ ^ ^∈^^ . During a step U30, the user calculates a proof Π ௬ை^ of non-revocation of the identifier ^^ of the anonymous verifiable accreditation of interest ^^^^ ூ . In the embodiment described here, this proof is constituted by: - ​​a proof ^^ ^^ that the identifier ^^ belongs to the white list of valid identifiers or by - a proof ^^ ^^that this identifier ^^ does not belong to the blacklist of invalid identifiers. Example of generating the proof ^^ ^^ This proof allows the USR user to prove that the identifier ^^ is valid. We recall that in the case of a white list, the witness of membership in the list of valid identifiers is of the type ^^ ൌ ^^௬,^ ൌ and we note (^^, ^^ ^) the current state of the accumulator. In the embodiment described here, the user first calculates a refresh of his membership indicator C. To do this, he chooses l ∈ Z∗ ୪୮ and calculates C . Let A ൌ C୪. We have Cୟ^ା^= V and therefore C^= VCିୟ^. This implies that C୪^= V୪Cି୪ୟ^. Let A^=C୪^ ൌ A^ and A^ =Aି^. We therefore have A^ ൌ V୪A^ୟ^. User USR then generates a zero-knowledge proof: πୖ^^ = PoΚ^l, a୬: A^ ൌ V୪A^ୟ^^. In this particular embodiment, user USR also proves in his verifiable presentation ^^^^ that the identifier ^^ ൌ ^^^ used for the non-revocation proof is indeed the same as the one normally present in his anonymous accreditation ^^^^. For example, user USR generates a ZK proof ^^ாொ that the identifier ^^ ൌ ^^^ in the representation of  in bases V and ^ ^ ^ is the same as the pledge ^^ ^. For this ZK proof, the skilled person may refer to the document David Chaum, Torben P. Pedersen: Wallet Databases with Observers. CRYPTO 1992: 89-105. We will implicitly assume that this proof ^^ ாொ is integrated into the proof ^^ ^ described above. In the embodiment described here, the proof π ^^ final consists of the following data: π^^ ൌ ^A, A^, πୖ^^^.Example of proof generation ^^ ^^ This proof allows the USR user to prove that the identifier ^^ of his verifiable anonymous accreditation is not revoked. We recall that in the case of a black list, the witness of non-membership in the list of invalid identifiers is of the type note (V, ^^ ^) the current state of the accumulator. In the embodiment described here, the user first calculates a refresh of his non-membership indicator C. To do this, he chooses l ∈ Z∗ ୪୮ and calculates C .0 and therefore C^= Vf ି^Cିୟ^. This implies that Let A^= C୪^ ൌ A^ and A^ =Aି^et dᇱ ൌ െld. We therefore have A^ ൌ V୪f ^ᇱA^ୟ^. User USR then generates a zero-knowledge proof: In this particular embodiment, the user USR also proves in his verifiable presentation ^^^^ that the identifier ^^ ൌ ^^^ used for the non-revocation proof is indeed the same as the one normally present in his anonymous accreditation ^^^^. For example, the user USR generates a ZK proof ^^ாொ that the identifier ^^ ൌ ^^^ in the representation of  in the bases V and ^ ^ ^ is the same as the pledge ^^ ^. For this ZK proof, the skilled person may refer to the document David Chaum, Torben P. Pedersen: Wallet Databases with Observers. CRYPTO 1992: 89-105. We will implicitly assume that this proof ^^ ாொ is integrated into the proof ^^ ^ described above. In the embodiment described here, the proof π ^^ final consists of the following data: π^^ ൌ ^A, A^, π^^^^. During a step U32, the user sends to the service provider FS: (i) the verifiable presentation VP including the refreshed anonymous verifiable accreditation ^^^^ ᇱூ obtained from anonymous verifiable accreditation of interest ^^^^ ூ ; (ii) the proof Π ௬ை^ of non-revocation of the identifier ^^ of the anonymous verifiable accreditation of interest ^^^^ ூ constituted by the proof ^^ ^^ that the identifier ^^ belongs to the white list of valid identifiers or by the proof ^^ ^^that this identifier does not belong to the blacklist of invalid (revoked) identifiers. In the embodiment described here, the user also sends the opening data ^^^^^^^^^^^^ ^ ^ ^∈^^ to the service provider FS. During a step S34, the service provider FS checks that the opening data ^^^^^^^^^^^^ ^ ^ ^∈^^ actually allow to reveal the attributes of interest ^^ ^ ^^^^ ^^ ଶ of the user and that these attributes comply with the conditions of access to his service. If this is not the case, in the embodiment described here, the service provider FS refuses access to the service during a step S40. In the embodiment described here, if the attributes ^^ ^ ^^^^ ^^ ଶ of the user comply with the conditions of access to its service, the service provider verifies, during a step, the validity of the proof zero-knowledge disclosure. This step may not be performed, especially if the identity provider FI is configured to perform this verification. It nevertheless allows the service provider to verify that the verifiable presentation VP was indeed issued by the user USR, and that the latter has not reused a verifiable presentation from a third party that he could have fraudulently copied. In the embodiment described here, if the service provider FS determines that the proof ^^ ^ is invalid, it refuses access to the service. During a step S36, the service provider verifies the proof Π ^^^ of non-revocation, that is to say the validity of ^^ ^^ or ^^ ^^ . To check the validity of ^^ ^^ , the service provider will have to ensure on the one hand that the following equality is satisfied ^^^^^, ^^ଶ^ ൌ ^^^^^^, ^^ଶ^ and on the other hand that ^^ோா^ is valid. To check the validity of ^^ ^^, the service provider will have to ensure on the one hand that the following equality is satisfied ^^^^^, ^^ଶ^ ൌ ^^^^^^, ^^ଶ^ and on the other hand that ^^ோொ is valid. The proof verification algorithm ^^ ோா^ and ^^ ோொ being relatively conventional for those skilled in the art, they will not be described here. In the embodiment described here, before allowing access to the service to the user USR, the service provider FS must ensure that the attributes of interest ^^ ^ ^^^^ ^^ ଶ of the user have been certified. In the embodiment described here, the service provider FS verifies the validity of these attributes using the public key of the identity provider FI. In the embodiment described here, the service provider FS offers its service to the user, only if: - the user's attributes of interest; - the proof Π ை^ of the validity of the accreditation ^^^^ ூ ; - the proof Π ௬ை^of the non-revocation of the identifier of this accreditation have been obtained. Each of the D-USR, D-FI and D-FS devices described above can be implemented by an ORD computer whose hardware architecture is shown in Figure 3. This ORD computer comprises in particular a processor 10, a random access memory 11, a read-only memory 12 and communication means 13. The read-only memory 12 constitutes a recording medium within the meaning of the disclosure. It comprises a PG-X computer program in accordance with the disclosure. For the D-USR device, this PG-X computer program is a PG-USR program comprising instructions for executing the steps of a method for requesting access to a service as described above with reference to Figure 2. The PG-USR program defines in particular the M-AUTH authentication module, the WAL cryptographic module and the COM-3 communication module of the D-USR device.For the D-FI device, this computer program PG-X is a PG-FI program comprising instructions for executing the steps of a method for managing at least one anonymous verifiable accreditation as described previously with reference to Figure 2. The PG-FI program defines in particular the module M-CRY1 for authentication and generation of an anonymous verifiable accreditation, and the module COM1 of the D-FI device. For the D-FS device, this computer program PG-X is a PG-FS program comprising instructions for executing the steps of a method for controlling access to a service as described previously with reference to Figure 2. The PG-FS program defines in particular the cryptographic module M-CRY2 and the communication module COM2 of the D-FS device. Another example of implementing the disclosure In the first example detailed above, the certified public attributes of the user are used to access a service.The present disclosure is not limited to this embodiment of the disclosure. For example, the accreditation management device can generate an accreditation ^^^^ comprising: - an attribute necessary to exercise a right (access code for an access right, bank card number for a payment right, etc.); and - an identifier of this accreditation ^^^^. The accreditation management device can manage a white list of valid accreditation identifiers or a black list of revoked (invalid) accreditation identifiers and calculate a witness of belonging or not belonging to such a list of an accreditation identifier.The accreditation management device can thus provide a user with an accreditation relating in particular to an attribute necessary for the exercise of a right and the witness of belonging or non-belonging of the identifier of this accreditation to a white list of valid identifiers or black list of revoked identifiers. The user's device can be configured to obtain proof of non-revocation of this identifier and to provide this proof, in addition to the accreditation relating to the attribute necessary for the exercise of the right to an entity with which the user wishes to exercise his right (merchant for a payment with the bank card number, access portal for an access right with the access code, etc.).

Claims

CLAIMS

1. Method for managing at least one anonymous verifiable accreditation ^ ^^^^ ^ , the method being implemented by an accreditation management device (D-FI) and comprising the following steps: - generation (I14) of an anonymous verifiable accreditation ^ ^^^^ ^ relating to a plurality of attributes, one of which is an identifier ^^^^ of this accreditation ^ ^^^^ ^ ; - update (I10) of a list ൫^^ ^^ ൯ of accreditation identifiers accumulated in a cryptographic accumulator by adding or removing said identifier (^^) and the value ^^^^ from the accumulator, said list ൫^^ ^^ ൯ being: (i) either a white list comprising valid identifiers; (ii) or a black list comprising invalid identifiers; - calculation (I12) of a witness ^^^^ representative of: (i) the membership of said identifier ^ ^^ ^to a whitelist; or (ii) non-membership of said identifier ^ ^^ ^ to a blacklist and (iii) proof ^ Π^ ^ associated with said witness ^ ^^ ^ ; - sending (I18) to a user: (i) of said anonymous verifiable accreditation ^ ^^^^ ^ ; (ii) proof ^ ^^௩^^^ௗ ^ of the validity of said anonymous verifiable accreditation ^ ^^^^ ^ ; (iii) said identifier ^ ^^ ^ of said anonymous verifiable accreditation ^ ^^^^ ^ ; (iv) the said witness ^ ^^ ^ and proof ^ Π^ ^ associated with said witness.

2. Method for managing at least one anonymous verifiable accreditation ^ ^^^^ ^, according to claim 1 wherein one of said attributes ^ ^^^^^^ ^ is a commitment relating to a secret attribute the user.

3. Method for managing at least one anonymous verifiable accreditation according to claim 1 or 2 wherein: (i) when said list ൫^^ ^^ ൯ is a white list: - the value ^^ of the accumulator after update is calculated by ^^ ൌ ^^ᇱ௬ାఈ ; - the witness ^^^^ of belonging of said identifier ^^^ ൌ ^^^^ to said white list is calculated by - the proof Π associated with this witness ^^௬,^ is Π^ ൌ And (ii) when the said list ൫^^ ^^ ൯ is a blacklist: భ- the value ^^ of the accumulator after update is calculated by ^^ ൌ ^^ᇱ ^శ^ ; - the witness ^^^^ of non-membership of said identifier ^ ^^ ^ to the said blacklist is calculated by- the evidence Π^ associated with this witness ^ഥ^ ఈ௬,^ is Π^ ൌ Πఠഥ ఈ^,ೇ=PoK^^^: ^^ ൌ ^ഥ^௬,^ ⋀ ^^^ ൌ ^^^^ where :- ^^, ^^^, ^^ଶ are public generators of said accumulator ;- ^^ is an integer belonging to {1, 2,…, p-1}, the private key ^^^^ of the credential management device (D-FI) for managing the accumulator is equal to ^^- ^^ ൌ ^^ఈ, ^^ ൌ ఈ ^ ^ ଶ ^^ଶ - the public key ^^^^ for accumulator management is ^^^^ = (^^ ^ , ^^ ଶ ) - ^^=^^^^ ି௬ =^^ ఈ - ^^ ᇱ is the value of the accumulator before said update ;- ^^ ൌ ^^ ^െ^^^ where ^^^ is a polynomial defined by ^^^^ ^^^ ^ ^^^ , ^^ being a list of secret values ​​used to initialize the accumulator - ^^ is an initial value of the accumulator: ^^^ ൌ

4. Method implemented by a user device (D-USR), this method comprising the following steps: - reception (I18), from an accreditation management device (D-FI): (i) of at least one anonymous verifiable accreditation ^ ^^^^ ^ relating to a plurality of attributes, one of which is an identifier ^^^^ of this accreditation ^ ^^^^ ^ ; (ii) proof ^ ^^௩^^^ௗ ^ of the validity of said anonymous verifiable accreditation ^ ^^^^ ^ ; (iii) the identifier ^ ^^ ^ of said anonymous verifiable accreditation ^ ^^^^ ^ ;(iv) a witness of ^^^^ the membership of said identifier ^^^^ in a white list of valid identifiers or of the non-membership of said identifier ^^^^ in a black list of invalid identifiers, said white or black list being a list ൫^^ ^^ ൯ of elements accumulated in a cryptographic accumulator; (v) of a proof ^ Π^ ^ associated with said witness ^ ^^ ^ ; - obtaining (U30) proof of non-revocation of the identifier ^^^^ of anonymous verifiable accreditation of interest ^^^^^ ூ ^ consisting of: (i) proof that the said identifier ^ ^^ ^ of said verifiable accreditation d’intérêt ^ ^^^^ ூ^ belongs to the said white list or by (ii) a proof ^^^ ^^ ^ that said identifier ^ ^^ ^of said anonymous verifiable accreditation of interest does not belong to said blacklist; - use of at least one of said attributes to exercise a user right (USR) at least under the condition of obtaining proof ^Π ை^ ^ of the validity of said accreditation ^ ^^^^ ூ^ and the non-revocation of said identifier ^^^^.

5. Method according to claim 4 for requesting access to a service in which said at least one anonymous verifiable accreditation ^ ^^^^ ^ relates to a plurality of attributes (^^^, …, ^^^^ of the user (USR), said method further comprising the following steps; - selection (U26) from said at least one anonymous verifiable accreditation ^ ^^^^ ^ of an anonymous verifiable accreditation of interest ^ ^^^^ ூ^relating to at least one attribute of interest for a provider of said service; - sending (U32), to said service provider (FS): (i) a verifiable presentation (VP) comprising at least one refreshed accreditation obtained from said anonymous verifiable accreditation of interest ^ ^^^^ ூ^ enabling the service provider to obtain said at least one attribute of interest; (ii) said proof of non-revocation of the identifier ^^^^ of said anonymous verifiable accreditation of interest ^ ^^^^ ூ^ .

6. Method for requesting access to a service according to claim 5 wherein: (i) the proof that said identifier ^^^^ of said anonymous verifiable accreditation of interest ^^^^^ூ^ belongs to said white list is of the type ^^^^ ൌ ^^^, ^^^, ^^ோா^^, with: ^^ = PoΚ^^^, ^^ : ^^^ ൌ ^ ^௬ோா^ ^ ^^ ^^ ^(ii) the proof ^ ^^^^ ^that the said identifier ^ ^^ ^ of said anonymous verifiable accreditation of interest ^^^^^ூ^ does not belong to said blacklist is of the type ^^^^ ൌ ^^^, ^^^, ^^ோொ^, with: where :- ^^, ^^^, ^^ଶ are public generators of said accumulator ;- ^^ is an integer belonging to {1, 2,…, p-1}, the private key ^^^^ of the device (D-FI) for managing accreditations for the management of the accumulator being equal to ^^- ^^ ൌ ^^ఈ ఈ^ ^ , ^^ଶ ൌ ^^ଶ- the public key ^^^^ for the management of the accumulator is ^^^^ = (^^ ^ , ^^ ଶ ) - ^^=^^^^ ି௬ =^^ ఈ - ^^ ᇱ is the value of the accumulator before said update ;- ^^ ൌ ^^^^െ^^^ where ^^^ is a polynomial defined by ^^^ ^ ^^^ , ^^^బ being a list of secret values ​​used to initialize the accumulator- ^^^ is an initial value of the accumulator: ^^^ ൌ

7. Method for controlling access to a service by a user (USR), said method being implemented by a service provider (D-FS) and comprising the following steps: - obtaining (U32) a verifiable presentation (VP) comprising an anonymous verifiable accreditation of interest ^ ^^^^ ூ^ relating to attributes of interest of the user and proof of non-revocation of an identifier ^^^^ of said anonymous verifiable accreditation d’intérêt ^ ^^^^ ூ^ ; - verification (S34) of said at least one attribute of interest; - verification (S36) of the validity of said proof of non-revocation; - sending (S38) to an accreditation management device (D-FI) a request for verification of said anonymous verifiable accreditation of interest ^ ^^^^ ூ^included in said verifiable presentation (VP), - a positive result of a verification (S40) of said at least one attribute and obtaining proof ^Π ை^ ^ of the validity of said accreditation ^ ^^^^ ூ^ and the non-revocation of said identifier being necessary conditions for authorizing (S58) the access of the user (USR) to said service.

8. Method according to any one of claims 1 to 7 in which said anonymous verifiable accreditation ^^^^^^ is a blind signature calculated using a private key ^^^^ ^of said accreditation management device (D-FI).

9. Method according to claim 8 wherein said anonymous verifiable accreditation ^^^^^^ is a pair ^^^, ^^^ calculated according to the BBS+ protocol defined by public parameters ^^^^ with ^^^^ ൌ^^^, ^^^, ^^ଶ, ^^், ^^, ^^, ^^, ^^^, ^^^, ^^ଶ, .. , ^^^, ^^^ା^, ℎ^, ℎଶ, .. , ℎ^, ℎ, ^^, ^^^, ^^ଶ^ where:- ^^^, ^^^, ^^ଶ, ^^்^ denotes a bilinear environment for which the problem q SDH is difficult; - p is a prime integer which denotes the order of cyclic groups ^^ ^ , ^^ ଶ and ^^ ் - ^^, ^^^, ^^^, ^^ଶ, .. , ^^^, ^^^ା^ designate n+3 randomly chosen ^^^ generators, each^^^ ^ ^ ^ ^ ୀ^ being associated with a specific attribute type;- ^^, ^^^, ^^ଶ are the public generators of said accumulator;- ℎ denotes a generator of ^^ ଶ , and in which: ^^ ᇱᇱ ^, ^^^ ᇱᇱ , ^^ ଶ ᇱᇱ,…, ^^ ᇱᇱ ^ , ^^ ∈ ^^∗^ are random values ​​chosen by said accreditation management device (D-FI).

10. Accreditation management device (D-FI) comprising: - a module (M-CRY1) for generating (I14) an anonymous verifiable accreditation ^^^^^^ relating to a plurality of attributes, one of which is an identifier ^^^^ of this accreditation ^^^^^^; - a module (M-CRY1) for updating (I10) a list ൫^^ ^^ ൯ of accreditation identifiers accumulated in a cryptographic accumulator by adding or removing said identifier and la valeur ^ ^^ ^ of the accumulator, said list being: (i) either a white list comprising valid identifiers; (ii) or a black list comprising invalid identifiers; - a module (M-CRY1) for calculating (I12) a witness ^ ^^ ^ representative of: (i) the membership of said identifier ^ ^^ ^to a whitelist; or (ii) non-membership of said identifier ^ ^^ ^ to a blacklist and (iii) proof ^ Π^ ^ associated with said witness ^ ^^ ^ ; - a module (COM1) for sending (I18) to a user: (i) said anonymous verifiable accreditation ^ ^^^^ ^ ; (ii) proof ^ ^^௩^^^ௗ ^ of the validity of said anonymous verifiable accreditation ^ ^^^^ ^ ; (iii) said identifier ^^^^ of said anonymous verifiable accreditation ^^^^^^; (iv) said witness ^^^^ and evidence ^Π ^ ^ associated with said witness.

11. Device (D-USR) comprising: - a module (COM3) for receiving (I18), from an accreditation management device (D-FI): (i) at least one anonymous verifiable accreditation ^^^^^^ relating to a plurality of attributes, one of which is an identifier ^^^^ of this accreditation ^^^^^^; (ii) proof ^ ^^௩^^^ௗ ^ of the validity of said anonymous verifiable accreditation ^ ^^^^ ^ ; (iii) the identifier ^ ^^ ^ of said anonymous verifiable accreditation ^ ^^^^ ^ ; (iv) a witness of ^ ^^ ^ the belonging of said identifier ^ ^^ ^ to a white list of valid identifiers or non-membership of said identifier ^ ^^ ^ to a blacklist of invalid identifiers, said whitelist or blacklist being a list ൫^^ ^^൯ of elements accumulated in a cryptographic accumulator; (v) of a proof ^Π ^ ^ associated with said witness ^^^^; - a module (WAL) for obtaining (U30) proof non-revocation of the identifier ^ ^^ ^ of said anonymous verifiable accreditation of interest ^ ^^^^ ூ^ consisting of: (i) a proof ^^^ ^^ ^ that said identifier ^^^^ of said anonymous verifiable accreditation of interest ^^^^^ ூ ^ belongs to said white list or by (ii) proof ^^^ ^^ ^ that said identifier ^^^^ of said anonymous verifiable accreditation of interest does not belong to said blacklist; - a module (MUT) for using at least one of said attributes to exercise a user right (USR) at least under the condition of obtaining proof ^Π ை^ ^ of the validity of said accreditation ^^^^^ ூ^ and the non-revocation of said identifier ^^^^.

12. Device (D-FS) for controlling access to a service by a user (USR), said device comprising: - a module (COM2) for obtaining a verifiable presentation (VP) comprising an anonymous verifiable accreditation of interest ^^^^^ ூ ^ based on user interest attributes and evidence non-revocation of an identifier ^ ^^ ^ of said anonymous verifiable accreditation of interest ^ ^^^^ ூ^ ; - a module (M-CRY2) for verifying (S34) said at least one attribute of interest; - a module (M-CRY2) for verifying (S36) the validity of said proof of non-revocation; - a module (COM2) for sending (S38) to an accreditation management device (D-FI) a request for verification of said anonymous verifiable accreditation of interest ^ ^^^^ ூ^included in said verifiable presentation (VP), - a positive result of a verification (S40) of said at least one attribute and obtaining a proof ^Π ை^ ^ of the validity of said accreditation ^ ^^^^ ூ^ and the non-revocation of said identifier being necessary conditions for authorizing (S58) the access of the user (USR) to said service.

13. Computer program (PG-USR, PG-FS, PG-FI) comprising instructions which, when the program is executed by a computer, cause the latter to implement a method according to any one of claims 1 to 9.

14. Recording medium readable by a computer on which is recorded a computer program (PG-USR, PG-FS, PG-FI) according to claim 13.

Images