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

Abstract

The invention proposes a method for requesting access to a service provided by a service provider, comprising the following steps: - receipt (I18), from an identity provider, of an accreditation and proof of the validity of the accreditation; - verification of the proof; - receipt (S22) of a list of attributes to be revealed to said service provider in order to access said service; - calculation (U24, U26) of an anonymized public key of the user, an anonymized signature, and proof (U38) of knowledge of an anonymized private key of the user associated with said anonymized public key, based on proof of knowledge of a private key of the user, said proofs being calculated jointly by a secure element and an application on a user terminal; - sending (U42, U420), to said service provider, a verifiable presentation with selective disclosure. Fig. 1

Description

Title of the invention: Methods and devices for requesting access to a service provided by a service provider. Prior art

[0001] The invention lies in the field of digital identity management. More specifically, the invention relates to a method of digital identity management 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.

[0002] Many service providers require the provision of attributes or identity elements of a user before delivering their service.

[0003] 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.).

[0004] The development of services accessible via the internet requires the implementation of dedicated tools enabling the digitization of elements present on the aforementioned media, possibly in a structured way and allowing their sharing with the service provider, after consent from the user.

[0005] The major players on the Internet have hitherto structured the field of digital identity management according to their business model. For example, through the OIDC (OpenID Connect) protocol, they have developed an offering that centralizes the user's identity elements and, under its control, after user identification / authentication and consent, authorizes service 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," lies in the fact that the identity provider knows, each time a user consumes one of the services, when the operation takes place and which identity elements the user shares with the service provider they are accessing.

[0006] Figure 1 illustrates the known mechanism of federated identity: - A user U sends an Rq_Id request to an identity provider (IF) so that the IF 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 TOK token to the user U - User U transmits this tokenTOK to the service provider FS so that the latter authorizes access to the service.

[0007] Self-sovereign identity (SSI) is another approach to digital identity, which gives users total control over their identity elements: they can present them when accessing a service either to prove who they are or one of their attributes. Only the service provider and the user interact during the identity element sharing phase.

[0008] In this logic, the user holds identity elements concerning him / herself, which have been issued and certified by one or more trusted entities, for example by an identity provider via the use of digital signatures.

[0009] In this digital identity model, a Verifiable Credential (VC) is a personal attestation enabling its holder to convince a third party, for example a service provider, that they possess a particular authorization or qualification. Diplomas, student cards, and driver's licenses are all examples of classic accreditations used in everyday life.

[0010] To generate trust between the user and the service, the user can present their identity elements, certified by the identity provider (in whom the service provider has confidence), using a verifiable presentation (VP). 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 cryptographic keys of the holder.

[0011] In the self-sovereign identity approach, the user controls the dissemination of his identity elements to the service provider (after consent) and protects his privacy vis-à-vis the identity provider by excluding it from his relationship with the service provider, the protocol being completely asynchronous.

[0012] However, the standard digital signature mechanisms used by the identity provider require the disclosure of all signed / certified data, even to prove the authenticity of only a part of it.

[0013] To protect their privacy, it is desirable for a user to disclose 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 or attribute data.

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

[0015] The ISO / IEC 18013-5 standard explains how to transpose this manual redaction technique to digital identity documents. This ISO / IEC 18013-5 standard is more Specifically, 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 that can be generalized 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.

[0016] The operating principle of the selective disclosure method used in ISO / IEC 18013-5 is now described.

[0017] Issuance of an identity document in accordance with ISO / IEC 18013-5

[0018] The identity provider has a private (SKj) and public key pair (PKi), of a digital signature algorithm such as ECDSA (Elliptic Curve Digital Signature Algorithm).

[0019] The user also has a private (SK) and public (PK) key pair for a digital signature algorithm, which they will use to authenticate their verifiable presentations (VP) and which they must first have certified by the identity provider along with all the attributes (regulatory or otherwise) relating to their driver's license. We will denote their attributes as ( ) ... A \Cl , > Uny

[0020] During the issuance phase of a VC accreditation (or digital identity document), after authenticating the user, the identity provider randomly chooses n public values, denoted IK-11, then calculates n digests (hashes 1 1 J £=1 cryptographic), one per attribute.

[0021] Each of these n digests is labeled by a unique digest identifier denoted HIDi. The digest, denoted If., of each attribute is calculated from its digest identifier (HIDjf), the attribute identifier (denoted ^a,), the value of this attribute (a0), and the secret key generated and associated with this attribute during the creation of the identity document:

[0022] dj || where H denotes a hash function cryptographic (SHA-256 for example); the notation str} || str2 being used to denote the concatenation of the strings str, and str2.

[0023] The identity provider then calculates a digital signature, using its private key SKh on the data structure comprising the user's public key PK and the n condensed Ef. Let H = PK || Hr || H2 || || H and — v the signature of the identity provider on H. ^Issuer — j

[0024] The identity provider then transmits the ^issuer signature and the If keys to the user.

[0025] The user's VC accreditation (or digital identity document) (or mobile security element - MSO in the terminology of ISO / IEC 18013-5) consists of their public key PK, the {H-}n hashes and the ^issuer certificate on this data:

[0026] f'1 — ( pp r jj \ n Y ' ( PK, { il j ] , <7 / ssuerJ

[0027] The secret data associated with this digital identity title VC are the user's private key SK and the randomly chosen secret keys [K- î ” •

[0028] Verifiable presentation of a digital identity document with selective disclosure in accordance with ISO / IEC 18013-5:

[0029] We will henceforth denote by A the list of indices of the attributes requested by the service provider. For example A = {1, 5, 7} means that the service provider wants the user to disclose the attributes af, ax, and ai.

[0030] The user connects anonymously to the service provider's site. The provider sends the user the access conditions to its site (i.e., list A of required attributes) as well as a random value (nonce) specific to this session to prevent replays of verifiable presentations.

[0031] The user calculates, using their private key SK, a signature (^tw) on a set of data called "DeviceAuthenticationBytes" in the ISO / IEC 18013-5 standard and denoted mOAB hereafter. 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 replays), optionally all the data disclosed to the service provider, as well as other contextual data:

