Methods and devices allowing selective disclosure of a user's attributes

Abstract

The invention proposes a method, implemented by an identity provider, for generating an accreditation VC relating to at least one attribute of a user (U), the method being and including the following steps: - authenticating (18) the user (U); - obtaining (110) at least one cryptographic representation H i <sb / >of an attribute (αi) of the user; - obtaining (112) a signature σ Issuer calculated using a private key (SK I ) of the identity provider and relating at least to: (a) the at least one cryptographic representation H i ; and (b) a public key PK of the user (U); - calculating (114) a proof (Π l ) of the validity of an accreditation (VC) including at least: (i) the signature σ Issuer , (ii) a public key PK of the user (U); and (iii) the at least one cryptographic representation H i ; and - sending (118) the proof (Π l ) and the accreditation (VC) to the user.

Description

[0001]Description Title of the invention: Methods and devices for selectively disclosing a user's attributes Prior art The invention is in the field of digital identity management. More specifically, the invention relates to a method for managing digital identity that preserves the privacy of users, by allowing them to reveal to third parties only attributes, for example identity data, necessary for a specific use. Many service providers require the provision of attributes or identity elements of a user before delivering their service. Traditionally, in a non-digital world, these identity elements are produced by (physical) titles issued by official authorities (identity cards, driving licenses, etc.) or by supporting documents issued by recognized third-party certifiers (electricity bill, telecom bill, medical certificate, etc.).The development of services accessible via the Internet requires the implementation of dedicated tools allowing the digitization of the elements present on the aforementioned media, possibly in a structured manner and authorizing their sharing with the service provider, after the user's consent. The major prescribers on the Internet have until now structured the field of digital identity management in line with their business model. For example, through the OIDC (OpenID Connect) protocol, they have developed an offer that centralizes the user's identity elements and, under its control, after identification / authentication and consent of the user, authorizes the service's access to all or part of the user's identity elements.One of the main problems with this type of architecture, known as "Federated Identity", is that the identity provider knows, each time a user consumes one of the services, when the operation takes place and what identity elements the user shares with the service provider he is accessing. Figure 1 illustrates the known mechanism of federated identity: - A user U sends a request Rq_Id to an identity provider FI so that the latter certifies, after authentication of the user, one or more of his attributes - The user U sends a request Rq_AS to a service provider FS to access a service - The identity provider FI issues a token TOK to the user U - The user U transmits this tokenTOK to the service provider FS so that the latter authorizes him access to the service.Self-sovereign identity (SSI) is another approach to digital identity, which gives users full control over their identity elements: they can present them when accessing a service either to prove who they are or one of their qualities. Only the service provider and the user interact during the identity element sharing phase. In this logic, the user holds identity elements about themselves, which have been issued and certified by one or more trusted entities, for example by an identity provider through the use of digital signatures. In this digital identity model, a credential (in English Verifiable Credential, VC) is a personal attestation allowing its holder to convince a third party, for example a service provider, that they possess a particular authorization or qualification.Diplomas, student cards, and even driving licenses are all examples of classic accreditations used in everyday life. In order to generate trust between the user and the service, the user can present their identity elements certified by the identity provider (in which the service provider trusts) using a verifiable presentation (VP). Remember that a verifiable presentation is a combination of verifiable credentials, grouped in a format to be presented to the third party. Verifiable presentations are signed with the holder's cryptographic keys. In the self-sovereign identity approach, the user controls the dissemination of their identity elements to the service provider (after consent) and protects their privacy vis-à-vis the identity provider by excluding it from its relationship with the service provider, the protocol being completely asynchronous.However, standard digital signature mechanisms used by the identity provider require revealing the entire signed / certified data, even to prove the authenticity of only part of it. To protect privacy, it is desirable for a user to reveal to a service provider only the attributes or identity data strictly necessary for the requested service. This property is known as selective disclosure of identity data or attributes. Selective disclosure of attributes is easily achievable in the physical world. For example, information on an identity document can be masked using a black marker to leave only certain identity data visible. ISO / IEC 18013-5 explains how to transpose this manual redaction technique to digital identity documents.This ISO / IEC 18013-5 standard is more precisely an international standard relating to the design of a dematerialized mobile driving license (mDL), through a native application for mobile phones. It defines more specifically a data model that can be generalized to any other dematerialized identity document on mobile phones, as well as a protocol allowing the selective disclosure of identity data associated with this document. The operating principle of the selective disclosure method used in the ISO / IEC 18013-5 standard is now described. Issuance of an identity document in accordance with the ISO / IEC 18013-5 standard The identity provider has a private key pair (^^. ^ ) and public (^^ ^), a digital signature algorithm such as ECDSA (Elliptic Curve Digital Signature Algorithm). The user also has a pair of keys, private (^^) and public (^^), a digital signature algorithm, which he will use to authenticate his verifiable presentations VP and which he must first have certified by the identity provider at the same time as all the attributes (regal or not) relating to his driving license. We will note (^^, ^^, ^^, … , ^^) its attributes. During the issuance phase of a VC accreditation (or digital identity title), after having authenticated the user, the identity provider randomly chooses ^ public values, noted ^ ^ ^ ^ ^ ^ ^^ , then computes ^ digests (cryptographic hashes), one per attribute. Each of these ^ digests is labeled with a unique digest identifier denoted ^^^ ^ . The summary, noted ^ ^, of each attribute is calculated from its digest identifier (^^^ ^ ), of the attribute identifier (noted ^^ ^^ ), of the value of this attribute ( ^ ^ ) and the secret key generated and associated with this attribute when creating the credential: ^^ = ℋ(^^^^ ∥ ^^^^ ∥ ^^ ∥ ^^ ) denotes a cryptographic hash function (SHA-256 for example); the notation ^^^^ ∥ ^^^^ being used to denote the concatenation of character strings ^^^ ^ and ^^^ ^ . The identity provider then computes a digital signature, using its private key^^^ , on the data structure comprising the user's public key ^^ and the ^digests ^^. Let ^ = ^^ ∥ ^^ ∥ ^^ ∥ … ∥ ^^ and ^^ !"# = ^$%^&'((^) denote the identity provider's signature on ^. The identity provider then transmits the signature ^ ^ !"# and the keys ^ ^to the user. The user's VC credential (or digital identity title) (or mobile security element – ​​MSO in the terminology of the ISO / IEC 18013-5 standard) consists of his public key ^^, digests ^^ ^ ^ ^ ^ ^^ and the certificate ^ ^ !"# on this data: )* = ( ^^, ^^^^ ^^^^ , ^^ !"#). The secret data associated with this VC digital identity document are the user's private key ^^ and the randomly chosen secret keys ^^ ^ ^ ^ ^ ^^ . Verifiable presentation of a digital identity document with selective disclosure in accordance with ISO / IEC 18013-5 In the following, we will designate by + the list of indices of the attributes requested by the service provider. For example, = ^1, 5, 7^ means that the service provider wants the user to reveal the attributes ^ ^, ^0, and ^1. The user connects anonymously to the service provider's site. The service provider sends the user the conditions for accessing its site (i.e., the list of required attributes) as well as a random value (nonce) specific to this session to avoid replays of verifiable presentations. The user calculates, using his private key ^^, a signature (^ 2 "# ), relating to a set of data, called “DeviceAuthenticationBytes” in the ISO / IEC 18013-5 standard and noted 3 456 in the following. The DeviceAuthenticationBytes includes the nonce (or any other equivalent element, specific to the current session with the service provider, and allowing to avoid replays of verifiable presentation), possibly all the data revealed to the service provider as well as other contextual data: ^ 2 "# = ^$%^ &' (3 456 ). The verifiable presentation )^ consists of the public key ^^ ^of the identity provider, of the user's public key ^^, of the digests ^^^^ ^ ^ ^^ ,of the set of data disclosed to the service provider ( ,7^ 89: "7 = ;^^^^ ∥ ^^^^ ∥ ^^ ∥ ^^<^∈, ), and The user transmits the verifiable presentation )^ to the service provider. The service provider first calculates ^′^ = ℋ(^^^^ ∥ ^^^^ ∥ ^^ ∥ ^^)for each $ ∈ ,. It then verifies that: 1) ^′^ = ^^ for each $ ∈ , ;2) ^^ !"# is a valid signature on ^ = ^^ ∥ ^^ ∥ ^^ ∥ … ∥ ^^ using the public key ^^ ^ of the identity provider; 3) ^ 2 "# is a valid signature out of 3 456 (which the service provider can reconstruct) using the public key ^^ certified by the identity provider. If (and only if) these three conditions are met, the service provider grants access to its service to the user. Note 1: the signature ^ ^ !"#allows to authenticate all identity data revealed by the user (^ ^ ^ ^ ^∈, )) as well as the public key ^^. The signature ^ 2 "# , for its part, allows the service provider to be convinced that this verifiable presentation does indeed come from the holder of the accreditation )* = ( ^^, ^^^^ ^^^^ , ^^ !"#) and that it is therefore not a duplication of a previous verifiable presentation. Note 2: public keys ^ ^ , included in the calculations of the condensates ^ ^ , are intended to prevent exhaustive search attacks against attributes that are not disclosed. Without these keys, brute force attacks would easily succeed against attributes with low entropy, such as those relating to the user's "date of birth" or the "ID serial number". Indeed, if had been calculated in the following way: = ℋ(^^^^ ∥ ^^^^ ∥ ^^), without the key ^^, it would be very simple to find the attribute "date of birth" (^ ^ ) by testing all possible values ​​(^′ ^ ) until obtaining the correct one, that is to say the one which would verify the equality ^^ = ℋ(^^^^ ∥ ^^^^ ∥ ^′^) (the data ^^^^ and^^ ^^ being public data accessible to all). Disadvantages of the ISO / IEC 18013-5 standard The scheme presented above proposed by the ISO / IEC 18013-5 standard has several disadvantages. In particular: i / from the point of view of the protection of personal data, because the user is traceable by the service provider (but also by the identity provider). Indeed, all verifiable presentations of this user will systematically contain the signature ^ ^ !"#and the public key ^^, which is an indication that they were produced by a single user. Worse still, if the service provider and the identity provider cross-reference their information, they will certainly be able to identify the user who originated a verifiable presentation because the identity provider knows to whom it gave the signature ^ ^ !"# and will therefore be able, in the presence of a verifiable presentation, to identify its author. ii / the user's private key ^^, which will be used to authenticate their verifiable presentations through the signature ^ 2 "#is an extremely sensitive key that must therefore be properly protected; indeed, the compromise of this key would put the user at risk of having their identity stolen. The ISO / IEC 18013-5 standard recommends that this key be stored in a "secure hardware element with the appropriate certifications". However, such devices (Secure Element or SE) have limited computing power, and do not support all the mathematical operations implemented by certain classic digital signature algorithms (in particular those, such as BBS+, involving bilinear couplings in the generation of a signature and / or the verification of a signature). This constraint severely limits the type of digital signature algorithms that can be implemented to issue signatures ^ 2 "# and / or verify signatures ^ ^ !"#. The invention presentation aims at a solution allowing a selective disclosure of anonymous accreditation attributes which does not have the aforementioned drawbacks. Purpose and summary of the invention Thus, and according to a first aspect, the present disclosure relates to a method for generating an accreditation )* relating to at least one attribute of a user, the method being implemented by an identity provider and comprising the following steps: - authentication of the user; - obtaining at least one cryptographic representation ^ ^ of a user attribute; - obtaining a signature ^ ^ !"# calculated using a private key of said identity provider and relating at least to: (a) said at least one cryptographic representation; and to (b) a public key ^^ of the user; - calculation of a proof of validity Π A of an accreditation)* comprising at least: (i) the said signature ^ ^ !"#, (ii) a public key ^^ of the user; (iii) said at least one cryptographic representation ^ ^ ; and - sending said proof to said user Π A and said accreditation )*. Correlatively, the present disclosure relates to a device for generating an accreditation )* relating to at least one attribute of a user, the device comprising: - a user authentication module; - a module for obtaining at least one cryptographic representation ^ ^ of a user attribute; - a module for obtaining a signature ^ ^ !"# calculated using a private key of said identity provider and relating at least to: (a) said at least one cryptographic representation; and to (b) a public key ^^ of the user; - a module for calculating a proof Π A of the validity of an accreditation)* comprising at least: (i) the said signature ^ ^ !"#, (ii) a public key ^^ of the user; (iii) said at least one cryptographic representation ^ ^; and - a module for sending said proof and accreditation to said user)*. Thus, and generally speaking, the present disclosure concerns three entities: 1. at least one identity provider which provides users, after having authenticated them, with anonymous accreditations (hereinafter accreditations) relating to one or more of its attributes. As detailed below, in one embodiment, the identity provider uses the BBS+ protocol to certify the attributes of users. 2. at least one service provider which verifies certain attributes of a user before delivering the service to them and being certain that their attributes are certified. In other words, the service provider verifies that the attributes of a user meet the conditions for access to its services. 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 will therefore have to provide proof of his majority through a verifiable presentation generated from an accreditation, certifying his age, issued by an identity provider in which the service provider has confidence. (3) at least one user having a set of accreditations allowing him to prove his identity or at least some of his attributes (majority, seniority, diplomas, etc.) to a service provider in order to access its services, by revealing only the attributes required for access to the service. In one embodiment, said signature complies with the BBS+ protocol described in the document “The BBS Signature Scheme, published 31 January 2024: The BBS Signature Scheme (identity.foundation)”. In one embodiment, said at least one cryptographic representation is a digest obtained by a hash function. In one embodiment, this digest complies with ISO / IEC 18013-5:2021.Indeed, the present disclosure is perfectly compatible with the data and disclosure model defined in this standard. A VC accreditation within the meaning of the present disclosure is for example a digital identity document or a mobile security element – ​​MSO in the terminology of the ISO / IEC 18013-5 standard. Very advantageously, by implementing the present disclosure, the user only reveals to the service provider the attributes strictly necessary for access to the service concerned. According to a second aspect, the present disclosure relates to a method implemented by a user's device, to request access to a service provided by a service provider, said method comprising the following steps: - authentication of the user with an identity provider; - reception from the identity provider, of an accreditation )* and of a proof Π. Aof the validity of the accreditation )*, said accreditation )* comprising at least: (i) a cryptographic representation ^ ^ of an attribute of the user (ii) a public key ^^ of the user; and (iii) a signature ^ ^ !"# calculated using a private key of said identity provider and relating to at least: (a) said at least one cryptographic representation ^ ^ and (b) said public key ^^ of the user, - verification of said proof Π A ; - receiving a list of at least one attribute to be revealed to said service provider to access said service; - calculating an anonymized public key PK DEFGH of the user from said public key ^^and an anonymized signature ^ ^ 69^ ! ^ " 7 # from signature ^ ^ !"# ; - calculation of a proof ^2 69^ " ^ # 7knowledge of an anonymized private key of the user associated with said anonymized public key PK DEFGH - sending to the service provider a verifiable presentation with selective disclosure comprising at least: (aa) a public key of the identity provider, (bb) the anonymized public key PK DEFGH of the user, (cc) at least one attribute to be revealed to access said service, (dd) a cryptographic representation ^ ^ said at least one attribute to be revealed, (ee) said anonymized signature σ D HAS J E I FG K H L M and (ff) said proof ^2 69^ " ^ # 7. Correlatively, the present disclosure relates to a device for requesting access to a service provided by a service provider, said device comprising: - a module for authenticating a user of said device with an identity provider; - a module for obtaining, from said identity provider, an accreditation )* and proof Π A of the validity of this accreditation )*, this accreditation )* comprising at least: (i) a cryptographic representation ^ ^ of an attribute of the user (ii) a public key ^^ of the user; and (iii) a signature ^ ^ !"# calculated using a private key of said identity provider and relating to at least: (a) said at least one cryptographic representation ^ ^ and (b) said user's public key, - a verification module of said proof Π A; - a module for receiving a list of at least one attribute to be revealed to said service provider in order to access said service - means for calculating an anonymized public key PK DEFGH of the user from said public key and calculation of an anonymized signature from the signature ^ ^ !"# ; - means of calculating a proof ^2 69^ " ^ # 7 knowledge of a user's private key associated with said anonymized public key PK DEFGH - a module for sending, to said service provider, a verifiable presentation with selective disclosure comprising at least: (aa) a public key of the identity provider, (bb) the anonymized public key PK DEFGH of the user, (cc) at least one attribute to be revealed to access said service, (dd) a cryptographic representation ^ ^ said at least one attribute to be revealed, (ee) said anonymized signature σ D HAS J E IFG K H L M and (ff) said evidence Very advantageously, thanks to the use of an anonymized public key and an anonymized signature, the invention makes it possible to guarantee that neither the service provider nor the identity provider, alone or jointly, can trace the user in the uses of his accreditations. According to a third aspect, the invention 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 with selective disclosure comprising at least: (aa) a public key of an identity provider, (bb) an anonymized public key PK DEFGH of the user obtained from a public key ^^ of the user, (cc) at least one attribute of the user to be revealed to access said service, (dd) a cryptographic representation of said at least one attribute to be revealed, (ee) an anonymized signature σ D HAS J E I FG K H L M obtained from a signature ^ ^ !"# issued by said service provider and relating to at least: (a) at least one cryptographic representation of a user attribute and (b) an anonymized public key ^^ 69^^7 of the user, and (ff) a proof ^2 69^ " ^ # 7 of the user's knowledge of an anonymized private key associated with said anonymized public key PK DEFGH ; - calculation of a cryptographic representation ^′ ^ of said required attribute; - verification: (i) of the cryptographic representation ^′ ^ of the required attribute; (ii) of said proof ^2 69^ " ^ # 7 of the user's knowledge of said anonymized private key and (iii) of said anonymized signature σ D HAS JE I FG K H L M using the public key of said identity provider (IF); - a positive result of said verification being a necessary condition for authorizing the user's access to said service. Correlatively, the present disclosure relates to a device for controlling access to a service by a user, said device comprising: - a module for obtaining a verifiable presentation with selective disclosure comprising at least: (aa) a public key of an identity provider, (bb) an anonymized public key PK DEFGH of the user obtained from a public key ^^ of the user, (cc) at least one attribute of the user to be revealed to access said service, (dd) a cryptographic representation ^ ^ of said at least one attribute to be revealed, (ee) an anonymized signature σ D HAS J E I FG K H L M obtained from a signature ^ ^ !"#issued by said service provider and relating to at least: (a) at least one cryptographic representation ^ ^ of a user attribute and (b) an anonymized public key ^^ 69^^7 of the user, and (ff) a proof ^2 69^ " ^ # 7 of the user's knowledge of an anonymized private key associated with said anonymized public key PK DEFGH ; - a module for calculating a cryptographic representation ^′ ^ of said required attribute (a F ); - a module (M-CRY2) for verification (S44, S440): (i) of the cryptographic representation ^′ ^ of the required attribute (ii) of said evidence ^2 69^ " ^ # 7 of the user's knowledge of said anonymized private key and (iii) of said anonymized signature σ D HAS J E I FG K H L Musing the public key of said identity provider; - a module configured to authorize the user's access to said service at least if said verification is positive. In one embodiment, the user obtains from the identity provider a proof O PQ of the validity of said anonymized signature σ DA J E I FG K H L M , and the verifiable selective disclosure presentation sent to the service provider by the user includes this proof of validity O PQ . In this embodiment, and as described in detail below, the verification of the anonymized signature by the service provider includes verification of this proof of validity O PQ. This embodiment of the invention is advantageously compatible with the federated identity mechanisms described with reference to Figure 1, and in particular that in the mode of the ISO / IEC 18013-5 standard, in which the user, after having authenticated himself with the service provider, receives from the latter a token attesting that he verifies the conditions of access to the services of this provider. In one embodiment, the access request method comprises: - the calculation, by a secure element of the user terminal, of a proof ^ of the knowledge of a private key of the user; - said proofs and σ D R E I F L G M Hbeing calculated jointly by this secure element (and an application of said terminal. This embodiment described in detail below is very advantageous when the secure elements used in the terminals are limited to very predetermined tasks which prevent certain cryptographic calculations, for example anonymization tasks, or certain signature calculations. In this solution, the secure element has no bilinear coupling to perform and only a scalar multiplication on an elliptic curve to perform to generate the signature σ RJLM(compared to a linear number in n with the original version of BBS+ standardized at the ETF under the reference "The BBS Signature Scheme, published 31 January 2024: The BBS Signature Scheme (identity.foundation)"). For some versions of BBS+ (Jan Camenisch, Manu Drijvers, Anja Lehmann: Anonymous Attestation Using the Strong Diffie Hellman Assumption Revisited. IACR Cryptol. ePrint Arch. 2016: 663 (2016)), the user's secure device only has to perform a constant number of scalar multiplications on the elliptic curve to generate the signature σ RJLMbut must instead interact several times with the mobile application to calculate this signature. The invention also relates to a computer program comprising instructions for executing the steps of the method for generating at least one accreditation when said program is executed by a computer. The invention also relates to a computer program comprising instructions for executing the steps of the method for requesting access to a service when said program is executed by a computer. The invention also relates to a computer program comprising instructions for executing the steps of the method for controlling access to a service when said program is executed by a computer. These programs can use any programming language, and be in the form of source code, object code, or intermediate code between source code and object code, such as in a partially compiled form, or in any other desirable form.The invention also relates to a computer-readable information medium, and comprising instructions of a computer program as mentioned above. The information medium may be any entity or device capable of storing the program. For example, the medium may comprise a storage means, such as a ROM, a non-volatile memory of the flash type or even 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 invention may in particular be downloaded from a network such as the Internet. Alternatively, the information medium may be an integrated circuit in which the program is incorporated, the circuit being adapted to execute or to be used in the execution of the method in question.Brief description of the drawings: Other characteristics and advantages of the present invention will emerge from the description given below, with reference to the appended drawings which illustrate exemplary embodiments thereof without any limiting character. In the figures: [Fig. 1] Figure 1 already described represents the known mechanism of federated identity [Fig. 2] Figure 2 represents a system comprising an accreditation generation device, a device used by a user to request access to a service and a device for controlling access to a service in accordance with particular embodiments of the present disclosure; [Fig. 3] Figure 3 represents in the form of a flowchart steps of a method for generating an accreditation in accordance with a particular embodiment of the present disclosure; [Fig.4] Figure 4 represents in flowchart form steps of a method for requesting access to a service and of a method for controlling access to a service in accordance with a particular embodiment of the present disclosure; [Fig. 5] Figure 5 represents in flowchart form steps of a method for requesting access to a service and of a method for controlling access to a service in accordance with another particular embodiment of the present disclosure; [Fig. 6] Figure 6 represents in flowchart form a step of the method of Figure 5 in a particular embodiment of the present disclosure; [Fig. 7] Figure 7 represents the hardware architecture of the devices of Figure 1 in a particular embodiment of the present disclosure. As a preliminary, we recall cryptographic tools used in the present disclosure.Pledging schemes Pledging a value is a cryptographic process allowing an issuer to commit a value (a secret for example) to a recipient without revealing it at first glance and in such a way that this commitment can no longer be modified a posteriori. This value can be, if necessary, revealed subsequently by the issuer. Thus, the recipient has the assurance that once the commitment is published, the issuer can no longer change his mind about the value contained in this commitment. Figuratively, pledging consists of giving the recipient a closed safe containing the secret, and subsequently providing him with the combination to open it. In a particular embodiment, the present disclosure may use the pledging scheme proposed by Pedersen in 1992 (Torben P. Pedersen. Non-interactive and information-theoretic secure verifiable secret sharing.In Joan Feigenbaum, editor, CRYPTO'91, volume 576 of LNCS, pages 129–140. Springer, Heidelberg, August 1992), which has the particularity of producing perfectly indistinguishable commitments (perfectly hiding in English). Zero-Knowledge Proofs We recall that a so-called Zero-Knowledge Proof (ZKP in English), is an interactive protocol that allows a verifier to convince himself that a certain prover knows a secret ^ satisfying a given predicate ^, the proof revealing to the verifier no information about the secret S in question except the fact that it verifies the given predicate P. Subsequently, to represent zero-knowledge proofs, we will sometimes use the usual notation PoK^α, β, … : predicate on α, β, … ^ introduced by Camenisch and Stadler (Jan Camenisch, Markus Stadler: Efficient Group Signature Schemes for Large Groups (Extended Abstract).CRYPTO 1997: 410-424) where the Greek letters correspond to the secrets known to the prover. For example, PoK{b : c = %. d} will denote a proof of knowledge of the discrete logarithm of (the public value) c in the (public) base %. In a particular embodiment, non-interactive versions of so-called zero-knowledge proofs of knowledge (also called "knowledge signatures") are used, obtained by heuristic transformations such as that due to Fiat-Shamir (Amos Fiat, Adi Shamir: How to Prove Yourself: Practical Solutions to Identification and Signature Problems. CRYPTO 1986: 186-194). More precisely, a "knowledge signature" is a non-interactive protocol allowing a prover on the one hand to convince a third party that he knows a secret ^ following a predicate ^ and on the other hand to guarantee that he is the author of a message m by ensuring the integrity of the latter.We denote such a knowledge signature of secret values ​​(b, e, f, …) verifying a given predicate and authenticating a message 3 as follows: SoK{ b, e, f, …: predicate on b, e, f, …}(3) where the Greek letters correspond to the secrets known by the prover and 3 to the authenticated message. For example, SoK{b: c = %. d}(3) will denote a knowledge signature of the discrete logarithm of (the public value) c in the (public) base % authenticating the message 3. A knowledge signature on a message 3 has the same characteristics as a digital signature: it guarantees both its authenticity and its integrity. Description of embodiments We will use in the following notation PoΚ(b^, b^,…, b^ ∶ ℛ(b^, b^,…, b^)) to denote a zero-knowledge proof of knowledge (ZKPK) of elements b ^ , b ^ ,…, b ^satisfying the relation ℛ. Thus a proof of knowledge of the two prime factors of a public RSA module (Rivest-Shamir-Adleman algorithm) j would be noted: PoΚ(b^, b^ ∶ j = b^ ∙ b^ ⋀ ( b^ ≠ 1) ⋀ ( b^ ≠ 1) ). Similarly, we will use in the following notation SoΚ(b^, b^,…, b^ ∶ ℛ(b^, b^,…, b^))(3) to denote a knowledge signature (ZKPK) of elements , b^ ,…, b^ satisfying the relation ℛ and authenticating the message 3. n o will denote the set {0, 1, 2,…, p-1}, where p is a prime integer and n o ∗ the set {1, 2,…, p-1}. The implementation of cryptographic mechanisms of the present disclosure uses bilinear pairings. We recall that a bilinear pairing, denoted e, is a definite mapping on a set r^ × r^ to a set rt where r^ , r^ and rt denote cyclic groups of order p, p being a prime number. This mapping u verifies the following properties: 1. (Bilinearity) 2. (Non-degenerate) For %^ ≠ 1{| and %^ ≠ 1{}, u(%^, %^) ≠ 1{~.3. (Computable) ∀ %^ ∈ r^ , ∀ %^ ∈ r^, there exists an efficient algorithm to compute u(%^, %^).In practice, the groups r ^ , r ^ and r t will be chosen such that there is no efficiently computable isomorphism between r ^ and r ^ . Such pairings are known to those skilled in the art as Type 3 pairings. The security of some cryptographic mechanisms used in this disclosure relies in part on the assumption that the problems below are difficult. In other words, if an attacker is able to defeat the security of these mechanisms, it is because he is also able to solve these problems, which are nevertheless considered "difficult". q-SDH problem: Let r be a cyclic group of prime order p and an element ^ ∈ n o . Given (%, %^ , %^} , %^ ^ , … , %^^ ), the q-strong Diffie-Hellman (q-SDH) problem consists of computing a pair of the form (%^^ ^^8 , ^) ∈ r × no.In a particular embodiment of the invention, the Pedersen pledge scheme is used (Torben P. Pedersen: Non-Interactive and Information-Theoretic Secure Verifiable Secret Sharing. CRYPTO 1991: 129-140). In this scheme, r is considered a cyclic group of prime order p and % and ℎ two arbitrary generators of r . It is assumed that the discrete logarithm of ℎ in base % is unknown. To commit to the message 3 ∈ n oof its choice, a sender chooses a random value ∈ n , calculates ^ #o le * = % ℎ and sends it to the recipient. If necessary (opening phase), the sender can reveal to the recipient the values ​​3 and ^ so that the latter checks the equality: * = %^ℎ#. Figure 2 represents a system SYS comprising a D-FI device for generating anonymous accreditation implemented by an identity provider FI, a D-FS device for controlling access to a service implemented by a service provider FS and a D-USR device implemented by a user U to request access to said service. To simplify the description, the D-FI device for managing anonymous accreditation will sometimes be called "D-FI device of the identity provider FI". Similarly, the D-FS device for controlling access to a service will sometimes be called "D-FS device for providing a service". Similarly, the D-USR device for requesting access to a service will sometimes be called "D-USR user device".Similarly, instead of saying "device DX" 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 anonymous accreditation management device D-FI and the user U can designate the service access request device D-USR. The anonymous accreditation management device D-FI has a pair of public keys (^^^ , ^^′^) and an associated private key (^^^). The user's device D-USR has a pair of public and private keys (^^, ^^) to enable its authentication with the identity provider FI. In the embodiment described here, these keys are stored in a secure element SE. The credential generation device D-FI is configured to, after having authenticated a user U, obtain at least one cryptographic representation ^. ^ of an attribute ^ ^ from the user and get a signature ^^ !"# calculated using the private key ^^ ^ of said identity provider and relating to at least (a) said at least one cryptographic representation ^ ^ ; and on (b) a public key ^^ of the user (^). The D-FI device then sends to the user U an accreditation )* comprising at least (i) said signature ^ ^ !"# , (ii) a public key ^^ of the user (^); and (iii) said at least one cryptographic representation ^ ^. 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 generating an accreditation. In the embodiment described, the user's D-USR device U comprises a secure element for storing cryptographic data, for example a secret private key, a WAL cryptographic module, for example an electronic identity wallet configured to store at least one anonymous verifiable accreditation )* issued by an identity provider FI, to generate an anonymized signature, for example the signature to generate a verifiable presentation to be presented to the service provider FS to access a service while protecting the confidentiality of its attributes. In one embodiment, the secure element SE is configured to calculate a proof ^ of knowledge of a private key of the user. In the embodiment described here, the device D-FI for generating an anonymous verifiable accreditation comprises a communication module COM1. This module can in particular be used by the device D-FI to communicate with the user D-USR for the purpose of their authentication and to send them an accreditation )*. In the embodiment described here, the device D-FI comprises a cryptographic module M-CRY1. This module can in particular be used to authenticate a user, calculate digests, signatures and proofs.In the embodiment described here, the D-FS device for controlling access to a service by a user comprises an M-LS module for determining which attributes of a user must be verified before authorizing them to access a service, verifying whether the attributes obtained actually satisfy the logic of the service and, if necessary, authorizing access to the service after having verified at least one proof of the validity of an accreditation of the certification of these attributes. In the embodiment described here, the D-FS device comprises a COM2 communication module. This module can in particular be used by the device to request attributes from the user, obtain these attributes or information enabling it to obtain these attributes, and obtain a verifiable presentation comprising an accreditation on attributes of a user, sending a message to the user to inform them of an authorization of access or of the refusal of access to a service.In the embodiment described here, the D-FS device comprises a cryptographic module M-CRY2 configured in particular to calculate digests, verify proofs and signatures. Figure 2 represents in the form of a flowchart the main steps of a method for issuing a verifiable accreditation implemented by the identity provider FI. During a step I2, the identity provider FI defines the public parameters of the signature system: pp = (r^,r^, rt , u, p, ^, %, %^, %^, %^, .. , %^, %^, ^) where: - where r^,r^, rt are three cyclic groups of order p and u a bilinear coupling of r^^r^ in r. t, for which we will assume that the q-SDH problem is difficult. - p is a prime integer that denotes the order of the group r - ^ the number of attributes to be certified -%, %^, %^, %^, .. , %^, %^ denote ^+3 generators of the group r chosen randomly (so that no one knows the discrete logarithm of one of these generators with respect to another of these generators). Each ^ % ^ ^ ^ ^ ^^ is associated with a specific attribute type (e.g. % ^ will be associated with the attribute “name”, % ^ to the “first name” attribute, % ^ to the “age” attribute, % ^ to the attribute "gender", etc.). This will allow us to differentiate the attributes and avoid any ambiguity. - ^ denotes a generator of r ^. The ^+3 generators of the group r are chosen randomly such that no one knows the discrete logarithm of one of these generators with respect to another of these generators. In the embodiment described here, each ^% ^ ^ ^ ^ ^^ is associated with a specific attribute type (e.g. % ^ will be associated with the attribute “name”, % ^ to the “first name” attribute, % ^ to the “age” attribute, % ^ to the "gender" attribute, etc.). In the following, all calculations relating to the exponents will be carried out modulo p (mod p). During a step I4, the identity provider FI defines the public data specific to the type of accreditation (for example, the digital identity document). In the embodiment described here, this public data includes: - a public key ^ ^ for each of the ^ types of attributes, either ^ ^ ^ ^ ^ ^ ^^, these public keys being intended to be used for all VC accreditations issued by the identity provider FI; - an integer ^^ randomly drawn from n o , - a digest identifier ^^^ ^ for each of the ^ types of attributes, that is ^^^^ ^ ^ ^ ^ ^^ , and - an identifier ^^ ^^ for each of the attribute types, either . During a step I6, the identity provider FI generates a private key ^^ ^ and an associated public key (^^^ , ^^′^). In the embodiment described here, the private key ^^^ belongs to ^1, 2, … , et la clé associated public is the pair (^^^ , ^^′^) with ^^ ^^ = %^ ( and ^^′ ^ ^ = ^ (.In the embodiment described here, the identity provider FI also generates a zero-knowledge proof Π = PoK ^b: ^^ = %^d ∧ ^^ d^ ′^ = ^ ^ that its key pair (^^^ , ^^′^) has been generated. We now assume that the identity provider FI wishes to generate a credential )* for the attributes (^^, ^^, ^^, … , ^^) of a user ^. We denote (^^, ^^ = % ^) a private / public key pair of this user. In the embodiment described here, the private key ^^ is stored in the secure element SE. During a step I8, the identity provider FI sends a challenge (message) ^ℎ to the user ^. The user ^ generates a proof O ! =SoK{b: ^^ = % d}(^ℎ) of knowledge of his private key authenticating the challenge ^ℎ. In the embodiment described here, the proof π Ris calculated using the algorithm called ECSchnorr (Claus-Peter Schnorr: Efficient Identification and Signatures for Smart Cards (Abstract). EUROCRYPT 1989: 688-689). Other algorithms can be used, for example, the ECDSA algorithm (ANSI X9.62-1998, Public Key Cryptography For The Financial Services Industry: The Elliptic Curve Digital Signature Algorithm (ECDSA)). The user ^ sends the identity provider FI his public key PK and the proof O ! . In the embodiment described here, if the identity provider FI does not authenticate the user U based on this information, the result of a test I9 is ​​negative and the method stops. If the authentication succeeds, during a step I10, the identity provider FI calculates, using a function cryptographic hash, a cryptographic representation ^ ^ in n o for each of the attributes ^ ^. In the embodiment described herein, this cryptographic representation is a hash calculated by a function that is for example compliant with the SHA-256 protocol. In the embodiment described herein, the cryptographic representation ^ ^ of an attribute ^ ^ is more precisely calculated from the digest ID ^^^ ^ , from the attribute identifier ^^ ^^ , of the value of this attribute ^ ^ and the public key ^ ^ associated with the type of this attribute when creating the credential: This representation complies with ISO / IEC 18013-5. Other representations may be used in other embodiments of this disclosure. During a step I12, the identity provider FI calculates a digital signature ^ ^ !"# using his private key ^^ ^ , on a data structure ^ including the user's public key ^^ and the ^ digests ^ ^. He saves this signature ^ ^ !"# . ^= ^^ ∥ ^^ ∥ ^^ ∥ … ∥ ^^In the embodiment described here, the signature scheme used complies with the BBS+ protocol. u is a value chosen randomly from By setting = therefore ^ ^( = ^^^".We designate For more information on this BBS+ protocol, the person skilled in the art can refer to the standard itself (https: / / identity.foundation / bbs-signature / draft-irtf-cfrg-bbs- signatures.html) or to the document “Barki, A., Brunet, S., Desmoulins, N., and J. Traore, "Improved Algebraic MACs and Practical Keyed-Verification Anonymous Credentials", In International Conference on Selected Areas in Cryptography, 1016,<https: / / link.springer.com / chapter / 10.1007 / 978-3-319-69453-5_20> . During a step I14, the identity provider FI generates a proof Π ^with zero knowledge disclosure to prove that he knows b such that * = ^d ∧ ^^^ = %^d.Π^ = PoK ^b: * = ^d ∧ ^^^ = %^d^ In the embodiment described here, the VC accreditation is constituted (step I16) by the user's public key ^^, the digests and the signature ^ ^ !"# on this data: )* = ( ^^, ^^^^ ^^^^ , ^^ !"# = (^, u)).The secret data associated with this VC accreditation is the private key ^^ of the user ^. During a step I18, the identity provider FI sends the accreditation )* and the proof Π ^ to user ^. During a step U20, user ^ calculates = , * = ^^ ^" and checks the validity of the proof Π ^ . If the proof is validated, the user ^ stores in his WAL digital identity wallet, the VC accreditation relating in particular to his attributes ^ ^ ^ ^ ^ ^ ^^and on his public key ^^. In one embodiment, the user knows his attributes and it is not necessary for the identity provider to return them to him. Alternatively, the identity provider returns them to the user to allow the latter to verify that the identity provider and he share the same information (i.e., verify, for example, that the identity provider has not misspelled his last name). Figure 4 represents in the form of a flowchart the main steps of a method for requesting access to a service implemented by the user U and the main steps of an access control method implemented by the service provider FS. In accordance with the present disclosure, the user U uses for this purpose a verifiable presentation VP generated from one or more accreditations VC by at least one identity provider FI.For simplicity, we assume that the verifiable presentation VP only has a VC accreditation. We will denote by +, the list of indices of the attributes ^^. ^ ^ ^∈,requested by the service provider FS. We will assume in this example that the verification of the conditions of access to the service relates to three attributes ^^, ^0, ^1 and therefore that , = ^1, 5, 7^. In the embodiment described here, for each attribute not belonging to ,, the user ^ will send the value ^^ to the service provider FS. During a step U20, the user U connects anonymously to the service provider FS. During a step S22, the service provider sends to the user U the list + of attributes that he must verify to grant access to his service and a random value (nonce) specific to the session to avoid replays of verifiable presentations. In a preferred embodiment, this request is authenticated, in other words signed by the service provider FS. During a step U24, the user calculates an anonymized public key PK DEFGHfrom his public key ^^ = % ^ so that neither the service provider FS nor the identity provider FI can trace him from his public key. For this purpose, the user ^ randomly chooses an integer r from Z ¤ and calculates a stake committed to the Pedersen of his private key sk: PKDEFGH = gJ ^M. During a step U26, the user ^ calculates an anonymized signature ^ ^ 69^ ! ^ " 7 # from signature ^ ^ !"# of its VC accreditation, to also prevent the service provider FS or the identity provider FI from being able to trace it from this signature element, and “adapt” it so that it relates to the anonymized public key PK DEFGH and the ^H F ^ G F ^^ (and not on PK and ^H attribute digests F ^ G F ^^ . To this end, in the embodiment described here, the user ^ chooses integers r^, r^ ∈Z ¤ ∗then calculates: ^̈ = ^#|×#} ^ = ^#} ^© = ^^̈"^#|=^̈ ^( This proof Π ¬^9^7^­® is known to those skilled in the art (see for example Stefan Brands: Rapid Demonstration of Linear Relations Connected by Boolean Operators. EUROCRYPT 1997: 318-333) and will not be detailed in this document. It follows from the following two equalities: ^© = ^^̈"^#| ; and During a step U38, the user ^ calculates using a random number r and his private key sk, a knowledge signature σ RJLM relating to a set of data, called “DeviceAuthenticationBytes” in the ISO / IEC 18013-5 standard and noted m ·¸Din the following: σRJLM = SoK^α: PKDEFGH = g¹^(m·¸D)In the ISO / IEC 18013 standard, the DeviceAuthenticationBytes includes the nonce (or any other equivalent element, specific to the current session with the service provider FS and allowing to avoid replays of the verifiable presentation VP, possibly all the data revealed to the service provider as well as other contextual data). The signature σ RJLM is a knowledge signature of the discrete logarithm of PK DEFGHin the base g. In a particular embodiment, the ECSchnorr algorithm is used for this signature. Any other algorithm for proving knowledge of the private key ^^ can also be implemented, in particular the ECDSA algorithm in the context of self-sovereign identity mechanisms SSI. In an embodiment of the present disclosure, the secure element SE may not be able to:- anonymize itself (step U24) its public key (for example calculate PKDEFGH = gJ ^M) and / or;- anonymize itself (step U26) its private key (for example calculate ^^69^^7 = ^^ +^ (3ª« p)); and / or - calculate itself (step U38) the proof of knowledge of the anonymized private key^^ + ^ (3ª« p), i.e. a signature ^2 69^ " ^ # 7 of knowledge of the discrete logarithm of ^^ 69^^7in the % base. We explain below how the SE secure element and the WAL mobile application associated with this SE can jointly anonymize the public key PK DEFGH and calculate the signature σ RJLM . It is recalled that in the embodiment described here, only the secure element SE knows the private key sk associated with the user's public key PK. We will assume that the secure element SE supports the classic digital signature algorithm ECSchnorr, also called ECSDSA in the ISO / IEC 14888-3 standard. The calculation of the signature ^ 69^^72 "# = SoK^α: PKDEFGH = g¹^(m·¸D) could be performed in the following manner: a / the secure element SE calculates a knowledge signature (denoted σ) of the discrete logarithm of PK in the base g (i.e. of the private key. sk): σ = SoK^α: PK = g¹^(m·¸D). In one embodiment, the ECSDSA algorithm can be implemented in the following way for the calculation of this signature: the secure element SE: i / generates a random number ωii / calculates T = g½, c = ℋ(T ∥ m·¸D) andiii / calculates ρ = ω + c sk (mod p) denotes a cryptographic hash function (SHA-256 for example). The signature σ is made up of the pair (c, ρ): σ = (c, ρ).It is valid if c¿ = ℋ(gÀ x ^^^8 , m·¸D) = c and invalid otherwise. b / the WAL application: i / chooses a hazard rii / calculates PK MJ ^MDEFGH = g × PK = g, andiii / calculates ρDEFGH = ρ + c × r = ω + c × sk + c × r = ω + c × (sk + r) (mod p). The signature = (c, ρDEFGH) is a valid ECSDSA signature on m·¸D relative to the public key PKDEFGH . In this embodiment, the secure element SE calculates the proof ^ of knowledge of the user's private key, the proofs and σ D R E I F L G M H being calculated jointly by said secure element SE by the WAL application of said terminal. Thus, the secure element SE performs simple operations (no bilinear coupling to be performed and only a scalar multiplication on an elliptic curve to be performed) while the signature is calculated by the dedicated WAL mobile application on your mobile phone. The verifiable presentation )^ ^ selective disclosure consists (step U40) of the public key of the identity provider FI, the anonymized public key PK DEFGH of the user, of the ^^^^ ^ F ∉, , of all data disclosed to the service provider FS (, HFJÄEÅJLH=;HIDF ∥ IDÈ ∥ aF ∥ KF <F∈,), des représentations cryptographiques ^^^∈,, et des signaturesσ D HAS J E I FG K H L M and ^2 69^ " ^ # 7 . User transmits verifiable presentation )^ ^ to the service provider FS during a step U42. During a step S44, the service provider FS calculates H′F = ℋ(HIDF ∥ IDÈÉ ∥ aF ∥KF) for each i ∈ ,. It then checks that: i / H′F = HF for each i ∈ , ;ii / ^2 69^ " ^ # 7 is a valid signature on m ·¸D , in other words the service provider FS can reconstruct it using the public key PK DEFGH certified by the FI identity provider. The ECSchnorr algorithm for verifying this SoK (SoK^α: PK DEFGH = g ¹ ^(m ·¸D)) being known to those skilled in the art, we will not detail it in this document. iii / is a valid signature on PKDEFGH, ^HF^F∈, and ^H′F = ^^^F∉,, using the public key of the FI. To do this, it must first ensure that the following equality is satisfied e(A Ì , PK ¿ A ) = e(B Í , f) and on the other hand that Π ÏÈEFHFÐÑ is valid. The verification algorithm for this proof Π ÏÈEFHFÐÑ is known to those skilled in the art. If all these conditions are verified, it is demonstrated that the requested attributes ^a F ^ F∈, have been certified by the identity provider FI and that the verifiable presentation VP comes from the user ^ whose attributes are the requested attributes ^a F ^ F∈,. The service provider FS allows the user ^ to access its service (step S46). If at least one of the conditions is not verified, the provider FS refuses access to its service (step S48). The mechanism presented above is very advantageous because neither the service provider FS nor the identity provider FI can trace the user ^. Furthermore, the selective disclosure method complies with that described in the ISO / IEC 18013-5 standard, but the latter has the disadvantage, in the event of collusion between the service provider FS and the identity provider FI, of tracing the uses of their common clients. In the embodiment described previously, the user ^ does not need to be connected to be able to generate a verifiable presentation VP. Similarly, the service provider FS does not need to be connected to be able to and verify a verifiable presentation VP, respectively.This mode, which can in this sense be described as offline (HL), corresponds to a VP verification mode proposed in particular by the ISO / IEC 18013-5 standard. The ISO / IEC 18013-5 standard provides a second mode, which can be described as "semi-offline mode" or "synchronous" mode. This mode, which requires that at least one of the two actors be connected, is similar to the federated identity model described with reference to Figure 1. In the SHL mode of the ISO / IEC 18013-5 standard, and as in the synchronous mode of the federated identity described with reference to Figure 1, the user ^ receives a token from the identity provider attesting that he verifies the access conditions to the service provider FS. As previously stated, the problem of federated identity poses a major drawback in that the identity provider knows with which service providers U uses its tokens and can thus trace its usage.We will now describe a particular embodiment of the present disclosure compatible with the SHL mode of the ISO / IEC 18013-5 standard but in which the identity provider FI is not able to identify with which service provider FS a user ^ uses his tokens. We place ourselves in the situation in which the user ^ has received an accreditation )* =(^, u) from the service provider as described with reference to figure 3. With reference to figure 5, the user ^ calculates an anonymized key PK. DEFGH from public key ^^ = % ^ and an anonymized value ^^ 69^ ! ^ " 7 # of the signature ^ ^ !"#of his VC accreditation. These steps are similar to steps U24 and U26 described with reference to Figure 4. During a step U28, the user ^ tries to obtain from the identity provider FI, by contacting him directly, a proof (SoK) OPQ that BÍ =Ì AJ ¡ where AÌ = AM|×M}. In a particular embodiment this proof is obtained blindly, which means that the identity provider FI, although having contributed to generating this proof (only he knows sk A ), will be unable in the presence of such proof π ÒÓ to determine which user it was intended for. In one embodiment, and as described below with reference to Figure 6, this proof O PQcan be obtained using the Chaum-Pedersen blind signature protocol (David Chaum, Torben P. Pedersen: Wallet Databases with Observers. CRYPTO 1992: 89-105). In a step U38 similar to the step U38 already described with reference to Figure 4, the user ^ calculates using a random number r and his private key sk, a knowledge signature ^2 69^ " ^ # 7 relating to a set of data m ·¸D . ^ 69^^7 2 "# = SoK^α: PKDEFGH = g¹^(m·¸D)The verifiable presentation )^ &^ consists (step U400) of the public key of the identity provider FI, the anonymized public key PK DEFGH of the user, of of all data disclosed to the service provider FS (, HFJÄEÅJLH =;HIDF ∥ IDÈ ∥ aF ∥ KF <F∈,), des représentations cryptographiques ^^^∈,, des signaturesσ D HAS J E I FG K H L M and ^2 69^ "^ # 7 and proof O PQ . σ DEFGH AJJKLM , ^ ^ ^ Ê ^ $ u ^ ^ « , O PQ ). The user transmits the verifiable presentation VP to the service provider FS during a step U420. During a step S440, the service provider FS calculates H′F = ℋ(HIDF ∥ IDÈÉ ∥ aF ∥KF) for each i ∈ ,. It then verifies that: i / H′F = HF for each i ∈ , ; ii / σ RJLM is a valid signature on m ·¸D iii / is a valid signature on PKDEFGH, ^HF^F∈, and ^H′F = ^^^F∉,, using the public key of the FI. To do this, it must first ensure that the proof Π ÒÓ is valid and that the proof Π ÏÈEFHFÐÑis valid. If all these conditions are verified, the service provider FS allows the user ^ to access its service (step S46). If at least one of the conditions is not verified, the provider FS refuses access to its service (step S48). This solution has the advantage of not requiring bilinear couplings, which makes it much more efficient than those implementing these cryptographic tools. Its security is also based on mathematical problems commonly considered more difficult by the scientific community. Figure 6 represents, in the form of a flowchart, a protocol implemented between the user ^ and the identity provider FI by which the identity provider FI can provide proof to the user ^ a proof (SoK) OPQ that BÍ =Ì AJ ¡ where AÌ = AM|×M}. In other words, this figure details step U28 of Figure 5 in a particular embodiment of the present disclosure.We recall that the identity provider FI knows the signature ^^ !"# = (^, u) calculated in step I12 on the public key ^^ and the attributes ^. ^ of user ^. In a step I50 similar to step I8, the identity provider FI sends a challenge (message) ^ℎ to user ^. User ^ generates a proof O ! =SoK{b: ^^ = % d}(^ℎ) of knowledge of his private key authenticating the challenge ^ℎ, for example using the algorithm called ECSchnorr or ECDSA. The user ^ sends to the identity provider FI his public key PK and the proof O ! . In the embodiment described here, if the identity provider FI does not authenticate the user U based on this information, the result of a test I51 is negative and the method stops. If the authentication succeeds, during a step I52, the identity provider FI calculates a cryptographic representation ^ ^ in n o for each of the attributes ^^ of the user ^. This step is similar to step I10. We denote C = AJ ¡ = BA^L. During a step I54, the identity provider FI chooses a value ^ randomly in no∗ and calculates ^^ = %^ and calculates ^^ = ^ . The identity provider FI sends the values ​​^ ^ and ^ ^ to user ^ (step I56). During a step U58, user ^ chooses two values ​​Õ, Ö randomly from no∗ and calculates: ^^ = ^ / Õ (mod p)The user sends the value ^ ^ to the identity provider FI during a step U60. During a step I62, the identity provider FI calculates ^^ = ^ + ^^ × ^^^ (3ª« p) and sends the value ^^ = ^ + ^^ × ^^^ (3ª« p) to the user ^. During a step U64, the user ^ calculates: ^= ( ^^ + Ö)Õ (mod p) The proof πÒÓ is equal to: πÒÓ = xAÌ, BÍ, c, rz. This is a valid proof (SoK) on the message m ·¸D if : Each of the D-USR, D-FI and D-FS devices described above can be implemented by an ORD computer whose hardware architecture is shown in Figure 7. This ORD computer comprises in particular a processor 10, a random access memory 11, a read-only memory 12 and communication means 13. The read-only memory 12 constitutes a recording medium within the meaning of the invention. It comprises a PG-X computer program in accordance with the invention. For the D-USR device, this PG-X computer program is a PG-USR program comprising instructions for executing the steps of a method for requesting access to a service as described above with reference to Figures 2 and 3. The PG-USR program defines in particular the M-AUTH modules for authentication, WAL obtaining of an accreditation, WAL calculation of keys and signatures, and COM-3 communication of the D-USR device.For the D-FI device, this PG-X computer program is a PG-FI program comprising instructions for executing the steps of an accreditation generation method as described previously with reference to Figures 2 and 3. The PG-FI program defines in particular the M-CRY1 module for authentication, calculation of digests, signatures, and obtaining accreditations, and the COM1 module of the D-FI device. 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 Figures 2 and 3. The PG-FS program defines in particular the M-CRY2 module for calculating digests, proofs and signatures, and the COM2 module for communication of the D-FS device.

Claims

CLAIMS

1. Method for generating an accreditation )* relating to at least one attribute of a user (^), the method being implemented by an identity provider (FI) and comprising the following steps: - authentication (I8) of said user (^); - obtaining (I10) at least one cryptographic representation ^ ^ of an attribute (^ ^ ) of the user; - obtaining (I12) a signature ^ ^ !"# calculated using a private key (^^ ^ ) of said identity provider and relating at least to: (a) said at least one cryptographic representation ^ ^ ; and on (b) a public key ^^ of the user (^); - calculation (I14) of a proof (Π A ) of the validity of an accreditation ()*) comprising at least: (i) the said signature ^ ^ !"# , (ii) a public key ^^ of the user (^); and (iii) said at least one cryptographic representation ^ ^; and - sending (I18) to said user of said proof (Π A ) and said accreditation ()*).

