Methods and devices for requesting access to a service provided by a service provider

Abstract

The invention relates to a method for requesting access to a service provided by a service provider, the method comprising the following steps: - receiving (118), from an identity provider, an accreditation VC and a proof n of the validity of the accreditation VC; - verifying the proof ∏I; - receiving (S22) a list of attributes to be revealed to the service provider in order to access the service; - calculating (U24, U26) an anonymised public key PKBlind of the user, an anonymised signature (formula I) and a proof (U38) (formula I) of knowledge of an anonymised private key of the user associated with the anonymised public key PKBlind on the basis of a proof of knowledge a of a private key of the user, wherein the proofs σ, (formula I) and (formula I) are jointly calculated by a secure element and an application of a user terminal; - sending (U42, U420), to the service provider, a verifiable presentation with selective disclosure.

Description

[0001]Description Title of the invention: Methods and devices for requesting access to a service provided by a service provider. Prior art The invention lies in the field of digital identity management. More specifically, the invention relates to a method for managing digital identity that preserves user privacy by allowing them to reveal to third parties only the attributes, for example, identity data, necessary for a specific use. Many service providers require the provision of a user's identity attributes or elements before delivering their service. Traditionally, in a non-digital world, these identity elements are produced by (physical) documents issued by official authorities (identity cards, driver's licenses, etc.) or by supporting documents issued by recognized third-party certifiers (electricity bill, telecom bill, medical certificate, etc.).The development of internet-accessible services requires the implementation of dedicated tools that enable the digitization of elements present on the aforementioned media, potentially in a structured manner, and allow their sharing with the service provider, after user consent. Major internet providers have thus far structured the field of digital identity management according to their business model. For example, through the OIDC (OpenID Connect) protocol, they have developed a service that centralizes user identity information and, under their control, after user identification / authentication and consent, authorizes service access to all or part of the user's identity information.One of the main problems with this type of architecture, known as "Federated Identity," lies in the fact that the identity provider knows, each time a user consumes a service, when the operation takes place and which identity elements the user shares with the service provider they are accessing. Figure 1 illustrates the known mechanism of federated identity: - A user U sends an Rq_Id request to an identity provider (FI) so that the FI can certify, after user authentication, one or more of their attributes. - User U sends an Rq_AS request to a service provider (FS) to access a service. - The identity provider (FI) issues a token (TOK) to user U. - User U transmits this token (TOK) to the service provider (FS) so that the latter can authorize access to the service.Self-sovereign identity (SSI) is another approach to digital identity, giving users complete control over their identity elements: they can present them to access a service to prove who they are or one of their qualifications. Only the service provider and the user interact during the identity element sharing phase. In this model, the user possesses identity elements about themselves, which have been issued and certified by one or more trusted entities, such as an identity provider using digital signatures. In this digital identity model, a Verifiable Credential (VC) is a personal attestation that allows its holder to convince a third party, such as a service provider, that they possess a specific authorization or qualification.Diplomas, student ID cards, and driver's licenses are all examples of standard credentials used in everyday life. To build trust between the user and the service, the user can present their identity information, certified by the identity provider (whom the service provider trusts), using a Verifiable Presentation (VP). A verifiable presentation is a combination of verifiable credentials, grouped into a format for presentation to the third party. Verifiable presentations are signed with the holder's cryptographic keys. In the self-sovereign identity approach, the user controls the sharing of their identity information with the service provider (after giving their consent) and protects their privacy from the identity provider by excluding them from the relationship with the service provider, as the protocol is completely asynchronous.However, the standard digital signature mechanisms used by identity providers require the disclosure of all signed / certified data, even to prove the authenticity of only a portion of it. To protect their privacy, users should only reveal to a service provider 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 implemented in the physical world. For example, information on an identity document can be redacted with a black marker to reveal only certain identity data. The ISO / IEC 18013-5 standard explains how to adapt 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 digital mobile driver's license (mDL), via a native mobile phone application. It defines, in particular, a data model generalizable to any other digital identity document on a mobile phone, 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 private key pair (^^^^) and a public key pair (^^^^), and a digital signature algorithm, which they will use to authenticate their verifiable VP presentations and which they must first have certified by the identity provider along with all the attributes (regulatory or otherwise) related to their driver's license. We will denote (^^1, ^^2, ^^3, … , ^^^^) these attributes. During the issuance phase of a VC accreditation (or digital identity document), after authenticating the user, the identity provider randomly chooses ^^ public values, denoted { ^^ ^^ } ^ ^ ^ = ^ 1. Then, calculates ^^ 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 during the creation of the identity document:^^^^ = ℋ(^^^^^^^^ ∥ ^^^^^^^ ∥ ^^^^ ∥ ^^^^) where ℋ denotes a cryptographic hash function (SHA-256 for example); the notation ^^^^^^1 ∥ ^^^^^^2 is used to denote the concatenation of the strings ^^^^^^1 and ^^^^^^2. The identity provider then calculates a digital signature, using its private key ^^^^ ^^, on the data structure comprising the user's public key ^^^^ and the ^^hashes ^^^^. Let ^^ = ^^^^ ∥ ^^1 ∥ ^^2 ∥ … ∥ ^^^^ and ^^^^^^^^^^^^^^^ = ^^^^^^^^^^^^^^^(^^) the identity provider's signature on ^^. The identity provider then transmits the signature ^^^^^^^^^^^^^^^ and the keys ^^ ^^ to the user. The user's VC accreditation (or digital identity credential) (or Mobile Security Element – ​​MSO in the terminology of the ISO / IEC 18013-5 standard) consists of their public key ^^^^, hashes 1 and the certificate ^^^^^^^^^^^^^^ on this data:^^^^ = ( ^^^^, {^^^^} ^^^^=1 , ^^^^^^^^^^^^^^^). The secret data associated with this VC digital identity title are the user's private key ^^^^ and the randomly chosen secret keys Verifiable presentation of a digital identity document with selective disclosure according to ISO / IEC 18013-5: We will hereafter refer to the list of attribute indices requested by the service provider as ^^. For example, ^^ = {1, 5, 7} means that the service provider wants the user to disclose the attributes ^^1, ^^5, and ^^7. The user connects anonymously to the service provider's website. The service provider sends the user the access conditions to its site (i.e., the list ^^ of required attributes) as well as a random value (nonce) specific to this session to prevent replays of verifiable presentations. The user calculates, using their private key ^^^^, a signature (^^ ^^^^^^^^ ), relating to a set of data, called "DeviceAuthenticationBytes" in the ISO / IEC 18013-5 standard and denoted ^^ ^^^^^^in the following. The DeviceAuthenticationBytes includes the nonce (or any other equivalent element, specific to the current session with the service provider, and allowing for the prevention of verifiable presentation replays), possibly all the data disclosed to the service provider, as well as other contextual data: ^^ ^^^^^^^^ = ^^^^^^^^ ^^^^ (^^ ^^^^^^ The verifiable presentation ^^^^ consists of the public key ^^^^ ^^ of the identity provider, of the public key ^^^^ of the user, of the digests { ^^ ^^ } ^ ^ ^ = ^ 1, of all the data disclosed to the service provider (^^^^^^^^^^^^^^^^^^^^ = {^^^^^^^^ ∥ ^^^^^^^^ ∥ ^^^^ ∥ and signatures^^^^ = (^^^^^^ , 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 ^^ ∥ ^^2 ∥ … ∥ ^^^^ using the public key ^^^^ ^^ from the identity provider; 3) ^^ ^^^^^^^^ is a valid signature on ^^ ^^^^^^ (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 the user access to its service. Note 1: The signature allows for the authentication of all identity data disclosed by the user ( { ^^ ^^ } ^^∈^^ )) as well as the public key ^^^^. The signature ^^ ^^^^^^^^Meanwhile, it allows you to convince the service provider that this verifiable presentation does indeed originate from the accreditation holder ^^^^ = ( ^^^^, {^^^^} ^^^^=1 , ^^^^^^^^^^^^^^^) and that it is therefore not a re-release of a previous verifiable presentation. Note 2: Public keys ^^ ^^ included in the calculations of the condensates ^^ ^^ These keys aim to prevent exhaustive search attacks against undisclosed attributes. Without them, brute-force attacks would easily succeed against low-entropy attributes, such as the user's "date of birth" or "ID serial number." Indeed, if ^^ ^^ had been calculated as follows: ^^^^ = ∥ ^^^^^^^^ ∥ ^^^^), without the key ^^^^, it would be very simple to find the "date of birth" attribute (^^ ^^ ) by testing all possible values ​​(^^′ ^^) until we get the right one, that is, the one that would verify the equality ^^^^ = ∥ ^^^^^^^^ ∥ ^^′^^) (the data ^^^^^^ ^^ and ^^^ ^^^^(being public data accessible to all). Disadvantages of the ISO / IEC 18013-5 standard. The schema 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 one and the same 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 to identify its author in the presence of a verifiable presentation.ii / the user's private key ^^^^, which will be used to authenticate their verifiable presentations through the signature ^^. ^^^^^^^^ is an extremely sensitive key that must therefore be properly protected; indeed, compromising this key would put the user at risk of identity theft. 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 Elements or SEs) have limited computing power and do not support all the mathematical operations implemented by some classic digital signature algorithms (particularly those, like BBS+, involving bilinear coupling in signature generation and / or signature verification). This constraint severely limits the types of digital signature algorithms that can be used to issue signatures. ^^^^^^^^and / or verify signatures. The invention presentation aims at a solution enabling the selective disclosure of anonymous credential attributes that does not present the aforementioned drawbacks. Object and summary of the invention: Thus, and according to a first aspect, the present disclosure concerns a method for generating a credential covering at least one attribute of a user, the method being implemented by an identity provider and comprising the following steps: - user authentication; - 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 (b) a public key of the user; - calculation of a proof of validity of an accreditation ^^^^ comprising at least: (i) said signature ^^^^^^^^^^^^^^, (ii) a public key ^^^^ of the user; (iii) said at least one cryptographic representation ^^ ^^ ; and - sending said proof to the user I and said accreditation. Correspondingly, this disclosure concerns a device for generating accreditation on 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 (b) a public key of the user; - a module for calculating a proof Π Iof the validity of an accreditation ^^^^ comprising at least: (i) 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 the user. Thus, and generally speaking, this disclosure concerns three entities: 1. at least one identity provider that provides users, after authenticating them, with anonymous credentials (hereinafter referred to as credentials) covering one or more of their attributes. As detailed below, in one embodiment, the identity provider uses the BBS+ protocol to certify users' attributes. 2. at least one service provider that verifies certain attributes of a user before delivering the service and ensures that their attributes are certified. In other words, the service provider verifies that a user's attributes meet the conditions for accessing 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 must therefore provide proof of their age through a verifiable presentation generated from an accreditation, certifying their age, issued by an identity provider trusted by the service provider. 3. At least one user possessing a set of accreditations enabling them to prove their identity or at least some of their attributes (age, seniority, qualifications, etc.) to a service provider in order to access its services, revealing only the attributes required for service access. In one embodiment, said signature conforms to 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 conforms to the ISO / IEC 18013-5:2021 standard.Indeed, this disclosure is fully compatible with the data and disclosure model defined in this standard. A VC credential, as defined in this disclosure, is, for example, a digital identity credential or a mobile security element (MSO) in the terminology of ISO / IEC 18013-5. Very advantageously, by implementing this disclosure, the user reveals to the service provider only the attributes strictly necessary for accessing the service in question. Secondly, this disclosure concerns a process implemented by a user's device to request access to a service provided by a service provider. This process comprises the following steps: - authentication of the user with an identity provider; - receipt from the identity provider of a credential and proof. Iof the validity of the accreditation, said accreditation comprising at least: (i) a cryptographic representation ^^ of a user attribute (ii) a user public key; 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 Π I - Receiving a list of at least one attribute to reveal to the service provider in order to access the service; - Calculating an anonymized public key (PK) Blind from the user using said public key ^^^^and an anonymized signature ^^ ^ ^ ^ ^ ^ ^ ^ ^ ^^ ^ ^ ^ ^ ^ ^ ^ ^ ^ ^ ^ ^ based on the signature ^^^^^^^^^^^^^^ and proof ^^^ ^ ^ ^ ^ ^ ^ ^^ ^ ^ ^ ^ ^ ^ ^ ^^ knowledge of an anonymized private key of the user associated with said anonymized public key PK Blind based on a proof of knowledge σ of a user's private key, said proofs σ, σ B I s l s in u d e r and σ B U l s i e n r d being calculated jointly by a secure element of a user terminal and an application of said terminal; - sending to the service provider a verifiable, selectively disclosed presentation containing at least: (aa) a public key of the identity provider, (bb) the anonymized public key PK Blind of the user, (cc) at least one attribute to reveal to access said service, (dd) a cryptographic representation ^^ ^^said at least one attribute to be revealed, (ee) said anonymized signature σ B I s l s in u d e r and (ff) said proof ^^ ^ ^ ^ ^ ^ ^^ ^ ^ ^ ^ ^ ^ ^ ^ ^ ^^ Correspondingly, this disclosure concerns 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, accreditation and proof of identity. I of the validity of this accreditation, this accreditation comprising at least: (i) a cryptographic representation ^^of a user attribute (ii) a user's public key; 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 user public key, - a verification module for said proof Π I - a module for receiving a list of at least one attribute to be revealed to the service provider in order to access the service; - means for calculating an anonymized public key (PK). Blind from the user's public key, to calculate an anonymized signature ^^ ^ ^ ^ ^ ^ ^ ^ ^ ^ ^ ^ ^ ^^ ^ ^ ^ ^ ^ ^ ^ ^ from the signature ^^^^^^^^^^^^^^^ and the means of calculating a proof ^^ ^ ^ ^ ^ ^ ^ ^ ^^ ^ ^ ^^ ^ ^ ^ ^^ knowledge of an anonymized private key of the user associated with said anonymized public key PK Blind based on proof of knowledge σ of a user's private key; - a sending module, auditing the service provider, of a verifiable, selectively disclosed presentation containing at least: (aa) a public key of the identity provider, (bb) the anonymized public key PK Blind of the user, (cc) at least one attribute to reveal to access said service, (dd) a cryptographic representation ^^ ^^ said at least one attribute to be revealed, (ee) said anonymized signature and (ff) said proof ^^ ^ ^ ^ ^ ^ ^^ ^ ^ ^ ^ ^ ^ ^ ^ ^ ^^Advantageously, through the use of an anonymized public key and an anonymized signature, the invention ensures that neither the service provider nor the identity provider, individually or jointly, can trace the user's use of their credentials. According to a third aspect, the invention relates to a method for controlling a user's access to a service, said method being implemented by a service provider and comprising the following steps: - obtaining a verifiable, selectively disclosed presentation comprising at least: (aa) a public key of an identity provider, (bb) an anonymized public key PK Blind of the user obtained from a public key ^^^^ of the user, (cc) at least one attribute of the user to reveal to access said service, (dd) a cryptographic representation ^^ ^^ said at least one attribute to be revealed, (ee) an anonymized signature σ B Is l s in u d e r obtained from a signature issued by said service provider and relating at least to: (a) at least one cryptographic representation ^^ of a user attribute and (b) an anonymized public key of the user, and (ff) a proof the user's knowledge of an anonymized private key associated with said anonymized public key PK Blind ; - calculation of a cryptographic representation ^^′ ^^ said required attribute; - verification: (i) of the cryptographic representation ^^′ ^^ of the required attribute; (ii) of said proof ^^ ^ ^ ^ ^ ^ ^ ^ ^^ ^ ^ ^ ^ ^ ^ ^ ^^ (iii) the user's knowledge of said anonymized private key and (iii) of said anonymized signature σ B I s l s in u de r 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. Correspondingly, this disclosure concerns a device for controlling user access to a service, said device comprising: - a module for obtaining a verifiable presentation with selective disclosure comprising at least: (aa) an identity provider's public key, (bb) an anonymized public key PK Blind of the user obtained from a public key ^^^^ of the user, (cc) at least one attribute of the user to reveal to access said service, (dd) a cryptographic representation ^^ ^^ said at least one attribute to be revealed, (ee) an anonymized signature σ B I s l s in u d e robtained from a signature issued by said service provider and relating at least to: (a) at least one cryptographic representation of a user attribute and (b) an anonymized public key of the user, and (ff) a proof ^ ^ ^ ^ ^ ^ ^ ^^ ^ ^ ^ ^ ^ ^ ^ ^^ the user's knowledge of an anonymized private key associated with said anonymized public key PK Blind - a module for calculating a cryptographic representation ^^′ ^^ said required attribute (a i ); - a verification module (M-CRY2) (S44, S440): (i) of the cryptographic representation ^^′ ^^ of the required attribute (ii) of said proof (iii) the user's knowledge of said anonymized private key and (iii) of said anonymized signature σ B I s l s in u d er using the public key of said identity provider; - a module configured to allow the user access to said service at least if said verification is positive. In one embodiment, the user obtains proof from the identity provider. ^^^^ of the validity of said anonymized signature σ BI s l s in u d e r and the verifiable, selectively disclosed presentation sent to the service provider by the user includes this proof of validity ^^ ^^^^ In this embodiment, and as described in detail below, the verification of the anonymized signature σ B I s l s in u d e r by the service provider includes verification of this proof of validity ^^ ^^^^This embodiment of the invention is advantageously compatible with the federated identity mechanisms described with reference to Figure 1, and in particular with the one in the ISO / IEC 18013-5 standard, in which the user, after authenticating with the service provider, receives from the latter a token attesting that they have met the conditions for accessing the provider's services. In one embodiment, the access request process comprises: - the calculation, by a secure element of the user terminal, of a proof of knowledge of a private key of the user; - said proofs B I s l s in u d e r and σ B U l s i e n r dbeing 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 terminals are limited to very predetermined tasks that 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 σ User(as opposed 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 needs to perform a constant number of elliptic curve scalar multiplications to generate the σ signature UserHowever, it must interact with the mobile application several times to calculate this signature. The invention also relates to a computer program comprising instructions for executing the steps of the process for generating at least one credential when said program is executed by a computer. The invention also relates to a computer program comprising instructions for executing the steps of the process 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 process 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 code intermediate between source 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 carrier containing instructions for a computer program as described above. The information carrier can be any entity or device capable of storing the program. For example, the carrier can include a storage means, such as a ROM, non-volatile flash memory, or a magnetic recording means, such as a hard drive. Alternatively, the information carrier can be a transmissible medium, such as an electrical or optical signal, which can be transmitted via an electrical or optical cable, by radio, or by other means. The program according to the invention can, in particular, be uploaded to a network such as the Internet. Alternatively, the information carrier can 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 process in question.Brief description of the drawings: Other features and advantages of the present invention will become apparent from the description given below, with reference to the accompanying drawings which illustrate non-limiting examples of embodiments. In the figures: [Fig. 1] Figure 1, already described, represents the known federated identity mechanism; [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 service access control device, in accordance with particular embodiments of this disclosure; [Fig. 3] Figure 3 represents, in flowchart form, the steps of a method for generating an accreditation in accordance with a particular embodiment of this disclosure; [Fig.[Fig. 4] Figure 4 presents a flowchart of the steps in a service access request process and a service access control process, in accordance with one particular embodiment of this disclosure; [Fig. 5] Figure 5 presents a flowchart of the steps in a service access request process and a service access control process, in accordance with another particular embodiment of this disclosure; [Fig. 6] Figure 6 presents a flowchart of one step in the process of Figure 5 in one particular embodiment of this disclosure; [Fig. 7] Figure 7 represents the hardware architecture of the devices in Figure 1 in one particular embodiment of this disclosure. As a preliminary matter, we will review the cryptographic tools used in this disclosure.Pledging Schemes. Pledging a security is a cryptographic process allowing an issuer to pledge a security (a secret, for example) to a recipient without initially disclosing it, and in such a way that this pledge cannot be modified later. This security can be disclosed subsequently by the issuer if necessary. Thus, the recipient is assured that once the pledge is published, the issuer cannot change their mind about the security contained within it. Figuratively speaking, pledging involves giving the recipient a locked box containing the secret and later providing them with the combination to open it. In a particular embodiment, this 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). Zero-Knowledge Proofs. Recall that a zero-knowledge proof (ZKP) is an interactive protocol that allows a verifier to convince themselves 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 other than the fact that it does indeed verify the given predicate ^^. Subsequently, to represent proofs with zero disclosure of knowledge, 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 by the prover. For example, PoK{^^ : ^^ = ^^. ^^} will denote a proof of knowledge of the discrete logarithm of (the public value) ^^ 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 through 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 they know a secret ^^ according to a predicate ^^ and, on the other hand, to guarantee that they are the author of a message m by ensuring the integrity of the latter.We denote such a signature of knowledge of secret values ​​(^^, ^^, ^^, …) verifying a given predicate and authenticating a message ^^ as follows: SoK{ ^^, ^^, ^^, …: predicate on ^^, ^^, ^^, …}(^^) where the Greek letters correspond to the secrets known by the prover and ^^ to the authenticated message. For example, SoK{^^: ^^ = ^^. ^^}(^^) will denote a knowledge signature of the discrete logarithm of (the public value) ^^ in the (public) database ^^ authenticating the message ^^. A knowledge signature on a message ^^ has the same characteristics as a digital signature: it guarantees both its authenticity and integrity. Description of embodiments We will subsequently use the following notation PoK(^^1, ^^2,…, ^^^^ ∶ ^^(^^1, ^^2,…, ^^^^)) to denote a zero-knowledge proof (ZKPK) ^^2,…, ^^ ^^satisfying relation R. Thus, a proof of knowledge of the two prime factors of a public RSA module (Rivest-Shamir-Adleman algorithm) would be denoted: Similarly, we will subsequently use the following notation SoK(^^1, ^^2,…, ^^^^ ∶ ^^(^^1, ^^2,…, ^^^^))(^^) to denote a knowledge signature (ZKPK) of elements ^^1, ^^2,…, ^^ ^^ satisfying relation R and authenticating the message ^^. ^^ ^^ will denote the set {0, 1, 2,…, ^^-1}, where ^^ is a prime integer and ^^ ^ ∗ ^ the set {1, 2,…, ^^-1}. The implementation of cryptographic mechanisms in this disclosure uses bilinear couplings. Recall that a bilinear coupling, denoted e, is a map defined on a set ^^1 × ^^2 to a set ^^^^ where ^^1, ^^2 and ^^^^ denote cyclic groups of order ^^, ^^ being a prime number. This map ^^ satisfies the following properties: 1. (Bilinearity) 2. (Non-degenerate) For ^^1 ≠ 1^^1 and ^^2 ≠ 1^^2, ^^(^^1, ^^2) ≠ 1^^^^3. (Computable) ∀ ^^1 ∈ ^^1, ∀ ^^2 ∈ ^^2, there exists an efficient algorithm to compute ^^(^^1, ^^2). In practice, the groups ^^1, ^^2 and ^^ ^^ will be chosen such that there is no efficiently computable isomorphism between ^^1 and ^^2. Such couplings are known to those skilled in the art as Type 3 couplings. 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 breach the security of these mechanisms, then they are also able to solve these supposedly "difficult" problems. q-SDH Problem: Let ^^ be a cyclic group of prime order ^^ and an element ^^ ∈ ^^ ^^ Given (^^, ^^^^ , ^^^^2 , ^^^^ 3, … , ^^^^The q-strong Diffie-Hellman (q-SDH) problem consists of computing a pair of the form (^^⁄ ^^+^^ , ^^) ∈ ^^ × ^^^^. 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, ^^ is considered a cyclic group of prime order ^^ and ^^ and h are any two generators of ^^. It is assumed that the discrete logarithm of h in base ^^ is unknown. To pledge the message ^^ ∈ ^^ ^^ A sender chooses a random value ∈ ^^^^, calculates ^^ = ^^ ^^ ℎ ^^and sends it to the recipient. If necessary (opening phase), the sender can reveal the values ​​^^ and ^^ to the recipient so that the latter can verify the equality: ^^ = ^^^^h^^. Figure 2 represents a SYS system comprising a D-FI device for generating anonymous credentials implemented by an identity provider (IF), a D-FS device for controlling access to a service implemented by a service provider (SP), and a D-USR device implemented by a user (US) to request access to said service. For simplicity, the D-FI device for managing anonymous credentials will sometimes be called the "IF provider's D-FI device." Similarly, the D-FS device for controlling access to a service will sometimes be called the "D-FS device for service delivery." Likewise, the D-USR device for requesting access to a service will sometimes be called the "user D-USR device." Similarly, instead of saying "DX device," one 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 credential management D-FI device, and the user (U) can designate the service access request D-USR device. The anonymous credential management D-FI device has a public key pair (^^^^^^, ^^^^′^^) and an associated private key (^^^^^^). The user's D-USR device has a public and private key pair (^^^^, ^^^^) 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 D-FI device is configured to, after authenticating a user (U), obtain at least one cryptographic representation ^^. ^^ of an attribute ^^ ^^ of the user and obtain a signature ^^^^^^^^^^^^^^calculated using the private key ^^^^ ^^said identity provider and relating at least to (a) said at least one cryptographic representation ^^ ^^ ; and on (b) a public key ^^^^ of the user (^^). The D-FI device then sends to user U an accreditation ^^^^ containing 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 includes an M-AUTH module for authenticating the user to the D-FI device for generating accreditation. In the described embodiment, the user's D-USR device U includes a secure element for storing cryptographic data, for example, a secret private key, and a WAL cryptographic module, for example, an electronic identity wallet configured to store at least one anonymous verifiable accreditation issued by an FI identity provider, for generating an anonymized signature, for example, the σ signature. B I s l s in u d e r and to generate a verifiable presentation to be presented to the FS service provider 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 the knowledge of a user's private key. In the embodiment described here, the D-FI device for generating an anonymous verifiable credential includes a COM1 communication module. This module can be used by the D-FI device to communicate with the user D-USR for authentication purposes and to send them a credential. In the embodiment described here, the D-FI device includes a M-CRY1 cryptographic module. This module can be used to authenticate a user, calculate hashes, signatures, and proofs.In the embodiment described here, the D-FS device for controlling user access to a service includes an M-LS module to determine which user attributes must be verified before granting access to a service, to verify whether the obtained attributes actually satisfy the service logic, and, if so, to authorize access to the service after verifying at least one proof of the validity of an accreditation for the certification of those attributes. In the embodiment described here, the D-FS device includes a COM2 communication module. This module can be used by the device to request attributes from the user, to obtain those attributes or information enabling the user to obtain those attributes, to obtain a verifiable presentation including an accreditation for a user's attributes, and to send a message to the user informing them of the authorization or denial of access to a service.In the embodiment described here, the D-FS device includes an M-CRY2 cryptographic module configured specifically to calculate hashes, verify proofs, and verify signatures. Figure 3 represents, in flowchart form, the main steps of a process for issuing a verifiable credential implemented by the identity provider FI. During a step I2, the identity provider FI defines the public parameters of the signature system: ^^^^ = (^^1,^^2, ^^^^ , ^^, ^^, ^^, ^^, ^^0, ^^1, ^^2, … , ^^^^, ^̃^, ^^) where: - where ^^1,^^2, ^^^^ are three cyclic groups of order p and ^^ a bilinear coupling of ^^1^^^^2 in ^^. ^^, for which we will assume that the q-SDH problem is difficult. - ^^ is a prime integer that denotes the order of the group ^^ - ^^ the number of attributes to be certified - ^^, ^^0, ^^1, ^^2, .. , ^^^^, ^̃^ denote ^^+3 generators of the group ^^ chosen randomly (such that no one knows the discrete logarithm of one of these generators with respect to another of these generators). Each { ^^ ^^ } ^ ^ ^ = ^1 is associated with a specific attribute type (for example, ^^1 will be associated with the attribute "last 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. - ^^ denotes a generator of ^^2. The ^^+3 generators of the ^^ group 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 { ^^ ^^ } ^ ^ ^ = ^1 is associated with a specific attribute type (for example, ^^1 will be associated with the attribute "last name", ^^2 with the attribute "first name", ^^3 with the attribute "age", ^^4 with the attribute "gender", etc.). In what follows, all calculations involving exponents will be performed modulo p (mod p). During 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 ^ ^ = ^ 1, these public keys being intended to be used for all VC credentials issued by the identity provider FI; - an integer ^^^^ randomly drawn from ^^ ^^ - a digest identifier ^^^^^^ ^^ for each of the ^^ attribute types, i.e. {^^^^^^ ^^} ^ ^ ^ = ^1, and - an identifier ^^^^ ^^^^ for each of the attribute types, either During step I6, the identity provider (IF) generates a private key. ^^ and an associated public key. In the embodiment described here, the private key ^^^^^^ belongs to {1, 2, … , et la clé The associated public pair is (^^^^^^ , ^^^^′^^) with ^^^^^^ = ^̃^ ^^^^^^ and ^^^^′^^ = ^^ ^^^^^^ In the embodiment described here, the identity provider FI also generates a proof Π = PoK {^^: ^^^^^^ = ^̃^ ^^ ∧ ^^^^′^^ = ^^ ^^} with zero disclosure of knowledge that its key pair (^^^^^^ , ^^^^′^^) has been generated. We now assume that the identity provider FI wants to generate a credential^^^^ for the attributes (^^1, ^^2, ^^3, … , ^^^^) 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) ^^h to the user ^^. The user ^^ generates a proof ^^ ^^ =SoK{^^: ^^^^ = ^^ ^^}(^^h) of knowledge of its private key authenticating the challenge ^^h. In the embodiment described here, the proof π Uis 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 their public key (PK) and the proof (PK) to the identity provider (FI). ^^ In the embodiment described here, if the identity provider FI does not authenticate user U based on this information, the result of a test I9 is ​​negative and the process stops. If authentication succeeds, during a step I10, the identity provider FI calculates, using a function cryptographic hashing, a cryptographic representation ^^ ^^ in ^^ ^^ for each of the attributes ^^ ^^In the mode described here, this cryptographic representation is a hash calculated by a function and is, for example, compliant with the SHA-256 protocol. In the embodiment described here, the cryptographic representation ^^ ^^ of an attribute ^^ ^^ is more precisely calculated from the digest identifier ^^^^^^ ^^ , of the attribute identifier ^^^^ ^^^^ , the value of this attribute ^^ ^^ and the public key ^^ ^^ associated with the type of this attribute when creating the proof of identity: This representation conforms to ISO / IEC 18013-5. Other representations may be used in other embodiments of this disclosure. During step I12, the identity provider (IF) calculates a digital signature using its private key. ^^ , on a data structure ^^ including the user's public key ^^^^ and the ^^ condensed ^^^^ . It saves this signature ^^^^^^^^^^^^^^.^^ = ^^^^ ∥ ^^1 ∥ ^^2 ∥ … ∥ ^^^^In the embodiment described here, the signature scheme used conforms to the BBS+ protocol. ^^ is a value chosen randomly from By posing ^^^^ Therefore ^^ ^^ = ^^^^−^^. We denote C = AskI = BA−e. For more information on the BBS+ protocol, those 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 step I14, the identity provider FI generates a proof Π ^^to zero disclosure of knowledge to prove that he knows ^^ such that ^^ = ^^^^ ∧ ^^^^^^ = ^̃^ ^^ .Π^^ = PoK {^^: ^^ = ^^ ^^ ∧ ^^^^^^ = ^̃^ ^^ In the embodiment described here, the VC accreditation is constituted (step I16) by the user's public key ^^^^, the digests {^^ ^^} ^ ^ ^ = ^ 1 and the signature on this data: = ( , { ) = 1 , = ( , ) = ( , ) = ( , ) = ( , )). The secret data associated with this VC credential is the user's private key. During an I18 step, the identity provider FI sends the credential and the proof. ^^ to the user ^^. During a U20 step, the user ^^ calculates = , ^^ = ^^^^ −^^ and verifies the validity of the evidence Π ^^If the proof is validated, the user ^^ stores the VC accreditation, including their attributes {^^, in their WAL digital identity wallet ^^} ^ ^ ^ = ^1 and on its public key ^^^^. In one embodiment, the user knows their attributes and the identity provider does not need to send them back. Alternatively, the identity provider sends them back to the user to allow the user to verify that they and the identity provider share the same information (i.e., to verify, for example, that the identity provider has not misspelled their last name). Figure 4 represents, in flowchart form, the main steps of a service access request process implemented by user U and the main steps of an access control process implemented by the service provider FS. In accordance with this disclosure, user U uses for this purpose a verifiable presentation VP generated from one or more credentials VC by at least one identity provider FI.For simplicity, we assume that the verifiable presentation VP only includes one VC accreditation. We will denote the list of attribute indices by ^^. { ^^ ^^ } ^^∈^^requested by the service provider FS. In this example, we will assume that the service access conditions verification covers three attributes ^^1, ^^5, ^^7, and therefore that ^^ = {1, 5, 7}. In the embodiment described here, for each attribute not belonging to ^^, the user ^^ will send the service provider FS the value ^^^^. During a step U20, the user U connects anonymously to the service provider FS. During a step S22, the service provider sends the user U the list ^^ of attributes that it must verify to grant access to its service and a random value (nonce) specific to the session to prevent replays of verifiable presentations. In a preferred embodiment, this request is authenticated, that is, signed by the service provider FS. During a step U24, the user calculates an anonymized public key PK Blindfrom its public key ^^^^ = ^^^^^^ so that neither the service provider FS nor the identity provider FI can trace it from its public key. To this end, the user ^^ randomly chooses an integer r from Z p and calculates a Pedersen-style stake for its private key sk: PKBlind = g sk+r During step U26, the user calculates an anonymized signature. ^ ^ ^ ^ ^ ^ ^ ^ ^ ^ ^ ^ ^^ ^ ^ ^ ^ ^ ^ ^ ^ based on the signature of his VC accreditation, to also prevent the FS service provider or the FI identity provider from tracing him from this signature element, and "adapt" it so that it relates to the anonymized public key PK Blind and the { H i } n i =1 (and not on PK and the condensers) For this purpose, in the embodiment described here, the user ^^ chooses integers r1, r2 ∈ Zp ∗ then calculate:^̂^ = ^^^^1×^^2^^ = ^^^^2^̅^ = ^̂^−^^^^^^1=^̂^^^^^^^ This proof Π ^^^^^^^^^^^^^^^^ 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 two following equalities: ^̅^ = ^̂^−^^^^^^1 and Alternatively, the proof Π ^^^^^^^^^^^^^^^^ can correspond to: Π ^^^^^^^^^^^^^^^^ = During a U38 step, the user ^^ calculates, using a random number r and their private key sk, a knowledge signature σ User relating to a set of data, called "DeviceAuthenticationBytes" in the ISO / IEC 18013-5 standard and denoted m DAB in the following: 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 enabling the prevention of replays of the verifiable presentation VP, possibly all the data disclosed to the service provider as well as other contextual data). The signature σ User is a signature of knowledge of the discrete logarithm of PK Blind in the base g. In one particular embodiment, the ECSchnorr algorithm is used for this signature. Any other algorithm that proves knowledge of the private key can also be implemented, notably the ECDSA algorithm in the context of self-sovereign identity (SSI) mechanisms. In one embodiment of this disclosure, the secure element SE may not be able to: - anonymize its own public key (step U24) (for example, calculate PKBlind = g sk+r) and / or ;- to anonymize his private key himself (step U26) (for example, calculate ^^^^^^^^^^^^^^ = ^^^^ +^^ (^^^^^^ ^^)) ; and / or - to calculate himself (step U38) the proof of knowledge of the anonymized private key^^^^ + ^^ (^^^^^^ ^^), that is to say, a signature ^^^ ^ ^ ^ ^ ^ ^ ^^ ^ ^ ^ ^ ^ ^ ^ ^^ of knowledge of the discrete logarithm of ^^^^^^^^^^^^^^ in the base ^^. We explain below how the secure element SE and the mobile WAL application associated with this SE can jointly anonymize the public key PK Blind and calculate the signature σ UserIt is worth recalling that in the embodiment described here, only the secure element SE knows the private key sk associated with the user's public key PK. In a first embodiment, we will assume that the secure element SE supports the classic ECSchnorr digital signature algorithm, also called ECSDSA in the ISO / IEC 14888-3 standard. The signature calculation = SoK{α: PKBlind = g α}(m DAB ) could be performed as follows: a / the secure element SE calculates a knowledge signature (denoted σ) of the logarithmmediscret of PK in the base g (i.e., of the private key sk): σUser = SoK{α: PK = g α}(m DABIn one embodiment, the ECSDSA algorithm can be implemented as follows for calculating this signature: the secure element SE: i / generates a random number ω ii / calculates T = gω, c = ℋ(T ∥ mDAB) and iii / calculates ρ = ω + c sk (mod p) denotes a cryptographic hash function (SHA-256 for example). The signature σ consists of the pair (c, ρ): σUser = (c, ρ). It is valid if c′ = ℋ(gρ x ^^^^−^^ , mDAB) = c and invalid otherwise. b / the WAL application: i / chooses a random number ri i / calculates PK r sk+rBlind = g × PK = g , and iii / calculates ρBlind = ρ + c × r = ω + c × sk + c × r = ω + c × (sk + r) (mod p). The signature ^^^^^^^^^^^^^^^^^^^^ = (c, ρBlind) is a valid ECSDSA signature on mDAB with respect to the public key PK Blind In this embodiment, the secure element SE calculates the proof σ User of the knowledge of the user's private key, the proofs σ B I s l s in u d e rand σ B U l s i e n r d 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 perform and only scalar multiplication on an elliptic curve to perform) while the signature ^^ ^ ^ ^^ ^ ^ ^ ^ ^ ^ ^ ^ ^^ ^ ^ ^ ^ ^^ ^ ^ is calculated by the dedicated WAL mobile application on its mobile phone. In a second embodiment, we will assume that the secure element SE supports the classic ECDSA digital signature algorithm. The calculation of the signature ^^^^^^^^^^^^^^^^^^^^^ = SoK{α: PKBlind = g α}(m DAB) can be performed as follows, and the ECDSA algorithm can be implemented to calculate this signature: a / the WAL application: i / calculates a data mod p et ii / transmits the data M to the SE b / the secure element SE: i / chooses a random number ^^ ∈ ^^^ ∗ ^ ii / calculates ^^^^ = (^^, ^^) and ^^ = ^^ (mod ^^). Note that we are incorrectly using multiplication (instead of addition) to denote the group operation in ^^. The element ^^ ^^ is therefore indeed a point on the underlying elliptic curve. Also note that if ^^ = 0 then the SE chooses a new random number ^^ ∈ ^^^*^ and then recalculates ^^^^ = (^^, ^^) and ^^ = ^^ (mod ^^) until ^^ ≠ 0. iii / calculates ^^0 = ^^−1(^^ + ^^^^ × ^^) mod ^^. Note that if ^^0 = 0 then the SE chooses a new random number ^^ ∈ ^^^*^ and then recalculates ^^^^ = (^^, ^^) , ^^ = ^^ (mod ^^) = ^^−1(^^ + ^^^^ × ^^) until ^^ ≠ 0 and ^^0 ≠ 0. The WAL application transmits ^^0 to the WAL application. Once ^^ is received, the WAL application calculates ^^ = ^^ × ^^0 = ^^ (ℋ(^^^^^^^^) + ^^^^^^^^^^^^^^^ × ^^) mod ^^. The signature = (^^, ^^) is a valid ECDSA signature on ^^^^^^^^ relative to the public key ^^^^^^^^^^^^^^. In this embodiment, the proof ^^ of knowledge of the user's private key as well as the proofs σ B I s l s in u d e r and σ B U l s i e n r d are calculated jointly by the said secure element SE and by the WAL application of said terminal. Thus, the secure element SE performs simple operations (no bilinear coupling to perform and only scalar multiplication on an elliptic curve to perform) while the signature ^^ ^ ^ ^^ ^ ^ ^ ^ ^^ ^ ^ ^^ ^ ^ ^ ^ ^^ ^ ^ is calculated by the dedicated WAL mobile application on his mobile phone. Verifiable presentation ^^^^ ^^^^ Selective disclosure consists (step U40) of the identity provider's public key (IF) and the anonymized public key (PK). Blind of the user, of the {^^^^} ^ i ∉^^ , of all the data disclosed to the FS service provider (^^ disclosed ={HIDi ∥ IDai ∥ ai ∥ Ki}i∈^^), cryptographic representations ^^ ^^^^∈^^ , and σ signatures B I s l s in u d e r and ^^ ^ ^ ^ ^ ^ ^^ ^ ^ ^ ^ ^ ^ ^ ^ ^ ^^ . The user submits the verifiable presentation ^^^^ ^^^^to the service provider FS during a step U42. During a step S44, the service provider FS calculates H′i = ℋ(HIDi ∥ IDai ∥ ai ∥ Ki) for each i ∈ ^^. It then verifies that: i / H′i = Hi for each i ∈ ^^ ; ii / ^^^ ^ ^ ^ ^ ^ ^ ^^ ^ ^ ^ ^ ^ ^ ^ ^^ is a valid signature on m DAB In other words, the FS service provider can reconstruct it using the PK public key Blind certified by the identity provider FI. The ECSchnorr or ECDSA algorithm for verifying this SoK (SoK{α: PK Blind = g α}(m DAB )) being known to those skilled in the art, we will not detail it in this document. iii / σ Blind Issuer is a valid signature on PKBlind, {Hi}i∈^^ and {H′i = ^^^^}i∉^^, using the FI's public key. To do this, it must first ensure that the following equality is satisfied: e(Â, PK ′ I) = e(B,̅ f) (If the FI has implemented the version of BBS+ using bilinear couplings) and on the other hand that Π validity is valid. The algorithm for verifying this proof Π validity is known to a person skilled in the art. Alternatively, they can ensure that the following equality ^̅^ = ^̂^^^^^^^ is satisfied and, on the other hand, that Π^^^^^^^^^^^^^^^^ is valid. If all these conditions are met, it is shown that the required attributes {a i} i∈^^ have been properly certified by the identity provider FI and that the verifiable presentation VP does indeed originate from the user ^^ whose attributes are the requested attributes {a i} i∈^^The service provider (FS) allows the user ^^ to access its service (step S46). If at least one of the conditions is not met, the FS denies access to its service (step S48). The mechanism described above is very advantageous because neither the FS nor the identity provider (FI) can trace the user ^^. Furthermore, the selective disclosure method conforms to that described in ISO / IEC 18013-5, but the latter has the drawback, in the event of collusion between the FS and FI, of allowing the tracking of their shared customers' usage. In the embodiment described above, the user ^^ does not need to be logged in to generate a verifiable presentation (VP). Similarly, the FS does not need to be logged in to generate and verify a verifiable presentation (VP).This mode, which can be described as offline (HL), corresponds to a VP verification method 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" or "synchronous." This mode, which requires at least one of the two parties to 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 federated identity described with reference to Figure 1, the user receives a token from the identity provider confirming that they have met the access requirements for the service provider. As previously stated, the federated identity problem 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 implementation of this disclosure that is compatible with the SHL mode of ISO / IEC 18013-5, but in which the identity provider (IF) is unable to identify which service provider (SP) a user ^^ uses their tokens with. We consider the situation in which the user ^^ has received an accreditation ^^^^ =(^^, ^^) from the service provider as described with reference to Figure 3. With reference to Figure 5, the user ^^ calculates an anonymized key PK. Blind from public key ^^^^ = ^^^^^^ and an anonymized value of the signature ^^^^^^^^^^^^^^ of their VC accreditation. These steps are similar to steps U24 and U26 described with reference to Figure 4. During a U28 step, the user ^^ attempts to obtain proof (SoK) from the FI identity provider by contacting them directly. sk r × ^^^^that B̅ = ÂI where  = A 1 r2. 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 I ), will be unable in the presence of such proof π EQ to determine which user it was intended for. In one embodiment, and as described below with reference to Figure 6, this proof ^^ ^^^^ can be obtained using the Chaum-Pedersen blind signature protocol (David Chaum, Torben P. Pedersen: Wallet Databases with Observers. CRYPTO 1992: 89-105). During a U38 step similar to the U38 step already described with reference to Figure 4, the user ^^ calculates, using a random number r and their private key sk, a knowledge signature relating to a dataset m ^^^^^^^^^^^^^^^^^^^^^ = SoK{α: PKBlind = g α}(m DAB ) The verifiable presentation ^^^^ ^^^^^^consists (step U400) of the identity provider's (IF) public key, the user's anonymized public key (PK), and the of all the data disclosed to the FS service provider (^^disclosed = {HIDi ∥IDai ∥ ai ∥ Ki}i∈^^), cryptographic representations ^^ ^^^^∈^^ , σ signatures B I s l s in u d e r and ^^ ^ ^ ^ ^ ^ ^ ^ ^^ ^ ^ ^ ^ ^ ^ ^ ^^ And proof ^^ ^^^^ . σ Blind Issuer, ^^ ^ ^ ^ ^ ^ ^ ^^ ^ ^ ^ ^ ^ ^ ^ ^ ^ ^ , ^^ ^^^^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′i = ℋ(HIDi ∥ IDai ∥ ai ∥ Ki) for each i ∈ ^^. It then verifies that: i / H′i = Hi for each i ∈ ^^ ; ii / σ User is a valid signature on m DAB is a valid signature on PKBlind, {Hi}i∈^^ and {H′i = ^^^^}i∉^^, using the FI's public key. To do this, it must first ensure that the proof Π EQ is valid and that the proof Π validityis valid. If all these conditions are met, the service provider FS allows the user ^^ to access its service (step S46). If at least one of the conditions is not met, the service provider FS denies access to its service (step S48). This solution has the advantage of not requiring bilinear coupling, making it much more efficient than those implementing these cryptographic tools. Its security also relies on mathematical problems commonly considered more difficult by the scientific community. Figure 6 represents, in flowchart form, a protocol implemented between the user ^^ and the identity provider FI by which the identity provider FI can provide the user ^^ with a proof (SoK) ^^ ^^^^that B̅ = ÂskI where  = Ar1×r2. In other words, this figure details step U28 of Figure 5 in a particular implementation of this disclosure. Recall that the identity provider FI knows the signature ^^^^^^^^^^^^^^ = (^^, ^^) calculated in step I12 on the public key ^^^^ and the attributes ^^ ^^ of the user ^^. During an I50 step similar to the I8 step, the identity provider (IF) sends a challenge (message) ^^h to the user ^^. The user ^^ generates a proof ^^ ^^ =SoK{^^: ^^^^ = ^^ ^^}(^^h) of knowledge of its private key authenticating the challenge ^^h, for example using the algorithm called ECSchnorr or ECDSA. The user ^^ sends the identity provider FI its public key PK and the proof ^^ ^^In the embodiment described here, if the identity provider (IF) does not authenticate user U based on this information, the result of test I51 is negative and the process stops. If authentication succeeds, during step I52, the identity provider (IF) calculates a cryptographic representation. ^^ in ^^ ^^ for each of the attributes ^^ ^^ of the user ^^. This step is similar to step I10. During an I54 step, the identity provider FI chooses a value ^^ randomly from ^^ ∗ ^^ ^^ and calculate ^^0 = ^̃^ and calculate ^^0 = ^^ ^^ The identity provider FI sends the values ​​^^0 and ^^0 to the user ^^ (step I56). During a step U58, the user ^^ chooses two values ​​^^, ^^ randomly from ^^^ ∗ ^ and calculate: ^^0 = ^^ / ^^ (mod ^^) The user sends the value ^^0 to the identity provider FI during a U60 step. During an I62 step, the identity provider FI calculates ^^0 = ^^ + ^^0 × ^^^^^^ (^^^^^^ ^^) and sends the value ^^0 = ^^ + ^^0 × ^^^^^^ (^^^^^^ ^^) to the user ^^. During a U64 step, the user ^^ calculates: ^^ = ( ^^0 + ^^)^^ (mod ^^) The proof πEQ is equal to: πEQ = (Â, B,̅ c, r). This is a valid proof (SoK) on the message m DAB 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 includes, in particular, a processor 10, random access memory 11, read-only memory 12, and communication means 13. The read-only memory 12 constitutes a storage medium within the meaning of the invention. It includes a PG-X computer program according to the invention. For the D-USR device, this PG-X computer program is a PG-USR program containing instructions to execute the steps of a process 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, obtaining WAL accreditation, calculating WAL 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 containing instructions to execute the steps of an accreditation generation process as described previously with reference to Figures 2 and 3. The PG-FI program defines, in particular, the M-CRY1 module for authentication, hash calculation, signature generation, and accreditation issuance, and the COM1 module of the D-FI device. For the D-FS device, this PG-X computer program is a PG-FS program containing instructions to execute the steps of an access control process for a service as described previously with reference to Figures 2 and 3. The PG-FS program defines, in particular, the M-CRY2 module for hash calculation, proof generation, and signature generation, and the COM2 communication module of the D-FS device.

Claims

CLAIMS

1. A method for requesting access, implemented by a user's device (^^), to request access to a service provided by a service provider (SF), said method comprising the following steps: - sending (U42, U420), to said service provider (SF), a verifiable selectively disclosed presentation containing at least: (aa) an identity provider (IF) public key, (bb) an anonymized public key PK Blind of the user (U) calculated from a public key ^^^^ of the user (U), (cc) at least one attribute to reveal (a i ) to access said service, (dd) a cryptographic representation ^^ ^^ said at least one attribute to be revealed (a i ) (ee) an anonymized signature σ B I s l s in u d e r calculated from a signature ^^^^^^^^^^^^^^calculated using a private key (^^^^ ^^) of said identity provider and bearing at least on said at least one cryptographic representation ^^ ^^ and on said public key ^^^^ and (ff) a proof (U38) knowledge of an anonymized private key of the user associated with said anonymized public key PK Blind calculated from a proof of knowledge ^^ of a user's private key; said proofs ^^, σ B U l s i e n r d and said anonymized signature ^^ ^ ^ ^^ ^ ^ ^ ^ ^ ^ ^ ^ ^^ ^ ^ ^ ^ ^ ^ ^^being calculated jointly by a secure element (SE) of a terminal of said user and an application (WAL) of said terminal.

2. Access request method according to claim 1 characterized in that said cryptographic representation ^^ ^^ , said public key (^^^^) of the user (^^) and said signature ^^^^^^^^^^^^^^^ are included in an accreditation ^^^^ received from said identity provider (IF).

3. Access request method according to claim 2, further comprising a proof verification step Π I of the validity of said accreditation, said proof being received from said identity provider (IF).

4. A method for requesting access according to any one of the preceding claims, further comprising a step (U28) of obtaining proof of the validity of said anonymized signature provided by said supplier identity (FI), said verifiable selective disclosure presentation further including said proof of validity

5. A 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 proof Π I of the validity of said accreditation, said accreditation comprising at least: (i) a cryptographic representation ^^ of an attribute (^^ ^^ (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 Π I - a module (COM3) for receiving a list (^^) of at least one attribute to be revealed to the service provider (SP) in order to access the service - means (SE, WAL) for calculating an anonymized public key PK Blind from the user (^^) using said public key ^^^^, to calculate an anonymized signature ^^ ^ ^ ^ ^ ^ ^ ^ ^ ^ ^ ^ ^ ^^ ^ ^ ^ ^ ^ ^ ^ ^ based on the signature ^^^^^^^^^^^^^^ and proof ^^ ^ ^ ^ ^ ^ ^ ^ ^^ ^ ^ ^ ^ ^ ^ ^ ^^knowledge of an anonymized private key of the user associated with said anonymized public key PK Blind based on proof of knowledge of a user's private key; - a sending module (COM3) for auditing the service provider (FS) with a verifiable, selectively disclosed presentation containing at least: (aa) an identity provider's (IF) public key, (bb) the anonymized public key PK Blind of the user, (cc) at least one attribute to reveal (a i ) to access said service, (dd) a cryptographic representation ^^ ^^ said at least one attribute to be revealed (a i ), (ee) said anonymized signature σ B I s l s in u d e r and (ff) said proof σ User .

6. Computer program (PG-USR) comprising instructions which, when the program is executed by a computer, cause the computer to implement a method for requesting access to a service according to claims 1 to 4.

7. Computer-readable recording medium on which a computer program according to claim 6 is recorded.

Images