Methods and devices for managing the revocation of cryptographic accreditations

Abstract

An accreditation management device (D-FI) generates an anonymous verifiable accreditation relating to attributes of a user (D-USR), including an identifier 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 representing the membership of the identifier of an accreditation to this list and a proof associated with this witness. The user can calculate a proof of non-revocation of the identifier of his anonymous verifiable accreditation and use his certified attributes to exercise a right, for example to access a service subject to the verification of this proof and the validity of the accreditation. Fig. 1

Description

Title of the invention: Methods and devices for managing the revocation of cryptographic accreditations Prior art

[0001] The invention lies in the field of digital identity management. More specifically, the invention relates to a digital identity management method which preserves the privacy of users.

[0002] For example, many service providers, whether online or in a face-to-face relationship with the user, require the provision of user identity elements, more generally in order to deliver their service.

[0003] Traditionally, in a non-digital world, this provision of identity elements is carried out using (physical) documents 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.).

[0004] In particular, a mechanism is known in which an authority issues cryptographic accreditations to certify attributes of its users, a service provider being able to obtain proof of the validity of such an accreditation before granting access to its service.

[0005] 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.

[0006] 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, which 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 following the expiration of their validity date, upon 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 the system management). Often, in this type of architecture, the system stores the valid tokens it has issued in its database, with 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 of all revoked tokens, or a whitelist of all valid tokens, both lists being populated by the central system. Finally, in systems where the user's equipment is controlled by the central system, the token deletion may be performed on the user's equipment by the central system.

[0007] The proofs of non-revocation of tokens of the current state of the art either do not offer any anonymity to the user, or a computational anonymity which could be lifted by attackers having powerful quantum computers, or are too costly to be generated by devices (such as smart cards) having limited computing power or even involve operations not supported by these devices (bilinear couplings for example).

[0008] 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 (proofs of non-revocation of tokens 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. Subject matter and summary of the invention

[0009] 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 (v) and the value (V) from the accumulator, said list being: (i) either a whitelist containing valid identifiers; (ii) blacklist containing invalid identifiers; - calculation of a representative witness of: (i) the membership of said identifier in a whitelist; or (ii) the non-membership of said identifier on a blacklist and (iii) evidence associated with said witness; - sending 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; and (iv) the said witness and the evidence associated with the said witness.

[0010] 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 whitelist containing valid identifiers; (ii) a blacklist containing invalid identifiers; - a calculation module for a representative witness of: (i) the membership of said identifier in a whitelist; or (ii) the non-membership of said identifier on a blacklist and (iii) evidence associated with said witness; - a module for sending 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 the evidence associated with the said witness.

[0011] 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.

[0012] These attributes can be public attributes, for example regal (name, first name, date of birth, address, etc.).

[0013] 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.

[0014] 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.

[0015] Very advantageously, the present disclosure proposes to manage the list of valid or revoked accreditation identifiers by cryptographic accumulators.

[0016] 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.

[0017] In an embodiment of the present disclosure, to generate the compressed list of revoked (respectively non-revoked) identifiers, the dynamic universal accumulator proposed by reference [1] is used with the adaptations presented below so that it can be supported by constrained devices such as secure elements (SE in English) which do not implement certain mathematical operations such as the couplings conventionally used by this type of accumulator).

[0018] [1]: Giuseppe Vitto, Alex Biryukov: Dynamic Universal Accumulator with Batch Update on Bilinear Groups. CT-RSA 2022: 395-426.

[0019] In a particular embodiment: (i) the value V of the accumulator after adding a value 3' (or ^«) to a black or white list is calculated by y _ y'y+a; - the witness of belonging of said identifier to said white list is calculated by i / , Z'* __ z , __ 17 / , C = Wyy ' - the proof Hc associated with this witness is nc = EU, (,=PoK [a:B = ayv“A^ = / î] - the value V of the accumulator after removing a value 3' (or a») from a black list is white is calculated by _ y; - the witness of non-membership of said identifier (y) to said black list is calculated by C=^vV = V / ( ) y' , - the proof Hc associated with this witness &yN is nc — EI^ v=PoK Or : - .A / p A are public generators of said accumulator; - a is an integer belonging to {1, 2,..., p-1}, the private key sk of the accreditation management device for the management of the accumulator is equal to a - the public key Pk for managing the accumulator is Pk = (P,, P^) - B=yc y=Ca - y' is the value of the accumulator before said update; - d = Pv ( -y ) where Pv is a polynomial defined by Py( %) = JJ u <y ( y + x ), yy étant une liste de valeurs secrètes utilisée pour initialiser l’accumulateur et yy l'ensemble des éléments accumulés dans l’accumulateur V à l'exclusion des éléments d'initialisation - Vo is an initial value of the accumulator: 6 + a)

[0020] In a particular embodiment of the present disclosure, the anonymous verifiable accreditation is a blind signature calculated using a private key sk{ of said accreditation management device.

[0021] 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.

[0022] In the present disclosure, an anonymous credentialing mechanism as introduced by Chaum (David Chaum: Showing Credentials Without Identification: Signatures Transferred Between Unconditionally Unlinkable Pseudonyms. EUROCRYPT 1985: 241-244) may be used. Such a system allows a user to prove that his attributes (name, first name, date of birth, address, gender, etc.) have been certified, without revealing superfluous information.

[0023] 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.

[0024] 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 both for its generation and for its verification. This primitive therefore differs from the digital signature which can be verified by everyone, using a public key.

[0025] In a particular embodiment, the present disclosure uses more specifically the anonymous accreditation 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 accreditation manager to generate anonymous accreditations that any service provider can verify using the manager's public key.

[0026] This scheme is particularly advantageous in the context of the present disclosure, because the successive use of the same accreditation cannot be detected, which avoids any risk of tracing. It also makes it possible to certify certain attributes without revealing them, which signature scheme allowing to sign pledged messages and on the other hand to efficiently prove knowledge of a signature without revealing it.

[0027] In a particular embodiment, the management method further comprises calculating proof of the validity of the verifiable accreditation and sending said proof to the user.

[0028] This proof allows the user to be convinced of the validity of the accreditation.

[0029] In a particular embodiment, the proof is a proof with a designated verifier, so that only the user can be convinced of the validity of the accreditation.

[0030] The zero-knowledge proof mechanism is a mechanism known to those skilled in the art of cryptography and is recalled below.

[0031] In a particular embodiment of the present disclosure, said anonymous verifiable accreditation is a pair (A, r) calculated according to the BBS+ protocol defined by public parameters PP with PP = (g G{, G2, Gt, p,n, g, g& gr-, gn, gn+]J^ f,frf^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 G^ G2 and GT - g- gff gp g2' £„+1 denote n+3 generators of G^ chosen randomly, each f 1 ” being associated with a specific attribute type; ] O ; | 1 ' ' è=l - G f ? Jg are the public generators of said accumulator; - h denotes a generator of G2, and in which: / [ \ Or (Iq, yp aÇ..., 5'', f Zp are random values ​​chosen by the said accreditation management device.

[0032] According to a second aspect, the disclosure relates to a method implemented by a device of a user, this method comprising the following steps: - reception, 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 that accreditation; (ii) proof of the validity of said anonymous verifiable accreditation; (iii) the identifier of said anonymous verifiable accreditation; (iv) a witness to the membership of said identifier in a white list of valid identifiers or to 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 an ac- cryptographic accumulator; (v) evidence 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 whitelist or by (ii) 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 at least on condition of obtaining proof of the validity of said accreditation and the non-revocation of said identifier.

[0033] Correlatively, the disclosure relates to a device comprising: - a reception 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 that accreditation; (ii) proof of the validity of said anonymous verifiable accreditation; (iii) the identifier of said anonymous verifiable accreditation; (iv) a witness to the membership of said identifier in a white list of valid identifiers or 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) evidence associated with said witness; - a module for 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 whitelist or by (ii) proof that said identifier of said anonymous verifiable accreditation of interest does not belong to said blacklist; - 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 the non-revocation of said identifier.

[0034] 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; - selection of 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, audit service provider: (i) a verifiable presentation comprising at least one refreshed credential obtained from said anonymous verifiable credential 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 credential of interest.

[0035] In a particular embodiment: (i) the proof that said identifier y of said anonymous verifiable accreditation of interest j belongs to said white list is of the type 7Trep), with: C = aiwy = V^ A = C\ where Zp (note that this value A should not be confused with the value A of the equation (EQ) presented later). Let A=C1a = Aa and A =A'1. We therefore have _ y^'" = PoK(z, a„ : A = (ii) the proof (7Tbl) that said identifier (y = an) of said anonymous verifiable accreditation of interest VC1^ does not belong to said blacklist is of the type ^neq)^ with: C = ûy v A = Cl, where / ^Zp A=da Or : - A / p / 2 are public generators of said accumulator; - a is an integer belonging to {1, 2,..., p-1}, the private key sk of the accreditation management device for the management of the accumulator being equal to a - the public key Pk for managing the accumulator is Pk = (P[, P^) - B=vcy=Ca - y is the value of the accumulator before said update; - d = Pv ( -y ) where Pv is a polynomial defined by Pv ( x ) = 0^^, ( )' + X ) ' yy being a list of secret values ​​used to initialize the accumulator - Vq is an initial value of the accumulator: «) - ^neq = poK^ d; Hn. X = V^Â"'1 a 1 0 a d7