2. Generation method according to claim 1 wherein: - said signature complies with the BBS+ protocol; and - said at least one cryptographic representation is a digest compliant with the ISO / IEC 18013-5 standard.

3. Access request method, implemented by a device of a user (^), to request access to a service provided by a service provider (FS), said method comprising the following steps: - authentication (I8) of the user (^) with an identity provider (FI); - reception (I18), from said identity provider (FI), of an accreditation )* and of a proof Π A of the validity of the accreditation )*, said accreditation )* comprising at least: (i) a cryptographic representation ^ ^ of an attribute (^ ^) of the user; (ii) a public key ^^ of the user (^); and (iii) a signature ^ ^ !"# calculated using a private key (^^ ^ ) of said identity provider and relating at least to: (a) said at least one cryptographic representation ^ ^ and (b) said public key (^^) of the user (^), - verification of said proof Π A ; - reception (S22) of a list (+) of at least one attribute to be revealed to said service provider (FS) to access said service - calculation (U24, U26) of an anonymized public key PK DEFGH of the user (^) from said public key ^^ and an anonymized signature ^^ 69^ ! ^ " 7 # from signature ^ ^ !"# ; - calculation (U38) of a proof ^2 69^ " ^ # 7 knowledge of an anonymized private key of the user associated with said anonymized public key PK DEFGH- sending (U42, U420), to said service provider (SP), a verifiable presentation with selective disclosure comprising at least: (aa) a public key of the identity provider (IF), (bb) the anonymized public key PK DEFGH of the user, (cc) at least one attribute to reveal (a F ) to access said service, (dd) a cryptographic representation ^ ^ of said at least one attribute to be revealed (a F ) (ee) said anonymized signature and (ff) said proof ^2 69^ " ^ # 7 .