[0032] °User = / \ Sign SK \tn DAB )

[0033] The verifiable presentation VP consists of the identity provider's PKI public key, the user's PK public key, the H-hash hashes, and all the data disclosed to the service provider. ^disdosed - { HIDï || IDai || || . Y and signatures and :

[0034] VP = (PK T , PK, {H{} n AhIDAÏ ID a || æ||

[0035] The user transmits the verifiable VP presentation to the service provider.

[0036] The service provider first calculates || ID* || a, || K) for each ie A.

[0037] He then verifies that: 1. H'i = for each ie A; 2. ^isister is a valid signature on H = PK II H || H, || || H using It 1 II Z II • * ' it n the identity provider's public key PKt; 3. aVser is a valid signature on mDAB (which the service provider can reconstruct) using the PK public key certified by the identity provider.

[0038] If (and only if) these three conditions are met, the service provider gives access to its service to the user.

[0039] Note 1: The issuer signature allows authentication of all identity data disclosed by the user ( { )) as well as the PK public key. The ^User signature, As for it, it allows the service provider to be convinced that this verifiable presentation does indeed originate from the accreditation holder. TT, n\ and VC = [PK, {Ha Issuer ] that it is therefore not a replay of a previous verifiable presentation.

[0040] Note 2: The public keys Kp included in the digest calculations 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 "identity card serial number." Indeed, if Hj had been calculated as follows: jj. — |j IDOi || üiY without the key K^ It would be very simple to find the "date of birth" attribute (¾) by testing all possible values ​​until the correct one is obtained, that is, the one that satisfies the equality dj. _ h(h / D- || || a't) (the data and IDa; being data public spaces accessible to all). Disadvantages of the ISO / IEC 18013-5 standard

[0041] The scheme presented above, as proposed by ISO / IEC 18013-5, has several drawbacks. In particular:

[0042] i / From the perspective of personal data protection, 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 PK, 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 ^issuer and will therefore be able to identify its author in the presence of a verifiable presentation.

[0043] ii / the user's private key SK, which will be used to authenticate their verifiable presentations through the ^User signature, is an extremely sensitive key that must Therefore, it must be adequately protected; indeed, compromising this key would expose the user to the 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, such as 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 GUser signatures and / or verify Aissuer signatures.

[0044] The invention relates to a solution enabling the selective disclosure of anonymous credentials without the aforementioned drawbacks. Object and summary of the invention

[0045] Thus, and according to a first aspect, the present disclosure relates to a method for generating a VC 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 Hi of a user attribute; - obtaining a fidussured signature calculated using a private key from said identity provider and covering at least: (a) said at least one cryptographic representation; and on (b) a user's PK public key; - calculation of proof of validity L, of a VC accreditation comprising at least: (i) said signature aissuer, (ii) a user's PK public key; (iii) said at least one cryptographic representation Hi; and - sending said user said proof nT and said VC accreditation.

[0046] Correspondingly, this disclosure relates to a device for generating a VC credential covering at least one attribute of a user, the device comprising: - a user authentication module; - a module for obtaining at least one cryptographic representation Hi of a user attribute; - a module for obtaining a calculated ^issuer signature using a private key from said identity provider and covering at least: (a) said at least one cryptographic representation; and on (b) a user's PK public key; - a calculation module for proof of the validity of a VC accreditation, comprising at least: (i) said signature ^issuer , (ii) a user's PK public key; (iii) said at least one cryptographic representation; and - a module for sending said proof and VC accreditation to the user.

[0047] 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 the users' attributes.

[0048] 2. at least one service provider that checks certain attributes of a user Before providing the service, the service provider must ensure that the user's attributes are verified. In other words, the service provider checks that a user's attributes meet the access requirements for its services. For example, for access to an adult content website, the service provider has a legal obligation to ensure that the user is of legal age. The user must therefore provide proof of age through a verifiable document generated from an accreditation, certifying their age, issued by an identity provider trusted by the service provider.

[0049] 3. at least one user with a set of credentials enabling him to to prove one's identity or at least some of one's 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.

[0050] 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)".

[0051] In one embodiment, said at least one cryptographic representation is a digest obtained by a hash function.

[0052] In one embodiment, this summary complies with ISO / IEC 18013-5:2021. Indeed, this disclosure is fully compatible with the data and disclosure model defined in this standard.

[0053] A VC accreditation within the meaning of this disclosure is, for example, a digital identity credential or a mobile security element - MSO in the terminology of ISO / IEC 18013-5.

[0054] Very advantageously, by implementing this disclosure, the user only reveals to the service provider the attributes strictly necessary for access to the service concerned.

[0055] According to a second aspect, the present disclosure relates to a process implemented by a user's device to request access to a service provided by a service provider, said process comprising the following steps: - user authentication with an identity provider; - receipt from the identity provider of a VC accreditation and proof Hj of the validity of the VC accreditation, said VC accreditation comprising at least: (i) a cryptographic representation H of a user attribute (ii) a user's public key; and (iii) an issuer signature calculated using a private key of said identity provider and relating at least to: (a) said at least one cryptographic representation H; and (b) said user PK public key, - verification of said proof II[ ; - receipt of a list of at least one attribute to be revealed to said service provider in order to access said service; - calculation of an anonymized public key PKBlind of the user from said public key PKet of an anonymized signature from the signature ^issueet of a proof (?ij^ of knowledge of an anonymized private key of the user associated with said anonymized public key PKBlind from a proof of knowledge a of a private key of the user, said proofs a, and O"®1™1 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 user's anonymized PKBünd public key, (cc) at least one attribute to be revealed to access said service, (dd) a cryptographic representation of said at least one attribute to be revealed, (ee) said anonymized signature and (ff) said proof

[0056] Correspondingly, this disclosure relates to a device for requesting access to a service provided by a service provider, said device comprising: - an authentication module for a user of said device with an identity provider; - a module for obtaining, from said identity provider, a VC accreditation and proof of the validity of this VC accreditation, this VC accreditation comprising at least: (i) a cryptographic representation H{ of a user attribute (ii) a user's PK public key; and (iii) an Alssuer signature calculated using a private key of said identity provider and relating at least to: (a) it says at least one cryptographic representation H{ and (b) said user public key, - a module for verifying said proof; - 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 of calculating an anonymized public key PKBUnd of the user from said public key, of calculating an anonymized signature <7^^. from the signature aissuer and means of calculating a proof of knowledge of an anonymized private key of the user associated with said anonymized public key PKg^ from a proof of knowledge ° of a private key of the user; - a sending module, service provider audit, of a verifiable, selectively disclosed presentation including at least: (aa) a public key of the identity provider, (bb) the user's anonymized PKBlind public key, (cc) at least one attribute to be revealed to access said service, (dd) a cryptographic representation Hj of said at least one attribute to be revealed, (ee) said anonymized signature and (ff) said proof <7^^.

[0057] Very advantageously, through 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, individually or jointly, can trace the user in the uses of his credentials.

[0058] 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, selectively disclosed presentation that includes at least: (aa) a public key from an identity provider, (bb) an anonymized PKblind public key of the user obtained from a PK public key of the user, (cc) at least one user attribute to be revealed to access said service, (dd) a cryptographic representation of said at least one attribute to be revealed, (ee) an anonymized signature obtained from an issuer signature issued by said service provider and relating at least to: (a) at least one cryptographic representation H, of a user attribute and (b) an anonymized PKBlind public key of the user, and (ff) proof af^^de the user's knowledge of an anonymized private key associated with said anonymized public key PKBlind; - calculation of a cryptographic representation of said required attribute; - verification : (i) of the cryptographic representation H'} of the required attribute; (ii) said proof of the user's knowledge of said anonymized private key and (iii) of said anonymized signature using the public key of said identity provider (IF); - a positive result of said verification being a necessary condition to authorize the user's access to said service.

[0059] Correspondingly, this disclosure relates to a device for controlling user access to a service, said device comprising: - a module for obtaining a verifiable, selectively disclosed presentation comprising at least: (aa) a public key of an identity provider, (bb) an anonymized PKBimd public key of the user obtained from a PK public key of the user, (cc) at least one user attribute to be revealed to access said service, (dd) a cryptographic representation Hi of said at least one attribute to be revealed, (ee) an anonymized signature obtained from a signature issuer issued by said service provider and relating at least to: (a) at least one cryptographic representation Hi of a user attribute and (b) an anonymized public key PKBiùui^ the user, and (ff) proof of the user's knowledge of an anonymized private key associated with said anonymized public key PKB]ind; - a calculation module for a cryptographic representation H} of said required attribute (a,); - a verification module (M-CRY2) (S44, S440): (i) of the cryptographic representation H} of the required attribute (ii) of said proof cr^^de of the user's knowledge of said anonymized private key and (iii) of said anonymized signature 0^1^. using the public key of said identity provider; - a module configured to allow user access to said service at least if said check is positive.

[0060] In one embodiment, the user obtains from the identity provider proof of the validity of said anonymized signature, and the verifiable selective-disclosure presentation sent to the service provider by the user includes this proof of validity.

[0061] In this embodiment, and as described in detail below, the verification of the anonymized signature 0^!^r by the service provider includes the verification of this proof of validity ^8.

[0062] This embodiment of the invention is advantageously compatible with the federated identity mechanisms described with reference to [Fig.1], and in particular that in the mode of the ISO / IEC 18013-5 standard, in which the user, after authenticating with the service provider, receives from the latter a token attesting that he / she / it verifies the conditions of access to the services of that provider.

[0063] In one embodiment, the access request process includes: - the calculation, by a secure element of the user terminal, of a proof a of the knowledge of a private key of the user; - said proofs 0®^. and being calculated jointly by this secure element (and an application of said terminal.

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

[0065] In this solution, the secured element has no bilinear coupling to perform and only elliptic curve scalar multiplication to perform to generate the aUær signature (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:

[0066] Anonymous Attestation Using the Strong Diffie-Hellman Assumption Revisited. IACR Cryptol. ePrint Arch. 2016: 663 (2016)), the user's secure device only has a constant number of elliptic curve scalar multiplications to perform to generate the °User signature but must, on the other hand, interact several times with the mobile application to calculate this signature.

[0067] The invention also relates to a computer program comprising instructions for executing the steps of the process of generating at least one accreditation when said program is executed by a computer.

[0068] The invention also relates to a computer program comprising instructions for executing the steps of the process of requesting access to a service when said program is executed by a computer.

[0069] The invention also relates to a computer program comprising instructions for executing the steps of the access control process for a service when said program is executed by a computer.

[0070] These programs may use any programming language, and be in the form of source code, object code, or intermediate code between source code and object code, such as in a partially compiled form, or in any other desirable form.

[0071] 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

[0072] Other features and advantages of the present invention will become apparent from the description below, with reference to the accompanying drawings which illustrate non-limiting examples of embodiments. In the figures:

[0073] [Fig-1] The [Fig. 1] already described represents the known mechanism of federated identity

[0074] [Fig.2] Fig.2 represents a system comprising a generation device accreditation, a device used by a user to request access to a service and a device for controlling access to a service that conform to particular embodiments of this disclosure;

[0075] [Fig.3] The [Fig.3] represents in flowchart form the steps of a process for generating an accreditation in accordance with a particular embodiment of this disclosure;

[0076] [Fig.4] Fig.4 represents in flowchart form the steps of a process for requesting access to a service and a process for controlling access to a service in accordance with a particular embodiment of this disclosure;

[0077] [Fig.5] Fig.5 represents in flowchart form the steps of a process for requesting access to a service and a process for controlling access to a service in accordance with another particular embodiment of this disclosure;

[0078] [Fig.6] The [Fig.6] represents in flowchart form a step of the process of the [Fig.5] in a particular mode of the present disclosure;

[0079] [Fig.7] The [Fig.7] represents the hardware architecture of the devices of the [Fig.1] in a particular embodiment of the present disclosure.

[0080] As a preliminary matter, we recall the cryptographic tools used in this disclosure. Pledging schemes

[0081] 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 subsequently. This security can, if necessary, be disclosed later by the issuer.

[0082] Thus, the recipient is assured that once the pledge is published, the issuer can no longer change their mind about the value contained in that pledge. Figuratively speaking, a pledge consists of handing the recipient a locked box containing the secret, and subsequently providing them with the combination to open it.

[0083] In a particular embodiment, the present disclosure may use the pledge 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 hiding commitments. Zero-knowledge evidence

[0084] It is recalled that a Zero-Knowledge Proof (ZKP) is an interactive protocol that allows a verifier to convince themselves that a certain prover knows a secret -S satisfying a given predicate P, the proof revealing no information about the secret to the verifier. the s in question, apart from the fact that it satisfies the given predicate P. Subsequently, to represent zero-knowledge proofs, we will sometimes use the standard notation PoK {a, P, ... : predicate on a, p, ...} 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{a ; J = g"} will denote a proof of knowledge of the discrete logarithm of (the public value) y in the (public) base £.

[0085] In a particular embodiment, non-interactive versions of so-called zero-knowledge proofs (also called "knowledge signatures") are used, obtained through heuristic transformations such as the Fiat-Shamir transformation (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 P 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 knowledge signature of secret values ​​(a, fi, y, ...) satisfying a given predicate and authenticating a message m as follows: SoK{ a, fi, y, ... : predicate on a, fi, y, ...}(OT) where the Greek letters correspond to the secrets known by the prover and to the authenticated message. .

[0086] For example, SoK{fZ: = g^}^) will denote a knowledge signature of the discrete logarithm of (the public value) y in the (public) base $ authenticating the message m. A knowledge signature on a message has the same characteristics as a digital signature: it guarantees both its authenticity and its integrity. Description of implementation methods

[0087] We will use the following notation in the following days an ' R(af to denote a zero-knowledge proof (ZKPK) of elements ai, a2,..., a» 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: p0K(aia2 : A = ■ œ2A (c^ * 1) A (a2 * 1) ) • De Similarly, we will subsequently use the following notation an ' R^CL^ a^m) to denote a knowledge signature (ZKPK) of elements ai, aA..., a» satisfying relation R and authenticating message m. Zp will denote the set {0, 1, 2,..., ^-1}, where is a prime integer and z* the set {1, 2,...,M}.

[0088] 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 Gf x G2 to a set GT where Gb G2 and Gt denote cyclic groups of order p, p being a prime number. This map e satisfies the following properties: 1. (Bilinearity) V g} G Gb V g2 G G2etv e(garSb2) = 2. (Non-degenerate) For g{ * b, and g2 * 1«2, / '] 1 *3» p » 2 / 3. (Computable) V g^ G Gb V g2 G G2, there exists an efficient algorithm to calculate / \. ^1'

[0089] In practice, the groups G1, G2, and G2 will be chosen such that there is no efficiently computable isomorphism between G1 and G2. Such couplings are known to those skilled in the art as Type 3 couplings.

[0090] The security of certain 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, it is because they are also able to solve these problems, which are nevertheless considered "difficult".

[0091] q-SDH Problem: Let G be a cyclic group of prime order and an element x e Zp. Given (g, g\ gx2 gx2 , g.^ , the q-strong Diffie-Hellman (q-SDH) problem consists of computing a pair of the form ce Q x Zp-

[0092] 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).

[0093] In this scheme, we consider G to be a cyclic group of prime order p and h to be any two generators of G. H is assumed to be the discrete logarithm of h in base $, which is unknown. To commit to the message m G Zp of its choice, a sender chooses a random value G Zp, calculates C = g^11 and sends it to the receiver. If necessary (opening phase), the sender can reveal the values ​​m and r to the receiver so that the latter can verify the equality: C = g^11

[0094] Figure 2 represents a SYS system comprising a D-FI generation device anonymous accreditation implemented by an identity provider (IF), a D-FS access control device for a service implemented by a service provider (SSP) and a D-USR device implemented by a user U to request access to said service.

[0095] For the sake of simplicity, the D-FI anonymous accreditation management device will sometimes be referred to as the "FI identity provider D-FI device".

[0096] Similarly, the D-FS device for controlling access to a service will sometimes be called a "D-FS service delivery device".

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

[0098] Similarly, instead of saying "DX device," one can simply say "X." In other words, the service provider FS can refer to the D-FS device, the identity provider FI can refer to the D-FI anonymous credential management device, and the user U can refer to the D-USR service access request device.

[0099] The D-FI anonymous accreditation management device has a public key pair (PKpPK'j) and an associated private key {sk^.

[0100] The user device D-USR has a public and private key pair (PK, sk) to enable its authentication with the identity provider FL. In the embodiment described here, these keys are stored in a secure element SE.

[0101] The D-FI credential generation device is configured to, after authenticating a user U, obtain at least one cryptographic representation of an attribute a< of the user and obtain an issuer signature calculated using the private key SKi of said identity provider and bearing at least on (a) said at least one cryptographic representation; and on (b) a public key PK of the user (U)-

[0102] The D-FI device then sends to user U a VC credential comprising at least (i) said ^issner signature, (ii) a user PK public key and (iii) said at least one cryptographic representation

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

[0104] In the described embodiment, the user U's D-USR device includes 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 credential (VC) issued by an identity provider (FI), to generate an anonymized signature, for example the signature <T^^ret pour générer une présentation vérifiable to be presented to the FS service provider to access a service while protecting the confidentiality of its attributes.

[0105] In one embodiment, the secure element SE is configured to calculate a proof of knowledge of a user's private key.

[0106] In the embodiment described here, the D-FI device for generating an anonymous verifiable credential includes a C0M1 communication module. This module can, in particular, be used by the D-FI device to communicate with the user D-USR for authentication purposes and to send them a VC credential.

[0107] In the embodiment described here, the D-FI device includes an M-CRY1 cryptographic module. This module can notably be used to authenticate a user, calculate hashes, signatures and proofs.

[0108] In the embodiment described here, the D-FS device for controlling access to a service by a user includes an M-LS module to determine which attributes of a user must be checked before allowing them to access a service, to check if the attributes obtained actually satisfy the logic of the service and, if so, to allow access to the service after verifying at least one proof of the validity of an accreditation of the certification of these attributes.

[0109] In the embodiment described here, the D-FS device includes a COM2 communication module. This module can notably be used by the device to request attributes from the user, obtain these attributes or information enabling the user to obtain these attributes, and obtain a verifiable presentation including accreditation on a user's attributes, send a message to the user to inform them of an authorization of access or the refusal of access to a service.

[0110] In the embodiment described here, the D-FS device includes an M-CRY2 cryptographic module configured in particular to calculate digests, verify proofs and signatures.

[0111] Fig. 3 represents in flowchart form the main steps of a process for issuing a verifiable accreditation implemented by the identity provider FI.

[0112] During step 12, the identity provider FI defines the public parameters of the signature system: A where: ? ë pp = \G } G2,G T ,e, p,n, g, g^, g2, ... , g n , g, f)

[0113] - where G;G2, Gt are three cyclic groups of order p and a bilinear coupling of G]XG2 in GT, for which we will assume that the q-SDH problem is difficult.

[0114] - p is a prime integer that denotes the order of the group G

[0115] - n the number of attributes to be certified

[0116] -g, g$ g? gy g denote n+3 generators of the group G chosen randomly (in such a way that no one knows the discrete logarithm of one of these generators with respect to another of these generators). Each "fgl" is associated with a specific type of attribute (for example, will be associated with the attribute "name", S2 with the attribute "first name", ^4 with the attribute "age", ^4 with the attribute "gender", etc.). This will allow us to differentiate the attributes and avoid any ambiguity.

[0117] - f denotes a generator of G2.

[0118] The n+3 generators of the group G are chosen randomly such that no one knows the discrete logarithm of one of these generators with respect to another of these generators.

[0119] In the embodiment described here, each {g.}” is associated with a specific type of attribute (for example S1 will be associated with the attribute “name”, S2 with the attribute “first name”, S3 with the attribute “age”, S4 with the attribute “gender”, etc.).

[0120] In the following, all calculations involving exponents will be carried out modulo P (mod P).

[0121] During a step 14, the identity provider FI defines the public data specific to the type of accreditation (for example, the digital identity document).

[0122] In the embodiment described here, this public data comprises: - a public key for each of the n types of attributes, i.e., ÏK-]n , these public keys are intended to be used for all VC credentials issued by the identity provider FI; - an integer Aô randomly drawn from Zp, - a HIDi digest identifier for each of the n attribute types, i.e. {HID:}n, and 1 'J 1=1 - an IDa identifier for each of the attribute types, i.e. {IDai}n .

[0123] During a step 16, the identity provider FI generates a private key skj and an associated public key (PK^ P^'i).

[0124] In the embodiment described here, the private key skI belongs to 2, p} and the associated public key is the pair (PKb PK'^ with PKj = gsk' and PK'j = f^1-

[0125] In the embodiment described here, the identity provider FI also generates a zero-knowledge proof fl = PoK . pg _ ~a pj^, _ that its key pair (PK^ PK'i) has indeed been generated.

[0126] It is now assumed that the identity provider FI wishes to generate a VC credential for the attributes of a user C.

[0127] We denote (sk, PK = g^) a private / public key pair of this user.

[0128] In the embodiment described here, the private key sk is stored in the secure element SE.

[0129] During a step 18, the identity provider FI sends a challenge (message) ch to the user C.

[0130] User U generates a proof ~ SoK{a: PK = g^jÇch) of knowledge of his private key authenticating the challenge ch.

[0131] In the embodiment described here, the Ku proof is 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)).

[0132] User U sends to the identity provider FI their public key PK and proof

[0133] In the embodiment described here, if the identity provider FI does not authenticate user U on the basis of this information, the result of a test 19 is negative and the process stops.

[0134] If authentication succeeds, during a step 110, the identity provider FI calculates, using a cryptographic hash function H, a cryptographic representation in Zp for each of the attributes a<.

[0135] In the mode described here, this cryptographic representation is a hash calculated by a function H and is for example in accordance with the SHA-256 protocol.

[0136] In the embodiment described here, the cryptographic representation Hj of an attribute ai is more precisely calculated from the hash identifier HlDh of the attribute identifier of the value of this attribute ai and the public key Kt associated with the type of this attribute during the creation of the identity document:

[0137] Hj = ï^hid. || IDai || has; ||

[0138] This representation conforms to ISO / IEC 18013-5. Other representations may be used in other embodiments of this disclosure.

[0139] During a step 112, the identity provider FI calculates a digital signature ^issuer using its private key SKh on a data structure H comprising the user's public key PK and the n digests H{. It saves this signature ^issuer

[0140] H = PK || H, || #J| ... Il# tl 1 II ± O 11 n

[0141] In the embodiment described here, the signature scheme used conforms to the BBS+ protocol.

[0142]

[0143]

[0144]

[0145]

[0146]

[0147]

[0148]

[0149]

[0150]

[0151]

[0152]

[0153]

[0154]

[0155] e is a value chosen randomly from and , „ 't' / T~r** TT By setting _ „ ' A^ - B and therefore Ask' = B A6 We designate _ ^ski _ 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. Traoré, "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 114, the identity provider FI generates a zero-disclosure proof of knowledge nz to prove that it knows such that C = AaKPK^ga- n7 = PoK ; c = A pKi = In the embodiment described here, the VC accreditation is constituted (step 116) by the user's PK public key, the {Hj}" digests, and the ^issuer signature on this data: VC = (PÆ. = The secret data associated with this VC accreditation is the user U's private key sk. During step 118, the identity provider FI sends the VC accreditation and the proof H / to user C. During a U20 step, user U calculates _ „ p^TT” vP ■> C = B A6 and verifies the validity of the proof H / . If the proof is validated, user C stores in their digital identity wallet WAL, the VC accreditation including their attributes {« / } " ! and their public key PK. In one embodiment, the user knows their attributes and it is not necessary for the identity provider to send them back to them. Alternatively, the identity provider sends them back to the user to allow the latter to verify that the identity provider and he / she share the same information (i.e. to verify for example that the identity provider has not misspelled his / her last name).

[0156] Fig. 4 represents in flowchart form the main steps of a process for requesting access to a service implemented by the user U and the main steps of an access control process implemented by the service provider FS.

[0157] In accordance with this disclosure, user U uses for this purpose a verifiable VP presentation generated from one or more VC credentials by at least one FI identity provider.

[0158] For the sake of simplicity, it is assumed that the verifiable presentation VP only includes one VC accreditation.

[0159] We will denote by A the list of indices of the attributes { a; ] . claimed 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 ai, as, a7 and therefore that A={1, 5, 7}.

[0160] In the embodiment described here, for each attribute not belonging to A, user C will send the value A8 to the service provider FS.

[0161] During a U20 step, user U connects anonymously to the service provider FS.

[0162] During an S22 step, the service provider sends user U the list A of attributes that he must check to give access to his service and a random value (nonce) specific to the session to avoid replays of verifiable presentations.

[0163] In a preferred embodiment, this request is authenticated, in other words signed by the FS service provider.

[0164] During a U24 step, the user calculates an anonymized public key PKBIind from his public key PK = gsk so that neither the service provider FS nor the identity provider FI can trace him from his public key.

[0165] For this purpose, the user U randomly chooses an integerr in Zp and calculates a Pedersen-style pledge of his private key sk; PKB]ind = gsk+r.

[0166] During a step U26, user U calculates an anonymized signature <7^”^. from the signature issued from his VC accreditation, to also prevent the service provider FS or the identity provider FI from tracing him from this signature element, and “adapt” it so that it relates to the anonymized public key PKB!ind and the {Hj]nj (and not to PK and the attribute digests [HJ” .

[0167] To this end, in the embodiment described here, the user C chooses integers q, r2 e Zp and then calculates:

[0168] A -eas^i B = ADA r3 = r](mod p) n™Mity= PO K| gr | : B = A a D *

[0169] This proof n^-^y 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:

[0170] . r'et B^AD

[0171] We then define B, D,

[0172] Alternatively, proof 11^ / / ^, may correspond to: PoKj « sfi : _ a -a = vtt / ïl where V4 a Wii^B = ADAF°PKaini = OTU*? a 5 * 01mod pI

[0173] During a step U38, the user C calculates, using a random number r and their private key sk, a knowledge signature aUser on a set of data, called "DeviceAuthenticationBytes" in the ISO / IEC 18013-5 standard and denoted mDAB hereafter: ap^d = SoK{a : PKB{ind = HiHdab)

[0174] 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 disclosed to the service provider as well as other contextual data).

[0175] The signature °uær is a signature of knowledge of the discrete logarithm of PKBlintl in the basis

[0176] In a particular embodiment, the ECSchnorr algorithm is used for this signature. Any other algorithm that proves knowledge of the private key sk can also be implemented, in particular the ECDSA algorithm in the context of SSL self-sovereign identity mechanisms.

[0177] In one embodiment of this disclosure, the secure element SE may not be able to: - to anonymize his own (step U24) his public key (for example calculate PKBiind = gsk+r) and / or; - to anonymize his own private key (step U26) (for example, calculate skstînd = sk + r{mod p)); and / or - to calculate itself (step U38) the proof of knowledge of the anonymized private key sk + r (mod p), that is to say a signature aÿ^de knowledge of the discrete logarithm of PK-bim in the base g.

[0178] We explain below how the secure element SE and the mobile WAL application associated with this SE can jointly anonymize the PKBlind public key and calculate the °user signature.

[0179] It is recalled that in the embodiment described here, only the secure element SE knows the private key sk associated with the public key PK of the user.

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

[0181] The calculation of the signature aBlind — $oK{a ' PKB1 ( could be carried out from in the following way:

[0182] a / The secure element SE calculates a knowledge signature (denoted °) of the discrete logarithm of PK in the base § (i.e., of the private key sk); aUse,-SoK{a: PK = g«J(mDAB)-

[0183] In one embodiment, the ECSDSA algorithm can be implemented as follows for calculating this signature: the secure element SE: i / generates a random number ii / calculate T = g«, c = H(T || and iii / calculate P = w + c sk (mod P) where H denotes a cryptographic hash function (SHA-256 for example).

[0184] The signature ° consists of the pair (c, P): _(cp(.

[0185] It is valid if c = H( gp x PKC, niDAB ) — C and invalid otherwise.

[0186] b / the WAL application: i / chooses a hazard1 ii / calculates PKBiind = gr x PK = gsk+r, and iii / calculates PBîmd = p+cxr = œ + cxsk + cxr = w+Cx(sk + r)(modP).

[0187] The signature (c, PBlind) is a valid ECSDSA signature on mDAB relative to the public key PKBhnd.

[0188] In this embodiment, the secure element SE calculates the proof ^uær of the knowledge of the user's private key, the proofs Q^suer and Qu™1 being calculated jointly by said secure element SE by the WAL application of said terminal.

[0189] Thus, the secure element SE performs simple operations (no bilinear coupling to be performed and only scalar multiplication on elliptic curve to be performed) while the signature is calculated by the dedicated WAL mobile application of his mobile phone.

[0190] In a second embodiment, we will assume that the secure element SE supports the classic ECDSA digital signature algorithm.

[0191] The calculation of the signature = SoK{a • pk^ = g«}(mDAB) can be carried out as follows and the ECDSA algorithm can be implemented for the calculation of this signature:

[0192] a / the WAL application:

[0193] i / calculates a data point M _ pi x mod and

[0194] ii / transmits the data M to the SE

[0195] b / the secure element SE:

[0196] i / chooses a random k ^Zp

[0197] ii / calculates gk - j) and x = i (mod ^). Note that we are improperly using multiplication (instead of addition) to denote the group operation in G. The element gk is therefore indeed a point on the underlying elliptic curve. Also note that if x = 0 then the SE chooses a new random number k ^Zp and then recalculates gk = (yy) and x = i (mod ^) until x * 0.

[0198] iii / calculates xx) mod Note that if <70 - 0 then the SE chooses a new random number k G then recalculate gk = (yy), x = i (mod ^) and = k~\M + sk*x') until x * 0 and * 0.

[0199] iiii / transmits to the WAL application.

[0200] Once received, the WAL application calculates ct = r

[0201] The signature = (x, <7 ) is a valid ECDSA signature on mDAB relative to the PKBlind public key.

[0202] In this embodiment, the proof 17 of the knowledge of the user's private key as well as the proofs and 0®^ are calculated jointly by said secure element SE and by the WAL application of said terminal.

[0203] Thus, the secure element SE performs simple operations (no bilinear coupling to be performed and only scalar multiplication on elliptic curve to be performed) while the signature is calculated by the dedicated WAL mobile application of its mobile phone.

[0204] The verifiable VPHL selective disclosure presentation consists (step U40) of the identity provider's public key FI, the user's anonymized public key PKBlind, the {A§]. ., the set of data disclosed to the service provider FS (Adisclosed = {HIDJI IDj| aj| Kj. ), the cryptographic representations Hi and the signatures and ■

[0205] VPhl = (pKi, PK'„ PKB1„(, (A8) ieA, HwAow^lHIDil IDaJj a,)

[0206] The user transmits the verifiable VPhl presentation to the FS service provider during a U42 step.

[0207] During an S44 step, the service provider FS calculates _ h(hTT) || IDaj|| Sj || Kj) for each i G A.

[0208] He then verifies that:

[0209] i / HL = 1¾ for each ig A€ ;

[0210] ii / is a valid signature on mDAB, in other words, the service provider FS can reconstruct it using the PKBiind public key certified by the identity provider FL. The ECSchnorr or ECDSA algorithm for verifying this SoK (QnKlrY • PL — ï) being known to those skilled in the art, we do not [refer to it]. LrvBHnd-g / (1¾ ab / We will not go into detail in this document.

[0211] iii / is a valid signature on PKBUnd, [FL} and {H', = Aô}, using the FL's public key. To do this, it must first ensure that the following equality is satisfied: e(A, PKj) = e(B, i) (if the FI has implemented the version of BBS+ using bilinear couplings), and secondly, that the `nvajidity` proof is valid. The algorithm for verifying this `nvajidity` proof is known to a person skilled in the art. Alternatively, it can ensure that the following equality is satisfied and on the other hand, that ïïvaiùuty is valid.

[0212] If all these conditions are met, it is demonstrated that the requested attributes [ai} ieA have indeed been certified by the identity provider FI and that the verifiable presentation VP does indeed originate from the user U whose attributes are the requested attributes (¾). The service provider FS allows the user U 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).

[0213] The mechanism presented above is very advantageous because neither the service provider FS nor the identity provider FI can trace the user U,

[0214] Moreover, the selective disclosure method is in accordance 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 customers.

[0215] In the embodiment described above, the user U does not need to be connected to generate a verifiable VP presentation. Similarly, the service provider FS does not need to be connected to generate and verify a verifiable VP presentation, respectively. This mode, which can therefore be described as offline (HL), corresponds to a VP verification mode proposed, in particular, by the ISO / IEC 18013-5 standard.

[0216] The ISO / IEC 18013-5 standard provides for 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 [Fig. 1].

[0217] 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, user C receives a token from the identity provider attesting that he / she is verifying the conditions of access to the service provider FS.

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

[0219] We will now describe a particular embodiment of this disclosure compatible with the SHL mode of ISO / IEC 18013-5 but in which the identity provider FI is unable to identify with which service provider FS a user U uses its tokens.

[0220] We are in the situation in which the user U has received a VC = (A, e) accreditation from the service provider as described with reference to [Fig.3].

[0221] With reference to Figure 5, user C calculates an anonymized PKBünd key from their public key PK = gsk and an anonymized value <7^^. of the signature issued from their VC accreditation. These steps are similar to steps U24 and U26 described with reference to [Fig. 4].

[0222] During a step U28, user C tries to obtain from the identity provider FI, by contacting it directly, a proof (SoK) that B = ^ski where _ aJ1*'2-

[0223] In a particular embodiment this proof is obtained blindly, which means that the identity provider FI, although having contributed to generating this proof (he alone knows dqy), will be unable in the presence of such proof KeQ to determine which user it was intended for. K 1 )' cryptographic representations 1J ieA ^disclosed {HIDj | HAl || â

[0224] 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).

[0225] During a step U38 similar to the step U38 already described with reference to Figure 4, the user U calculates, using a random number and his private key sk, a knowledge signature relating to a set of mDAB data. = SoK {a: PKBlind = g«} (mDAB)

[0226] The verifiable presentation V?shl consists (step U400) of the identity provider's public key FI, the user's anonymized public key PKBlind, the [AS}. A, and all the data disclosed to the service provider FS i signatures and (7^™? and proof VPSHL =(PKp PK'>> {A3). H,, A = | HIDi || IDa, || a| | K, ) . disclosed

[0227] The user transmits the verifiable presentation VP to the FS service provider during a U420 step.

[0228] During an S440 step, the FS service provider calculates _ FT(HTD || IDaJ aj| Ko for each ie A.

[0229] He then verifies that:

[0230] i / H'i = H; for each i GA;

[0231] ii / aUser is a valid signature on mDAB

[0232] iii / is a valid signature on PKBUnd, {FL} and { Hj = Aô}. , using the FL public key. For this, it must first ensure that the ügQ proof is valid and that the nva}jdity proof is valid.

[0233] If all these conditions are met, the service provider FS allows user C 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).

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

[0235]

[0236]

[0237]

[0238]

[0239]

[0240]

[0241]

[0242]

[0243]

[0244]

[0245]

[0246] Figure 6 represents, in flowchart form, a protocol implemented between user U and identity provider FI by which identity provider FI can provide user U with proof (SoK) nEQ that B = ^ski where _ ^rixr2. In other words, this figure details step U28 of [Fig.5] in a particular embodiment of the present disclosure. We recall that the identity provider FI knows the signature &iSSuer = ( A e) calculated in step 112 on the public key PK and the attributes ai of the user U. During a step 150 similar to step 18, the identity provider FI sends a challenge (message) ch to user U, User U generates a SoK proof (a: PK = ga) of knowledge of their private key authenticating the challenge ch, for example using the algorithm called ECSchnorr or ECDSA User U sends their public key PK and proof 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 151 test is negative and the process stops. If authentication succeeds, during step 152, the identity provider FI calculates a cryptographic representation in Zp for each of the a< attributes of user U. This step is similar to step 110. By setting = PK^]" Hi, we have = We designate £ _ ^ski _ During step 154, the identity provider FI chooses a value5 randomly from Z* and calculates Ao = gs and calculates Bo = As The identity provider FI sends the values ​​A) and Bq to the user U (step 156). During a U58 step, user U chooses two random values ​​v from Zp and calculates: , \u Ao = (AoxgF) c=h(Â||b| LII4.II»> dab ) cQ = du (mod p) The user sends the value to the identity provider FI during a U60 step.

[0247] During step 162, the identity provider FI calculates r0 = s + c0 x skj (mod p) and sends value r0 = 5 + c0 x skj (mod p) to user U.

[0248] During a step U64, user U calculates:

[0249] r = (r0 + v) u (mod p)

[0250] The proof ^EQ is equal to: K = ( Â, B, C. r ).

[0251] This is a valid proof (SoK) on the mDAB message if:

[0252] c'=h(Â||b|| f xPKilÂVB'lm \ hu & i fi u DAB;

[0253] Each of the D-USR, D-FI and D-FS devices described above can be implemented by an ORD computer whose hardware architecture is shown in [Fig.7].

[0254] This computer ORD includes in particular a processor 10, a random access memory 11, a read-only memory 12 and means of communication 13.

[0255] The read-only memory 12 constitutes a recording medium within the meaning of the invention. It includes a PG-X computer program according to the invention.

[0256] For the D-USR device, this PG-X computer program is a PG-USR program comprising 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.

[0257] For the D-FI device, this PG-X computer program is a PG-FI program comprising instructions to execute the steps of an accreditation generation process as described above 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 C0M1 module of the D-FI device.

[0258] For the D-FS device, this PG-X computer program is a PG-FS program comprising instructions to execute the steps of a service access control process as described above 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 communication module of the D-FS device.

Claims

Demands

1. A method for requesting access, implemented by a user's device (pj), to request access to a service provided by a service provider (SF), said method comprising the following steps: - receiving (118), from an identity provider (IF), a VC credential and proof üj of the validity of the VC credential, said VC credential comprising at least: (i) a cryptographic representation Hj of an attribute (p) of the user; (ii) a public key PK of the user and (iii) a signature ^issuer calculated using a private key of said identity provider and relating at least to: (a) said at least one cryptographic representation Hj and (b) said public key (PK) of the user (p), - verification of said proof Hj;- receiving (S22) a list (A) of at least one attribute to be revealed to said service provider (FS) in order to access said service - calculation (U24, U26) of an anonymized public key PKBünd of the user (p) from said public key PK, of an anonymized signature from the signature alssuer and of a proof (U38) of knowledge of an anonymized private key of the user associated with said anonymized public key PKBJind from a proof of knowledge of a private key of the user, said proofs a, and being calculated jointly by a secure element (SE) of a user terminal and an application (WAL) of said terminal;- sending (U42, U420), to said service provider (FS), of a verifiable selective disclosure presentation including at least: (aa) an identity provider's (IF) public key, (bb) the user's anonymized public key PKBimd, (cc) at least one attribute to be disclosed (a) to access said service, (dd) a cryptographic representation Hj of said at least one attribute to be disclosed (a), (ee) said anonymized signature and; (ff) said proof

2. A method for requesting access according to claim 1, further comprising a step (U28) of obtaining proof of validity of said anonymized signature provided by said identity provider (IF), said verifiable selective disclosure presentation further comprising said proof of validity.

3. 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 (jj) of said device (D-USR) with an identity provider (FI); - a module (COM3) for obtaining, from said identity provider (FI), a VC credential and proof II] of the validity of said VC credential, said VC credential comprising at least: (i) a cryptographic representation H, of an attribute of the user (ii) a public key PÂ" of the user (uy, and (iii) a digital signature calculated using a private key (SK / ) of said identity provider and relating at least to: (a) said at least one cryptographic representation H / and (b) said public key (PK) of the user ([f, - a module (WAL) for verifying said proof H];- a module (COM3) for receiving a list (A) of at least one attribute to be revealed to said service provider (FS) in order to access said service; - means (SE, WAL) for calculating an anonymized PKBlind public key of the user (jf) from said public key PK^, for calculating an anonymized signature from the issuer signature, and for proof of knowledge of an anonymized private key of the user associated with said anonymized PKBlind public key from proof of knowledge c of a private key of the user; - a module (COM3) for sending, to said service provider (FS), a verifiable presentation with selective disclosure comprising at least:; (aa) an identity provider's (IF) public key, (bb) the user's anonymized PKBIind public key, (cc) at least one attribute to be revealed (a) to access said service, xi (dd) a cryptographic representation H; of said at least one attribute to be revealed (a), (ee) said anonymized signature and (ff) said °user proof.

4. 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 claim 1 to 2.

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

Images