[0036] To verify the validity of ^wl, we must ensure that the following equality is satisfied e( A f? ) = e(A and on the other hand that ^REP is valid. The algorithm for verifying this ZKP (^REP) being relatively classic for those skilled in the art, we do not de- will not cut into this document.

[0037] For further information; those skilled in the art may refer to the document David Chaum, Torben P. Pedersen: Wallet Databases with Observers. CRYPTO 1992: 89-105

[0038] If nWL is valid then, we easily demonstrate that we necessarily know C and an such that c = y — V and therefore that, under the q-SDH hypothesis, Y is indeed accumulated in V.

[0039] Furthermore, and very advantageously, it is mathematically demonstrated that the proof ^wl thus defined does not reveal any information on the value 2 (for example on the identifier of the user's accreditation, including for a user with unlimited computing power and therefore a fortiori for an attacker with a quantum computer).

[0040] Let ç' _ y be the witness of belonging of the identifier (y') of the accreditation of a user U ' (different from the user U having generated the proof 71 wl), to the list of valid identifiers. We have of course y' y. We will on the one hand demonstrate that the user W could just as well have generated the same proof ^wl (i.e. by producing exactly the same values ​​a. A cl ^rep) and on the other hand that no one, including an attacker with unlimited computing power, is able to know who, of W or U ', generated the proof: — ^A A' ^rep)'

[0041] 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'e Zp such that _ Q'i. We therefore have _ y' / tv^ and therefore that Ay+a — V' • ^cc' implies, by reusing the notations above, that _ yi Ay • We have just shown that U could also have produced the values ​​A and

[0042] Given that the ^-REP proof, which is, let us recall, classic for those skilled in the art, is statistically proven ZK, it therefore reveals no information, including when faced with an attacker with unlimited computing power, on the secret pair (1, y) used to produce the ^REP proof.

[0043] Consequently, an attacker, even one with unlimited computing power, has no possibility of determining which of U or W generated the proof: = ^A, A ^REp)' This concludes the demonstration that kREP does indeed guarantee eternal confidentiality (in English Everlasting Privacy).

[0044] Similarly, to verify the validity of one must on the one hand ensure that the following equality is satisfied e(yf?) = C^Â. f?)ct on the other hand that ^neq is valid. The verification algorithm of this ZKP (tîneq) being relatively classic for those skilled in the art (see for example [2] and [3]), we will not detail it in this document.

[0045] [2]: David Chaum, Torben P. Pedersen: bWallet Databases with Observers. CRYPTO 1992: 89-105

[0046] [3]: Stefan Brands: Rapid Demonstration of Linear Relations Connected by Boolean Operators. EUROCRYPT 1997: 318-333

[0047] If ^bl is valid then, it is easily demonstrated that the user necessarily knows values ​​C, d # 0 and Y such that q — — y / c^fVy+a and therefore that, under the q-SDH hypothesis, is not accumulated in V.

[0048] It is understood that the user must, in addition to his VP, also transfer this proof of knowledge ^bl to the service provider in order to convince him that the VP does indeed contain an unrevoked VC.

[0049] The eternal confidentiality provided by ^bl is demonstrated in the same way as in the previous case with hwl.

[0050] It should be noted that the ZKP zero-knowledge proofs proposed in the state of the art for nWL 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 kwl or ^bl proofs, on the other hand, in this disclosure do not reveal any information about the user who presents it (including for an attacker with unbounded computing power) and only involve classical mathematical operations (addition of points or scalar multiplications on elliptic curves) and are sufficiently efficient to be executed by smart cards.

[0051] 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 credential of interest relating to attributes of interest of the user and proof of non-revocation of an identifier of said anonymous verifiable credential 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 the non-revocation of said identifier being conditions necessary to authorize the user's access to said service.

[0052] 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 verification module 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 the non-revocation of said identifier being necessary conditions for authorizing the user's access to said service.

[0053] 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 therefore sees his privacy protected to the maximum with unlimited confidentiality (in English, this type of protection is known as Everlasting Privacy).

[0054] The disclosure also relates to a computer program comprising instructions for executing the steps of a method as described above when said program is executed by a computer.

[0055] 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.

[0056] The disclosure also relates to a computer-readable information medium, and comprising instructions of a computer program as mentioned above. The information medium can be any entity or device capable of store 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 over 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

[0057] 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 which are not in any limiting nature. In the figures:

[0058] [Fig-1] [Fig.l] represents a system comprising a device for managing at least at least one anonymous verifiable credential, a service access request device and a service access control device in accordance with particular embodiments of the present disclosure;

[0059] [Fig.2] [Fig.2] represents in the form of flowcharts steps of a method for managing at least one anonymous verifiable accreditation, of a method for requesting access to a service and of a method for controlling access to a service in accordance with particular embodiments of the present disclosure;

[0060] [Fig.3] [Fig.3] represents the hardware architecture of the devices of [Fig.l] in a particular embodiment of the present disclosure.

[0061] As a preliminary matter, we recall cryptographic tools used in the present disclosure. 1. Pledge schemes

[0062] Pledging a value is a cryptographic process allowing an issuer to commit to a value to a recipient without revealing it at first glance and in such a way that this commitment can no longer be modified subsequently. This value can, if necessary, be revealed subsequently by the issuer.

[0063] Thus, the recipient has the assurance that once the commitment is published, the issuer can no longer change his mind about the value contained in this commitment.