4. Access request method according to claim 3, further comprising a step (U28) of obtaining proof (O PQ ) of the validity of said anonymized signature σ D HAS J E I FG K H L M provided by said identity provider (IF), said verifiable presentation with selective disclosure further comprising said proof of validity (OPQ ).

5. Access request method according to claim 3 or 4 comprising: - the calculation, by a secure element (SE) of the user terminal, of a proof ^ of the knowledge of a private key of the user; - said proofs and σ D R E I F L G M H being calculated jointly by said secure element (SE) and an application (WAL) of said terminal.

6. Method for controlling access to a service by a user (^), said method being implemented by a service provider (FS) and comprising the steps following: - obtaining (U42, U420) a verifiable presentation with selective disclosure comprising at least: (aa) a public key of an identity provider (FI), (bb) an anonymized public key PK DEFGH of the user obtained from a public key ^^ of the user, (cc) at least one attribute (a F) of the user to reveal to access said service, (dd) a cryptographic representation ^ ^ of said at least one attribute to be revealed (a F ), (ee) an anonymized signature σ D HAS J E I FG K H L M obtained from a signature ^ ^ !"# issued by said service provider and relating to at least: (a) at least one cryptographic representation ^ ^ of an attribute (^ ^ ) of the user and (b) an anonymized public key ^^ 69^^7 of the user (^), and (ff) a proof ^2 69^ " ^ # 7 of the user's knowledge of an anonymized private key associated with said anonymized public key PK DEFGH ; - calculation (S44, S440) of a cryptographic representation ^′ ^ of said required attribute (a F ); - verification (S44, S440): (i) of the cryptographic representation ^′ ^of the required attribute (ii) of said evidence ^2 69^ " ^ # 7 of the user's knowledge of said anonymized private key and (iii) of said anonymized signature σ D HAS J E I FG K H L M using the public key of said identity provider (FI); - a positive result of said verification (S44, S440) being a necessary condition for authorizing (S46) the access of the user (^) to said service.

7. Access control method according to claim 6 wherein said verifiable presentation ()^ ^&Â ) with selective disclosure further includes evidence of the validity of said anonymized signature σ D HAS J E I FG K H L M calculated by said service provider (FI), the verification of said anonymized signature σ D HAS J E I FG K H LM including the verification of said evidence (O PQ ).

8. Device (D-FI) for generating an accreditation )* relating to at least one attribute of a user (^), this device comprising: - a module (M-CRY1) for authenticating said user (^); - a module (M-CRY1) for obtaining at least one cryptographic representation ^ ^ of an attribute (^ ^ ) of the user; - a module (M-CRY1) for obtaining a signature ^ ^ !"# calculated using a private key (^^ ^ ) of said identity provider and relating at least to: (a) said at least one cryptographic representation ^ ^ ; and on (b) a public key ^^ of the user (^); - a module (M-CRY1) for calculating (I14) a proof Π A of the validity of an accreditation ()*) comprising at least: (i) the said signature ^ ^ !"#, (ii) a public key ^^ of the user (^); and (iii) said at least one cryptographic representation ^ ^ ; and - a module (COM1) for sending said proof Π to said user A and accreditation ()*).

9. Device (D-USR) for requesting access to a service provided by a service provider (FS), said device comprising: - a module (M-AUTH) for authenticating a user (^) of said device (D-USR) with an identity provider (FI); - a module (COM3) for obtaining, from said identity provider (FI), an accreditation )* and a proof Π A of the validity of said accreditation )*, said accreditation )* comprising at least: (i) a cryptographic representation ^ ^ of an attribute (^ ^ ) of the user (ii) a public key ^^ of the user (^); and (iii) a signature ^ ^ !"# calculated using a private key (^^ ^) of said identity provider and relating at least to: (a) said at least one cryptographic representation ^ ^ and (b) said public key (^^) of the user (^), - a module (WAL) for verifying said proof Π A ; - a module (COM3) for receiving a list (+) of at least one attribute to be revealed to said service provider (FS) to access said service - means (WAL) for calculating an anonymized public key PK DEFGH of the user (^) from said public key ^^ and calculation of an anonymized signature ^^ 69^ ! ^ " 7 # from signature ^ ^ !"# ; - means (SE) for calculating a proof ^2 69^ " ^ # 7 knowledge of an anonymized private key of the user associated with said anonymized public key PK DEFGH - a module (COM3) for sending, to said service provider (FS), a verifiable presentation with selective disclosure comprising at least: (aa) a public key of the identity provider (FI), (bb) the anonymized public key PK DEFGH of the user, (cc) at least one attribute to reveal (a F ) to access said service, (dd) a cryptographic representation ^ ^ of said at least one attribute to be revealed (a F ), (ee) said anonymized signature and (ff) said proof σ RJLM .