[0064] 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 commitments by perfectly indistinguishable (perfectly hiding in English) and computationally collision-resistant.

[0065] Presentation of Pedersen's pledge scheme

[0066] In a Pedersen pledge scheme we consider a cyclic group G of prime order P and 8 and A any two generators of G. We assume that the discrete logarithm of h in base 8 is unknown.

[0067] For a "pledge" operation in which a sender commits a message me Zp to a recipient, the sender chooses a random value r G Zp, calculates C - and sends it to the recipient.

[0068] For an “open” operation, the sender sends the message m and the random value 7 to the recipient so that the latter can verify the equality: C = gmll ■

[0069] The above method can be easily generalized by pledging several messages, for example n messages m2, mn)-

[0070] Let G be a cyclic group of prime order P and n + 1 arbitrary generators of G-gŸ g2, ---,8,, and h.

[0071] To commit to messages 7îîi' m2, ---,mn e Zp of its choice, the sender chooses a random value re Zp and calculates C = Z”1 x Z”2 X ■ ■ ■ XZ"” X II and O] o2 sends it to the recipient.

[0072] For the opening operation, the sender sends to the recipient the messages m 1' ■■■' and the random value 7 so that the latter can verify the equality: C = xg"^ x ■ ■ ■ xxh' ■ 2. Zero-knowledge evidence

[0073] We recall 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 it verifies the given predicate P. Subsequently, to represent zero-knowledge proofs, we will sometimes use the usual notation PoK{a, [3, ...: predicate on a, P, ...]•

[0074] In some embodiments, the present invention further utilizes 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

[0075] In a particular embodiment, some devices may use an anonymous signature scheme (a variant of a group signature scheme), such

[0076] schemes allowing a requester to prove their membership in a group (here a group of service providers) without revealing their 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 the "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 (MG) has a pair of keys, private and public (denoted (SKMG, PKMGj) and a digital signature algorithm. During the registration phase, the group member (denoted U) receives from the group manager MG a signature J on a public key PK generated for the occasion (of which only he knows the associated private key SK: _ (pjA . The key group public key is PKMG. while user's private key is SK and his membership certificate is (PK, a).

[0077] To prove to a service provider or any other third party that he is indeed part of the group managed by MG, the user U encrypts his public key PK using the public key PKRA of the revocation authority RA (Ct — Epr^PK}), then encrypts a ( = Epr (a)) always with the public key PKRA. The user generates a zero-knowledge proof 57 demonstrating that he knows on the one hand the plaintext of C\ (i.e. PK) but also the private key corresponding to this plaintext (i.e. SK) and on the other hand that the plaintext of C2 (i.e. G) is indeed a signature of MG on the plaintext of Cx (i.e. PK). The group signature consists of (Cb C2, Æ).

[0078] In a particular embodiment, the De-lerablé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 al 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, GR, Chaum, D. (eds.) CRYPTO 1984. LNCS, vol. 196, pp. 10-18. Springer, Heidelberg (1985)). Any other group signature scheme can, however, be implemented in this disclosure. 4. Cryptographic accumulator 4.1 Principle

[0079] It is recalled 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.

[0080] 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.

[0081] In other words, given a membership witness H for an accumulated element x and the current value of the accumulator V, it is possible to efficiently verify that the element x is indeed part of the list of accumulated elements.

[0082] Cryptographic accumulators that support only membership witnesses are called positive accumulators, those that support only non-membership witnesses are called negative accumulators, while those that support both are called universal accumulators.

[0083] A common requirement for cryptographic accumulators is the ability to modify the set of accumulated elements, which allows for updates of the accumulator.

[0084] In the embodiment described here, a managing entity of the cryptographic accumulator defines the public parameters of this cryptographic accumulator: PP^ GvG* Gt, p, f, - e: a defined bilinear coupling from G1 x G2 to a set GT where G G2 and Gt denote cyclic groups of order P, P being a prime number. For simplification, we assume that the group law in Gs and G2 is multiplication; - f and / j denote two randomly chosen generators of G}, so that the discrete logarithm of one of these generators is unknown with respect to another of these generators; and - designates a randomly chosen G2 generator

[0085] In the following, all calculations relating to exponents will be carried out modulo P. 4.2 Key generation:

[0086] In one embodiment of the present disclosure, the manager of the cryptographic accumulator randomly generates an integer a belonging to {1, 2,..., p-1} and calculates p^ = as well as P^ = fY The private key sk of the cryptographic accumulator manager can be chosen equal to a and its public key Pk can be made up of the pair ( P j, P2 ) .

[0087] As is known to those skilled in the art of cryptography, the value of the accumulator changes depending on the values ​​that can be added or removed from it.

[0088] We note V the value of the accumulator at a given instant and Y y the list of values ​​accumulated in the accumulator V. 4.3 Initializing the Accumulator

[0089] In one embodiment of the present disclosure, the accumulator manager generates a number of random values ​​y. e Zp which must remain secret.

[0090] We note 17 y this list of secret values ​​and by the initial value of the accumulator: v _ V0~J " 4.4 Battery Status

[0091] The state of the accumulator V at a given instant is characterized by a pair (V, Yv ) where V e Gj is the value of the accumulator and where Yv designates the set of elements accumulated in V, excluding the initialization elements: y _ yFÏ0 + O _ ®)- 4.5 Accumulator Update

[0092] In one embodiment of the present disclosure, to add an element 7 to the accumulator in the current state (V', Yy), the accumulator manager performs the following calculation: y = y''+a. The new state of the accumulator becomes (V, Yv ) where Yv = Yv, U {>'}.

[0093] In one embodiment of the present disclosure, to remove an element 7 from the accumulator in the current state (V, Y y ), the accumulator manager performs the following calculation: y _ y . The new state of the accumulator becomes (V, Yv) where Y}, = Yv.\M. 4.6 Calculation of a membership witness

[0094] Let (V, Y y) be the current state of the accumulator and 7 a value belonging to Y y and accumulated in V, we note œ^v the certificate or witness of belonging of 7 to the list Y y and relative to the current value V of the accumulator.

[0095] 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 3' does indeed belong to Yv and is therefore accumulated in V.