10. Device (D-FS) for controlling access to a service by a user (^), said device comprising: - a module (COM2) for obtaining a verifiable presentation with selective disclosure comprising at least: (aa) a public key of an identity provider (FI), (bb) an anonymized public key PK DEFGH of the user obtained from a public key ^^ of the user, (cc) at least one attribute (a F) of the user to reveal to access said service, (dd) a cryptographic representation ^ ^ of said at least one attribute to be revealed (a F ), (ee) an anonymized signature σ D HAS J E I FG K H L M obtained from a signature ^ ^ !"# issued by said service provider and relating to at least: (a) at least one cryptographic representation ^ ^ of an attribute (^ ^ ) of the user and (b) an anonymized public key ^^ 69^^7 of the user (^), and (ff) a proof ^2 69^ " ^ # 7 of the user's knowledge of an anonymized private key associated with said anonymized public key PK DEFGH ; - a module (M-CRY2) for calculating a cryptographic representation ^′ ^ of said required attribute (a F ); - a module (M-CRY2) for verification (S44, S440): (i) of the cryptographic representation ^′ ^of the required attribute (ii) of said evidence ^2 69^ " ^ # 7 of the user's knowledge of said anonymized private key and (iii) of said anonymized signature σ D HAS J E I FG K H L M using the public key of said Identity Provider (IF); - a module (COM2) configured to authorize (S46) the user's (U) access to said service at least if said verification (S44, S440) is positive.

11. 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 for generating an accreditation according to any one of claims 1 or 2; or - a method for requesting access to a service according to claim 3 to 5; or - a method for controlling access to a service according to claim 6 or 7.

12. Recording medium readable by a computer on which a computer program according to claim 11 is recorded.

Images