[0096] In one embodiment of the present disclosure, the witness v of the membership of 3' to the list T'y is calculated in the following manner by the accumulator manager: (j _ œ y _ yV^.

[0097] In one embodiment of the disclosure, the accumulator manager generates a zero-knowledge disclosure proof, noted proving the validity of this witness or C of belonging to the accumulator V.

[0098] We can note that y - C^- Let us denote by B=\ / ('~y=Ca. The membership witness C is therefore valid if the discrete logarithm of B in the base C is equal to the discrete logarithm of P] in the base f: 1¼.. v^PoKj^ • B — Ca / \ PA — fa^

[0099] Since only the accumulator manager knows a, only it is able to generate this proof.

[0100] In a particular embodiment, the accumulator manager can transmit the membership witness C (or a'yy) and the proof nw>,v to a user who can verify the validity of n(«v V. His witness C will only be valid if the proof IL,.,, is also valid. 4.7 Calculation of a non-membership witness

[0101] Let (V, ) be the current state of the accumulator and b a value not belonging to and therefore not accumulated in V.

[0102] In one embodiment, we designate by Pv(x), the polynomial PvÇx) = riÆ9-vxjyVi()'+ *)•

[0103] We note d — Pv( - >')• If d 0, we designate by Wy.v the certificate or witness of non-membership of y to the list 7 v and relative to the current value V of the accumulator. This witness of non-membership can be generated by the manager of the accumulator and used by a user to prove using a proof of knowledge with zero knowledge disclosure, that this value b does not belong to ^y and is therefore not accumulated in V.

[0104] In one embodiment of the present disclosure, the witness Ov V of the non-membership of b' to the list ^y is calculated in the following manner, for example by the accumulator manager:

[0105] C = y = y 7.

[0106] In one embodiment of the disclosure, the accumulator manager generates a zero-knowledge disclosure proof, noted ILlv proving the validity of this witness of non-membership of the accumulator V.

[0107] We can notice that Vpd — Cyr+a- Let us denote by B=yydçy=Ç,'. The witness C will therefore be valid if the discrete logarithm of B in the base C is equal to the discrete logarithm of Pi in the base / j: 11^=PoK[a:5 = CaAPi— As only the accumulator manager knows a, only he is able to generate this proof.

[0108] The accumulator manager can transmit the witness C (or é\y) and d as well as the proof 11^ to the user. After receiving C and I l;r. v , the user can check the validity of 11^v. His witness C will only be valid if the proof IL? v is also valid and d * 0.

[0109] It is remarkable to note that the proofs and Ü& v can be verified by constrained devices such as secure elements, because it only involves operations in the group Gy (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.

[0110] 4, 8 Updating a membership or non-membership witness

[0111] In the embodiment described here, the membership or non-membership indicator of a user must be updated each time the list is modified.

[0112] The witness can be updated by the accumulator manager; the user can then obtain it from the manager.

[0113] Alternatively, the user can himself, that is to say without calling the accumulator manager, update his membership indicator (respectively non-membership indicator) in the event that a new value is added or removed from the accumulator.

[0114] In the paragraphs below, we will assume that a user has already received a membership or non-membership indicator for a value y*, and we note (V, Xy ) the current state of this accumulator.

[0115] 4.8.1 Updating a membership witness by adding a value:

[0116] We assume that a value y' is added to the accumulator which therefore passes from the state (V, ^y ) to the new state (V, Xy) where y' _ y'''+a The user can update his membership witness by performing the following calculation: q< _ yty-yO xy where C designates the current value of the user's membership witness and v* the user's value.

[0117] 4.8.2 Updating a membership witness by removing a value:

[0118] We assume that a value y' is removed from the accumulator which therefore passes from the state (V, ^fy) to the new state (V', where y < _ yThe user can update his membership indicator by performing the following calculation ■ Q' — xy' A->') where C designates the current value of the user's membership indicator and y* the value for which this accumulator was created.

[0119] 4.8.3 Updating a non-membership witness by adding a value:

[0120] We assume that a value y' is added to the accumulator which therefore passes from the state (V, Cf y) to the new state (V", yv) where y' _ y>'+« The user can update his membership indicator by performing the following calculation: C - -v*) xy where C denotes the value current value of the user's non-membership witness and y* the value for which this accumulator was created and d' — dx ( v' - y*) •

[0121] 4.8.4 Updating a non-membership witness by removing a value:

[0122] We assume that a value y' is removed from the accumulator which therefore passes from the state (V, y*y ) to the new state (V\ where y < _ y7y+«j The user can update his membership indicator by performing the following calculation -y1 — y / ^-y^ xy ' 7b > where C designates the current value of the user's non-membership indicator and y* the value for which this accumulator was created and d = ™ • yV

[0123] First example of implementation of the disclosure

[0124] In a first example of implementation of the disclosure, we consider an identity provider, a service provider and a user. Identity Provider

[0125] 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.

[0126] In a particular embodiment of this disclosure, the identity provider may use the BBS+ protocol to certify user attributes.

[0127] In a particular embodiment, the identity provider also manages a compressed list of revoked anonymous verifiable VC credentials (or a list of non-revoked credentials) through a cryptographic accumulator.

[0128] In a particular embodiment, the identity provider can provide users, following the delivery of their verifiable anonymous accreditation VC, their witnesses of membership (respectively of non-membership) to the compressed list of valid (respectively revoked) verifiable accreditations. Service provider

[0129] 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 pre Verifiable Presentation (VP) generated from an anonymous, verifiable credential, certifying one's age, issued by an identity provider trusted by the service provider.

[0130] In one embodiment of the present disclosure, the service provider must verify that the VP verifiable presentation presented to it was indeed generated from a valid, i.e., non-revoked, anonymous VC verifiable credential. Users

[0131] In one embodiment of the present disclosure, users have one or more anonymous verifiable accreditations and their respective witnesses of membership (respectively of non-membership) in the compressed list of valid accreditations (respectively in the compressed list of revoked accreditations), 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.

[0132] 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.

[0133] The private keys and secrets of users used in particular by users to prove that the anonymous verifiable VC credentials that they present belong to them are preferably stored in secure devices such as secure elements (Secure Element), hardware security modules (Hardware Security Module HSM) or in trusted execution environments (Trusted execution environment TEE).

[0134] We will now describe an example implementation of the present disclosure in which an identity provider D-FI generates an anonymous verifiable credential VC relating to secret attributes and public attributes of a user D-USR, using its private key skj. In this example, when the identity provider produces a credential VC for a user, it inserts the identifier (for example a serial number) of this credential among the aforementioned public attributes. In this example, the identity provider also manages a white list comprising the identifiers of valid credentials or a black list comprising the identifiers of invalid or revoked credentials. It further manages a cryptographic accumulator in which the identifiers of the white list or the black list are accumulated.The identity provider provides the user with their anonymous VC credential, a witness that their credential's identifier is whitelisted or a witness that this identifier is not blacklisted, and a proof associated with this witness.

[0135] In this example, the user refreshes this VC credential and sends the refreshed credential to a D-FS service provider in a VP verifiable presentation 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 proof of non-revocation of the identifier of his credential.

[0136] In this example, the service provider verifies the non-revocation proof of the user's credential identifier, signs the VP verifiable presentation with a skRP group private key, and validates the credential of the VP verifiable presentation using the identity provider's public key.

[0137] In this example the D-FS service provider checks the validity of the requested attributes and waits for proof of the validity of the accreditation to authorize the user's access to said service.

[0138] [Fig. 1] represents a system SYS comprising a D-FI anonymous accreditation 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.

[0139] To simplify the description, the anonymous accreditation management D-FI device will sometimes be referred to as the “FI identity provider D-FI device”.

[0140] Similarly, the D-FS device for controlling access to a service will sometimes be called a “D-FS device for providing service”.

[0141] Similarly, the D-USR device for requesting access to a service will sometimes be called a “D-USR user device”.

[0142] 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 anonymous accreditation management device and the user USR can designate the D-USR service access request device.

[0143] [Fig.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.

[0144] 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.

[0145] In the embodiment described herein:

[0146] pp = (e, Gh G2, Gt, p, n, g, gtf gf gy gn, gn+f hh h2, hb h, f, fb f2) or

[0147] (e, G? G2, Gt) denotes a bilinear environment, for which we will do the assumption that the q-SDH problem is hard.

[0148] P is a prime number which denotes the order of the cyclic groups Gb G2 and GT

[0149] n the number of attributes (a1; ..., an) to be certified. In a particular mode of rea lization, the attributes ( ab ..., an.j ) are sovereign attributes and an is a serial number of the anonymous VC accreditation.

[0150] §o' £]' ^2' ®n' ^n+i designate n+3 randomly chosen Gy generators (of such that no one knows the discrete logarithm of one of these generators with respect to another of these generators). Each [ ]11 is associated with an attribute type I £-¼ I 1 ih=i specific (for example will be associated with the attribute “name”, ë2 with the attribute “first name”, §3 with the attribute “age”, §4 with the attribute “gender”, etc.). This will allow us to differentiate the attributes and avoid any ambiguity.

[0151] f, fb f2 correspond to the public generators of the accumulator managed by the D-FI identity provider

[0152] hb h2, -, h] designate 1 additional generators of G j chosen randomly (such that so that no one knows the discrete logarithm of one of these generators by relative to another of these generators). Each fh C will be associated with a secret attribute 1 (additional to aû) of the user. The exact number of additional secret attributes depends on the use case.

[0153] h denotes a generator of G2.

[0154] In the following, all calculations involving exponents will be performed modulo P (mod P). We will denote by params = (pp) where 7 / will denote a cryptographically secure hash function (e.g. SHA-256). Key Generations:

[0155] In the embodiment described here, the identity provider D-FI randomly generates an integer skj belonging to {l,2,...,pl} and calculates p^, _ Its private key will be skj and PKj its public key.

[0156] 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 the revoked anonymous verifiable accreditations in the case of the management of a black list, or valid serial numbers if it is a white list. To do this, it randomly generates an integer H belonging to {1, 2,..., p] and calculates P1 = as well as P, — f“.

[0157] We will also assume that each user U also has a private and public key pair (skÜ5 PK[ ; = gsku) certified by a certification authority.

[0158] The user's D-USR device knows the public parameters PP of the BBS+ system and the public key PKj of the D-FI identity provider

[0159] 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 accreditation.

[0160] In the embodiment described here, the D-USR device comprises a communication module COM3. This module can be used to send a commitment Com relating to secret attributes of the user to the D-FI device and receive an anonymous verifiable accreditation VC relating to these attributes and to public attributes of the user.

[0161] In the embodiment described, the device D-USR of the user USR comprises a cryptographic module WAL, for example an electronic identity wallet configured to store at least one anonymous verifiable accreditation VC 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 cryptographic module WAL can in particular also store a witness C of the belonging of the identifier y of this accreditation VC to a white list of valid identifiers or a witness of the non-belonging of this identifier -1' to a black list of invalid identifiers.

[0162] The WAL cryptographic module is for example configured to obtain proof of non-revocation of this identifier X

[0163] In the embodiment described here, the COM3 communication module of the D-USR device can be used to send this proof to a D-FS service provider.

[0164] In the embodiment described herein, the D-USR device comprises a MUT module configured to use at least one of the user's certified attributes to access a service of the D-FS service provider.

[0165] In the embodiment described here, the anonymous accreditation management device D-FI comprises a communication module C0M1. This module can in particular be used by the D-FI device to obtain commitment on the secret attributes of the user, send him a VC accreditation, send proofs, receive a verifiable presentation.

[0166] In the embodiment described here, the D-FI accreditation management device comprises a cryptographic module M-CRY1. This module can in particular be used to authenticate a user, generate and verify the validity of an anonymous verifiable accreditation VC relating to attributes and in the form of a blind signature using the private key, calculate proofs, verify signatures, in particular group signatures.

[0167] The cryptographic module M-CRY1 can also be configured to manage a white or black list of accreditation identifiers and to calculate a witness C of the belonging of the identifier y of an accreditation VC to a white list of valid identifiers or a witness of the non-belonging of this identifier 2 to a black list of invalid identifiers.

[0168] 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, proof Ily^ of non-revocation of an identifier y of this accreditation.

[0169] 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 Ily^, and to sign the verifiable presentation VP with a group private key.

[0170] The COM2 module of the D-FS device can be used to send to an accreditation management device a request for verification of an anonymous verifiable accreditation

[0171] [Fig.2] represents in the form of a flowchart the main stages of a process management of at least one anonymous verifiable accreditation implemented by the identity provider FI, the main steps of a method of 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.

[0172] In this example, we assume that user USR has / + 1 secret attributes «O $1' 1S2' -, slu e ^P'

[0173] In this example, the user USR uses a D-USR device to request the D-FI device of an identity provider FI to provide him with an anonymous verifiable credential UC covering the / + 1 secret attributes and n public attributes a 1' • ■ ■ ' a».

[0174] In the example described here, the n public attributes include n - 1 sovereign attributes and an attribute an corresponding to an identifier, for example a serial number, of the verifiable anonymous accreditation VC.

[0175] In the embodiment described here, the service provider FI 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 V the current value of this accumulator

[0176] During a step U4, the user USR uses his key pair (PKV, sky) to authenticate himself with the identity provider FI. In the embodiment described Here, if the FI identity provider does not authenticate the USR user, the result of a test 14 is negative and the process stops.

[0177] If the authentication is successful, during a step U5, the D-USR device of the user USR calculates a pledge (or commitment) Com on all of its secret values ​​and a proof that it knows how to open this commitment. [°178] C()m = OR ru e Zp

[0179] In the embodiment in which the user would like the verifiable anonymous accreditation VC to only relate to 1 secret attribute, we would have: Com = °0 °n+I

[0180] In the embodiment described herein, the Com 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.

[0181] During a step U6, the user USR transmits to the identity provider FI his public key PKU, the commitment Com and the proof

[0182] The service provider FI verifies the validity of the proof77u during a step U7. In the embodiment described here, if the proof is not valid, the method of issuing a verifiable anonymous accreditation stops.

[0183] During a step 18, the service provider FI determines a 3' identifier of the anonymous verifiable accreditation VC that it will generate for the user USR.

[0184] During a step 110, the service provider updates the cryptographic accumulator. This operation notably includes updating the list 9^ of accumulated elements, either adding the identifier y (sometimes noted in the document) to the list if this list is a white list containing valid identifiers, or removing the identifier -f from this list if this list is a black list containing invalid identifiers. This operation also includes updating the value V of the accumulator. An example of implementation of these operations was presented in chapter “4. 5 Updating the accumulator”.

[0185] During a step 112, the service provider calculates a witness C which represents: (i) the fact that the identifier 3' of the verifiable anonymous accreditation belongs to the list yv of accumulated elements if this list is a white list. In this case, the witness C can be calculated by the formula q _ _ y' / («,,+«) presented in section «4. 6 Calculation of a membership witness”; or (ii) the fact that the identifier 3 of the verifiable anonymous accreditation does not belong to the list yv of accumulated elements if this list is a black list. In this case, the witness C can be calculated by the formula yVCw) presented in section “4.7 Calculation of a non-membership witness”.

[0186] During this same step 112, the service provider calculates a proof nc associated with the witness C.

[0187] In the embodiment described herein, and as previously described in sections “4. 6 Calculation of a Membership Witness” and “4. 7 Calculation of a Non-Membership Witness”: (i) when witness C is a witness of membership of the identifier in a white list of the form q _ _ yJ / , the evidence nc associated with this witness œyy can be : Ilc = Il^PoK^ • B = / \ = and (ii) when witness C is a witness of non-membership of identifier 2 in a blacklist, of the form _ i / / («„+■>), the evidence nc associated with this witness c ttyv — vj Wy,v can be: is nc=nâM,=PoK[G ; B=A pi =

[0188] In the embodiment described here, the identity provider FI generates the anonymous verifiable credential VC during a step 114.

[0189] In the embodiment described here, this anonymous verifiable accreditation VC relates to the commitment Com calculated from the / + 1 secret attributes of the user and on the public attributes an comprising n- 1 sovereign attributes ^1' • • • ' aTh\ and the identifier? (or year) of the anonymous verifiable VC accreditation.

[0190] In the embodiment described here, this signature is a blind signature calculated using a private key sk, 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.

[0191] In the embodiment described here, this signature is calculated using the BBS+ protocol.

[0192] For further information on this standard, those skilled in the art may 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. Traoré, "Improved Algebraic MACs and Practical Keyed-Vérification Anonymous Credentials", In International Conférence on Selected Areas in Cryp- tography, 1016,<https: / / link.springer.com / chapter / 10.1007 / 978-3-319-69453-5_20> .

[0193] In the embodiment described here, the anonymous verifiable accreditation VC is a pair (A, r) calculated according to the BBS+ protocol defined by public parameters PP with pp = (e, G}, G2, Gt, p,n, g, gQ, g? gr„ gn, gn+v ., / ¾ h - (e, G CG Gr) denotes a bilinear environment for which the q-SDH problem is difficult;= - p is a prime integer which designates the order of the cyclic groups Gh G2 and GT - 8' 8ff 8{, 82' - 8^ 8„+3 denote n+3 randomly chosen generators of G}, each f 1 ” being associated with a specific type of attribute; ] o; | 1 *' Ï=1 - f, / pf 2 are 'public generators of said accumulator; - h denotes a generator of G2, and in which: / ni fn" J / C^+r) (EQ), WHERE A = (Ïq, A'p S2,---, s', r G Zp are random values ​​chosen by said rights management entity.

[0194] In the embodiment in which the user would like the verifiable anonymous accreditation VC to only relate to 1 secret attribute, we would have: / where «o = an + « 'o and ao represents the value set in pledge in Com.

[0195] In the embodiment described here, during a step 116, the identity provider FI calculates a proof ^vaiid of the validity of the anonymous verifiable accreditation VC.

[0196] The person skilled in the art understands that / vt / O^r) A = [gComgÿn^ implies that: (i) = H where H = e'““ (ii) A^=HA'r

[0197] By noting _ j£^'r the identity provider can calculate a ^valid proof at disclosure of knowledge, for example Schnorr demonstrating that A has indeed been calculated correctly, in other words that the discrete logarithm of b in base A is equal to the discrete logarithm of PK{ in base h.

[0198] For further information on Schnorr proofs, the skilled person may refer to Claus-Peter Schnorr: Efficient Identification and Signatures for Smart Cards. CRYPTO 1989: 239-252.

[0199] During a step 118, the identity provider FI sends to the user: (i) anonymous verifiable VC accreditation; (ii) proof of the validity of this accreditation; (iii) the identifier y of this anonymous verifiable accreditation VC; (iv) witness C of membership or non-membership of this identifier in a list and the proof Hc associated with this witness.

[0200] In the embodiment described here, the identity provider also sends, in the same message, the random values ​​.Vp S[-

[0201] These elements are received by the user USR during the same step.

[0202] During a step U20, the user's D-USR device: - calculates a0 = a0 + a'^ (mod p) and = s\ + s- (mod p) and - unblinds anonymous VC verifiable accreditation and obtains anonymous verifiable accreditation also rated VC for simplicity.

[0203] During a step U22, it verifies the validity of the signature (A, r) by verifying the proof ^valid and the proof üc associated with the witness of belonging (proof or with the witness of non-belonging (proof 11^).

[0204] This deblinded signature of the message consisting of the commitment Com on the secret attributes (a'() 5'..., s'{), the public attributes (a..., of this user and the identifier y=an of the anonymous verifiable accreditation VC 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.

[0205] We will now describe the main steps implemented by the various stakeholders (user, service provider, identity provider) when the USR user wishes to access a service offered by the FS service provider.

[0206] During a step U22, the user USR connects anonymously to the service provider FS.

[0207] 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 interest attributes) 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.

[0208] We will designate by D, the list of indices of the attributes of interest [a-1 claimed 1 1J ZeD by the service provider FS and in this example D = {1, 2} •

[0209] During a step U26, the user USR selects from among the anonymous verifiable accreditations VC received from the identity provider FI, one or more anonymous verifiable accreditations of interest VC1 bearing the attributes of interest of the service provider FS. For the sake of simplification, we consider that a single accreditation VC1 relates to all the attributes of interest.

[0210] In the embodiment described here, the user USR generates a verifiable presentation VP (in English "verifiable presentation") from this interest accreditation VC1-

[0211] In the embodiment described here, the user USR calculates a pledge C on all of its certified public attributes ' an. For the sake of simplification, we will assume that it actually calculates n pledges, one pledge per public attribute: C = (C j, C?, ..., C„) where Ci (ic {1,2, ..., n}) denotes a pledge on the attribute ai.

[0212] 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 sk^, the interest accreditation VC1 produced in step 114.

[0213] 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 VCrl from the accreditation of interest VC1 ■

[0214] This new refreshed verifiable accreditation VC'1 still relates to the secret attributes (a'o s\, ..., s'^, the public attributes (^, ..., an_)) of this user and to the identifier 3' of the accreditation of interest VC1 but it cannot be compared, in particular by the identity provider FI, with the VC accreditation produced by the identity provider FI in step 114.

[0215] In the embodiment described here, the user USR generates a zero-knowledge proof demonstrating that he knows how to reveal the n pledges Q and that the verifiable anonymous accreditation VC is valid on the set of pledged values ​​«i, • • • ' an.

[0216] During a step U28, the user USR generates a verifiable presentation VP featuring the refreshed VC'1 verifiable accreditation ■

[0217] In the described embodiment, the verifiable presentation VP comprises the public key PKj of the identity provider FI, the verifiable accreditation VC'1 the pledges C, and the zero-knowledge proof 77u: VP = (PKb 1 i= 1

[0218] As mentioned previously, in the embodiment described here, the service provider FS needs to verify the requested public attributes of interest ^2 and the user must therefore provide it with information for them. get.

[0219] In the embodiment described herein, this information includes the data necessary to reveal the pledges Ch only for i 6 D.

[0220] These data are hereinafter called opening data and noted Open(C^. •

[0221] When using a pledge scheme based on a hash function H, the pledge can be of the type Q = HU / j where ri is a random number. In this example ai and ri constitute the opening data OpeniCp •

[0222] During a step U30, the user calculates a proof of non-revocation of the identifier 3' of the anonymous verifiable accreditation of interest VC1 ■ In the embodiment described here, this proof is constituted by: - a nwl proof that the identifier belongs to the white list of valid identifiers or by - proof 77 bl that this identifier 3? does not belong to the blacklist of invalid identifiers.

[0223] Example of generation of proof 77 wl

[0224] This proof allows the user USR to prove that the identifier is valid. We recall that in the case of a white list, the indicator of belonging to the list of valid identifiers is of the type £ = v — yV^^, and we note (V, Yv ) the current state of the accumulator.

[0225] In the embodiment described here, the user first calculates a refresh of his membership witness C. To do this, he chooses ] e Zp and calculates C1-Let us set A = C1. We have Cao+a= V and therefore C“= ​​VC a“- Which implies that C!ci= ylQ1^1

[0226] Let ^=Cla = Aa and À =A-1. We therefore have _ yy^1”-

[0227] The USR user then generates a zero-knowledge proof: kRep = PoK^ an: Â^vyQ

[0228] In this particular embodiment, the user USR also proves in his verifiable presentation VP that the identifier 3'= an used for the proof of non- revocation is the same as that normally present in its anonymous VC accreditation.

[0229] For example, user USR generates a ZK proof that the identifier y ~ a" in the representation of  in bases V and À is the same as that of the pledge Cn. For this ZK proof, the skilled person may refer to David Chaum, Torben P. Pedersen: Wallet Databases with Observers. CRYPTO 1992: 89-105. We will implicitly assume that this ^BQ proof is integrated into the nv proof described above.

[0230] In the embodiment described here, the final kwl proof consists of the following data: = % 7Trep).

[0231] Example of generation of proof 77bl

[0232] This proof allows the user USR to prove that the identifier y 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 C = wvv = ' ct on notc ) the current state of the accumulator.

[0233] In the embodiment described here, the user first calculates a refresh of his non-membership witness C. To do this, he chooses 1 e Zp and calculates C1- Let A = C!. We have Ca,,+a= Vfd with d 0 and therefore Ca= VfdC a''- Which implies that Cict= y lfldC l'ln

[0234] Let C!“ = Aa and À =Adet d = - EL We therefore have _ y1^'^-

[0235] User USR then generates a zero-knowledge proof: ^•neq = poK^ d' an . X = vW” A 1 0 A d'oj.

[0236] In this particular embodiment, the user USR also proves in his verifiable presentation VP that the identifier y ~ an used for the proof of non-revocation is indeed the same as that normally present in his anonymous accreditation VC,

[0237] For example, user USR generates a ZK proof that the identifier 3' — an in the representation of  in bases V and À is the same as that of the pledge Cn. For this ZK proof, the skilled person may refer to David Chaum, Torben P. Pedersen: Wallet Databases with Observers. CRYPTO 1992: 89-105. We will implicitly assume that this proof ^G is embedded in the nu proof described above.

[0238] In the embodiment described here, the final proof consists of the following data: = % jt^q).

[0239] During a step U32, the user sends to the service provider FS: (i) the VP verifiable presentation including the anonymous verifiable accreditation ra VC1 refresh obtained from the anonymous verifiable credential of interest VC1 '(ü) the proof of non-revocation of the identifier 3' of the anonymous verifiable credential of interest VC1 constituted by the proof ^wl that the identifier -F belongs to the white list of valid identifiers or by the proof 77 bl that this identifier does not belong to the black list of invalid (revoked) identifiers.

[0240] In the embodiment described here, the user also sends the opening data OperAC} to the service provider FS.

[0241] During a step S34, the service provider FS verifies that the opening data Open(C^. actually makes it possible to reveal the attributes of interest a^et of the user and that these attributes comply with the conditions of access to its service.

[0242] If this is not the case, in the embodiment described here, the service provider FS refuses access to the service during a step S40.

[0243] In the embodiment described here, if the user's LP attributes comply with the conditions of access to his service, the service provider verifies, during a step, the validity of the zero-knowledge proof 77v. This step may not be performed, in particular 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.

[0244] In the embodiment described herein, if the service provider FS determines that the proof 77u is invalid, it denies access to the service.

[0245] During a step S36, the service provider verifies the proof IIvok of non-revocation, i.e. the validity of or of 71bl-

[0246] To verify the validity of the service provider, it must firstly ensure that the following equality is satisfied P?) — é^A / ) and secondly that ^rep is valid.

[0247] To verify the validity of 77 bl, the service provider must on the one hand ensure that the following equality is satisfied — e^A and on the other hand that 77 is valid.

[0248] The algorithm for verifying the proofs ^rep and ^neq being relatively classic for those skilled in the art, they will not be described here.

[0249] In the embodiment described here, before allowing access to the service to the user USR, the service provider FS must ensure that the user's interest attributes tt^ and a2 have been certified. In the embodiment described here, the service provider FS verifies the validity of these attributes using public key of identity provider FI.

[0250] In the embodiment described here, the service provider FS offers its service to the user, only if: - user interest attributes; - proof ^ok of the validity of the VC1 accreditation; - proof IIy^ of the non-revocation of the identifier of this accreditation has been obtained.

[0251] 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 [Fig.3].

[0252] This ORD computer includes in particular a processor 10, a RAM 11, a ROM 12 and communication means 13.

[0253] 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.

[0254] 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 previously with reference to [Fig.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.

[0255] 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 [Fig.2]. The PG-FI program defines in particular the module M-CRY1 for authentication and generation of an anonymous verifiable accreditation, and the module C0M1 of the D-FI device.

[0256] For the D-FS device, this PG-X computer program 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 [Fig. 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 disclosure

[0257] In the first example detailed above, the user's certified public attributes are used to access a service.

[0258] The present disclosure is not limited to this embodiment of the disclosure.

[0259] For example, the accreditation management device may generate a VC 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 for this VC accreditation.

[0260] 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 membership or non-membership of an accreditation identifier to such a list.

[0261] 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.

[0262] The user's device may 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 exercising the right to an entity with which the user wishes to exercise his right (merchant for 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 (VC), the method being implemented by an accreditation management device (D-FI) and comprising the following steps: - generation (114) of an anonymous verifiable accreditation (VC) relating to a plurality of attributes, one of which is an identifier (y) of this accreditation (VC); - updating (110) of a list (Yy) of accreditation identifiers accumulated in a cryptographic accumulator by adding or removing said identifier (3') and the value (V) of the accumulator, said list (Yy) being: (i) either a white list comprising valid identifiers; (ii) or a black list comprising invalid identifiers; - calculation (112) of a witness (C) representative of: (i) the membership of said identifier (y) in a white list; or (ii) the non-membership of said identifier (y) on a blacklist and (iii) evidence (nr) associated with said witness (C);- sending (118) to a user: (i) said anonymous verifiable accreditation (VC); (ii) proof (n) of the validity of said anonymous verifiable accreditation (VC); (iii) said identifier (y) of said anonymous verifiable accreditation (VC); (iv) said witness (C) and the proof (üc) associated with said witness.;

2. Method for managing at least one anonymous verifiable accreditation (VC), according to claim 1 in which one of said attributes (Com) is a commitment relating to a secret attribute (sj, .Ç,., sj) of the user.

3. Method for managing at least one anonymous verifiable accreditation according to claim 1 or 2 in which: (i) when said list (Yy) is a white list: - the value V of the accumulator after updating is calculated by ,v+a. V = V ' - the witness (C) of belonging of said identifier (y = a„) to said list - the proof Hc associated with this witness a'> v is nc = FL>yl =PoK (ii) where the said list (Y^) is a blacklist: - the value V of the accumulator after update is calculated by y = y; - the witness (C) of non-membership of said identifier (y) to said black list is calculated by _ _ y / ( û.t+i7 ) d, - the nc evidence associated with this witness is IIC = ILiyV=PoK Or : - / p / 2 are public generators of said accumulator; - a is an integer belonging to {1, 2,..p-1}, the private key sk of the device (D-FI) for managing accreditations (D-FI) for managing the accumulator is equal to a - the public key Pk for managing the accumulator is Pk = (P^ P^) - B=ycy=C° - y' is the value of the accumulator before said update; - d = Pv ( -y ) where Py is a polynomial defined by Py ( x ) = It eY oY (.V + -t) ​​• being a list of secret values ​​used to initialize the accumulator - Vo is an initial value of the accumulator: VQ-J ' ' °

4. Method implemented by a user device (D-USR), this method comprising the following steps: - reception (118), from an accreditation management device (D-FI): (i) at least one anonymous verifiable accreditation (VC) relating to a plurality of attributes, one of which is an identifier (y) of this accreditation (yc); (ii) verifiable proof of the validity of such accreditation anonymous (VC); (iii) the identifier (y) of said anonymous verifiable accreditation (VC); (iv) a witness of (C) the membership of said identifier (y) in a white list of valid identifiers or of the non-membership of said identifier (y) in a black list of invalid identifiers, said white or black list being a list (Yv) of elements accumulated in a cryptographic accumulator; (v) evidence (nr) associated with said witness (C); - obtaining (U30) proof (nvC>x) of non-revocation of the identifier (y) of said anonymous verifiable accreditation of interest (VC1) consisting of: (i) proof that said identifier (y) of said anonymous verifiable accreditation of interest (VC1) belongs to said white list or by (ii) proof that said identifier (y) 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 on condition of obtaining proof (ü^ of the validity of said accreditation (yQ1 j and of the non-revocation of said identifier (y).

5. Method according to claim 4 for requesting access to a service in which said at least one anonymous verifiable accreditation (VC) relates to a plurality of attributes (, an) of the user (USR), said method further comprising the following steps; - selection (U26) from said at least one anonymous verifiable accreditation (VC) of an anonymous verifiable accreditation of interest (VC1) relating to at least one attribute of interest to a provider of said service; - sending (U32), service provider (SP) audit: (i) a verifiable presentation (VP) 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 (nyOA) of non-revocation of the identifier (y) of said anonymous verifiable accreditation of interest (VC1)-

6. Method for requesting access to a service according to claim 5 in which: (i) the proof that said identifier (y) of said anonymous verifiable accreditation of interest (vdj belongs to said white list is of the type = (4 rfA with: C = œyy = A=d, where / ^Zp A=da ^HEP = poK^ . 2 = V1^ (ii) the proof that said identifier (y) of said anonymous verifiable accreditation of interest (vd^ does not belong to said blacklist is of the type = (a, % ^'EQy with: A = c\ ^l^Zp A=da Or : - A / g are public generators of said accumulator; - a is an integer belonging to {1, 2,..p-1}, the private key sk of the device (D-FI) for managing accreditations for the management of the accumulator being equal to a -Pi = ffP2=d - the public key Pk for managing the accumulator is Pk = (P^ PA - B=vcy=(d - y' is the value of the accumulator before said update; - d = Pv( -y ) where Py is a polynomial defined by Pvd} — fl eY oY (y + d' Yv0 being a list of secret values ​​used to initialize the accumulator - Vo is an initial value of the accumulator: a) v 0 “ J ”

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) including an anonymous verifiable accreditation of interest (yd) relating to attributes of user interest and proof (nyo^) of non-revocation of an identifier (y) of said anonymous verifiable accreditation of interest (vc7); - verification (S34) of said at least one attribute of interest; - verification (S36) of the validity of said proof ( ) of non-re vocation; - sending (S38) to an accreditation management device (D-FI) a request for verification of said anonymous verifiable accreditation of interest (VC1^ included in said verifiable presentation (VP), - a positive result of a verification (S40) of said at least one attribute and obtaining proof (II) of the validity of said accreditation (VC1) and of 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 wherein said anonymous verifiable credential (VC) is a blind signature calculated using a private key of said credential management device (D-FI).

9. Method according to claim 8 wherein said anonymous verifiable accreditation (VC) is a pair (A, r) calculated according to the BBS+ protocol defined by public parameters PP with pp = {e, G„ G2, Gt, p,n, g. gffgl,g2,^gn,gn+l,hl,h2?^hl,h, where: - (e, Gy G2, Gt) denotes a bilinear environment for which the q SDH problem is difficult; - p is a prime integer which denotes the order of the cyclic groups Gy G2 and Gt - P- Sff gp g2' ^n+1 designate n+3 randomly chosen GY generators torially, each fj” being associated with a specific type of attribute; - / ' fy f 2 are the public generators of said accumulator; - h denotes a generator of G2, and in which: / ___i ,, s, iKskj+r) where A = (gComgÿTlj=fy a® S yyg are random values ​​chosen by said accreditation management system (D-FI).

10. Device (D-FI) for managing accreditations comprising: - a module (M-CRY1) for generating (114) an anonymous verifiable accreditation (VC) relating to a plurality of attributes, one of which is an identifier (y) of this accreditation (VC); - a module (M-CRY1) for updating (110) a list (Yv) of accreditation identifiers accumulated in a cryptographic accumulator by adding or removing said identifier and the value ( V ) from the accumulator, said list being: (i) either a whitelist containing valid identifiers; (ii) a blacklist containing invalid identifiers; - a module (M-CRY1) for calculating (112) a witness (C) representative of: (i) the membership of said identifier (y) in a white list; or (ii) the non-membership of said identifier (y) on a blacklist and (iii) evidence (nc) associated with said witness (C); - a module (C0M1) for sending (118) to a user: (i) of said anonymous verifiable accreditation (VC); (ii) proof (Tîvaljd) of the validity of said anonymous verifiable accreditation (VC); (iii) said identifier (y) of said anonymous verifiable accreditation (VC); (iv) said witness (C) and the evidence ( ) associated with said witness.

11. Device (D-USR) comprising: - a reception module (COM3) (118), from an accreditation management device (D-FI): (i) at least one anonymous verifiable accreditation (VC) relating to a plurality of attributes, one of which is an identifier (j;) of this accreditation (VC); (ii) proof (nvcdid) of the validity of said anonymous verifiable accreditation (VC); (iii) the identifier (y) of said anonymous verifiable accreditation (VC); (iv) a witness of (C) the membership of said identifier (y) in a white list of valid identifiers or of the non-membership of said identifier (y) to a blacklist of invalid identifiers, said white or blacklist being a list (Yy) of elements accumulated in a cryptographic accumulator; (v) evidence (IIC) associated with said witness (C); - a module (WAL) for obtaining (U30) proof (nyC^) of non-revocation of the identifier (y) of said anonymous verifiable accreditation of interest (VC1} consisting of: (i) a proof (7Twb) that said identifier (y) of said anonymous verifiable accreditation of interest (VC1} belongs to said white list or by (ii) proof that said identifier (y) 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 on condition of obtaining proof (fj) of the validity of said accreditation (VC1) and of the non-revocation of said identifier (y).

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 VC1) relating to attributes of interest of the user and proof (riyOK) of non-revocation of an identifier (y) of said anonymous verifiable accreditation of interest (VC1}; - 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 (nvox) 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 (VC1) included in said verifiable presentation (VP), - a positive result of a verification (S40) of said at least one attribute and obtaining proof (n) of the validity of said accreditation (VC1) and of the non-revocation of said identifier being neces- necessary to authorize (S58) the user's (USR) access 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. A computer-readable recording medium on which a computer program (PG-USR, PG-FS, PG-FI) is recorded according to claim 13.

Images