Methods and devices for controlling a user's access to a service by certifying and ensuring the confidentiality of that user's attributes
Patent Information
- Application Number
- FR2023011012
- Authority / Receiving Office
- FR · FR
- Patent Type
- Applications
- Current Assignee / Owner
- Filing Date
- 2023-10-13
- Publication Date
- 2025-04-18
- Estimated Expiration
- Not applicable · inactive patent
Smart Images
Figure 00000000_0000_ABST
Abstract
Description
Title of the invention: Methods and devices for controlling a user's access to a service by certifying and ensuring the confidentiality of the attributes of this user Prior art
[0001] The invention lies in the field of digital identity management. More specifically, the invention relates to a digital identity management method which preserves the privacy of users.
[0002] Many service providers, whether online or in a face-to-face relationship with the user, require the provision of user identity elements, more generally in order to deliver their service.
[0003] Traditionally, in a non-digital world, this provision of identity elements is carried out using (physical) documents issued by official authorities (identity cards, driving licenses, etc.) and supporting documents issued by recognized third-party certifiers (electricity bill, telecom bill, medical certificate, etc.).
[0004] The development of services accessible via the Internet requires the implementation of dedicated tools allowing the digitization of elements present on the aforementioned media, possibly in a structured manner and authorizing their sharing with the service provider, after consent from the user.
[0005] The major prescribers on the Internet have until now structured the field of digital identity management in line with their business model. They have, for example, through the OIDC (OpenID Connect) protocol, developed an offer that centralizes the user's identity elements and, under its control, after identification / authentication and consent of the user, authorizes the service's access to all or part of the user's identity elements. One of the main problems with this type of architecture, known as Federated Identity, 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 he is accessing.The identity provider is thus able to compile the history of the user's access activities and identity elements required by the various services they have visited. This data then allows it to build a profile of the user's service consumption with the service providers and to use it for often commercial purposes.
[0006] Self-sovereign identity (SSI) is another approach to digital identity, which gives users full control over their assets identity: they can present them when accessing a service either to prove who they are or one of their qualities. Only the service provider and the user interact during the identity element sharing phase. In order to generate trust between the user and the service, the user presents identity elements that have been certified by a third party (the identity provider) that the service provider trusts. In this logic, the user holds identity elements concerning him, which have been issued and certified by one or more trusted entities, controls their dissemination to the service provider (after consent) and protects his privacy vis-à-vis the identity provider by excluding it from the relationship he has with the service provider.
[0007] The use of cryptographic methods such as "Zero-Knowledge Proof" (ZKP) would also allow a user to also protect his privacy vis-à-vis the service provider: thanks to these mechanisms, he could thus choose to reveal to the service provider only part of his identity elements, while proving that these are certified, or even convince him that they verify certain properties still without revealing them (for example, proving that "he is an adult" without it being necessary for him to reveal his date of birth).
[0008] However, this anonymity makes it difficult to monitor and analyze the use of such dematerialized identity documents: in fact, identity providers are completely unaware of how the certificates they issue are used.
[0009] The disclosure below proposes a mechanism making it possible in particular to monitor the use of dematerialized identity documents which does not have the aforementioned drawbacks. Subject matter and summary of the invention
[0010] Generally speaking, the present disclosure relates to three entities: (1) a service provider who wishes to verify certain attributes of a user before delivering the service and to be certain that its attributes are certified; (2) an identity provider capable of certifying a user's attributes and which wants visibility into the use of the credentials it issues; (3) a user who wishes to maintain confidentiality regarding the services they access.
[0011] The present disclosure proposes a mechanism in particular in which the identity provider certifies attributes of the user, the user only reveals to the service provider the attributes necessary to access the service, the service provider can ask the identity provider to provide proof of the certification of these attributes, the identity provider being unable to determine either the service provider requesting this proof, or the user concerned.
[0012] Thus, and according to a first aspect, the present disclosure relates to a method for managing at least one anonymous verifiable accreditation, this method being able to be implemented by an identity provider and comprising the following steps: - user authentication; - obtaining at least one attribute of the user; - generation of an anonymous verifiable accreditation relating to at least said at least one attribute of the user, said accreditation being a blind signature calculated using a private key of the identity provider; and - sending said accreditation to said user.
[0013] Correlatively, the present disclosure also relates to a device for managing at least one anonymous verifiable accreditation, this device comprising: - a user authentication module; - a module for obtaining at least one attribute of the user; - a module for generating an anonymous verifiable accreditation relating at least to said at least one attribute of the user, said accreditation being a blind signature calculated using a private key of the identity provider; - a module for sending said accreditation to said user.
[0014] Thus, and in general, the identity provider can generate, after having authenticated a user, an accreditation, in other words certify or attest that attributes of this user are valid.
[0015] These attributes can be public attributes, for example sovereign (surname, first name, date of birth, address, etc.).
[0016] In a particular embodiment, the user may also wish for the accreditation to relate to a secret attribute, for example a secret key of the user.
[0017] In which case, the user does not provide the secret attribute as such but a commitment (or pledge) on this secret attribute. The pledge schemes are mechanisms known to those skilled in the art of cryptography and will be recalled below.
[0018] It is recalled that accreditations are personal attestations allowing a user to convince a third party that he or she has a particular authorization or qualification. They are specific to an individual and generated by a trusted entity, via the use of digital signatures. However, standard digital signature mechanisms require revealing the entirety of the certified data, even to prove the authenticity of only part of it, and allow users to be traced.
[0019] In the present disclosure, an anonymous credentialing mechanism is used as introduced by Chaum (David Chaum: Showing Credentials Without Identification: Signatures Transferred Between Unconditionally Unlinkable Pseudonyms. EUROCRYPT 1985: 241-244 ). Such a system allows a user to prove that his attributes (name, first name, date of birth, address, gender, etc.) have been certified, without revealing superfluous information.
[0020] Very advantageously, it should be noted that the identity provider generates the accreditation using a blind signature calculated with its private key so that only this identity provider will be able to verify its validity.
[0021] In a particular embodiment, the blind signature is a message authentication code with a group structure, known to those skilled in the art as an algebraic MAC. It is recalled that a MAC is a cryptographic primitive that allows messages to be authenticated but where a single secret key is used both for its generation and its verification. This primitive therefore differs from the digital signature which can be verified by everyone, using a public key.
[0022] In a particular embodiment, the present disclosure uses more precisely the anonymous accreditation scheme with key verification proposed by Barki et al. in the document Amira Barki, Solenn Brunet, Nicolas Desmoulins, Jacques Traoré: Improved Algebraic MACs and Practical Keyed-Verification Anonymous Credentials. SAC 2016: 360-38. This is based on the algebraic MACs scheme, noted MACBbs+, introduced by the same authors in the same document.
[0023] This scheme is particularly advantageous in the context of the present disclosure, because the successive use of the same accreditation cannot be detected, which avoids any risk of tracing. It also makes it possible to certify certain attributes without revealing them, this signature scheme making it possible to sign pledged messages and on the other hand to effectively prove knowledge of a signature without revealing it.
[0024] The present disclosure could however rely on other anonymous accreditation systems with key verification, such as that proposed by Melissa Chase, Sarah Meiklejohn, Greg Zaverucha: Algebraic MACs and Keyed-Verification Anonymous Credentials. CCS 2014: 1205-1216 or on that introduced more recently by Camenisch et al (Jan Camenisch, Manu Drijvers, Petr Dzurenda, Jan Hajny: Fast Keyed-Verification Anonymous Credentials on Standard Smart Cards. SEC 2019: 286-298).
[0025] In a particular embodiment, the management method further comprises calculating proof of the validity of the verifiable accreditation and sending said proof to the user.
[0026] This proof allows the user to be convinced of the validity of the accreditation.
[0027] In a particular embodiment, the proof is a proof with a designated verifier, so that only the user can be convinced of the validity of the accreditation.
[0028] The zero-knowledge proof mechanism is a mechanism known to the person skilled in cryptography and is recalled below.
[0029] As mentioned previously, only the identity provider is capable of verifying the validity of an accreditation. This verification request may in particular be made at the request of a service provider who wishes to verify that the attributes presented to it by a user are certified.
[0030] Thus, in a particular embodiment, the management method further comprises the steps of: - anonymous receipt, from a service provider, of a verifiable presentation comprising an anonymous verifiable accreditation relating to at least one of the attributes of a user and a group signature of this presentation; - verification of the validity of said group signature; - verification of the validity of the anonymous verifiable credential using said private key of the identity provider, and if successful, generation of a proof of the validity of said credential; - sending said proof of the validity of the anonymous verifiable accreditation to the service provider only if said group signature has been determined to be valid.
[0031] Very advantageously, by using a group signature, the identity provider is not able to identify the service provider that originated the verification request, but only to ensure that this service provider belongs to a group of authorized service providers. This mechanism allows the identity provider to control the use made of the credentials it produces.
[0032] The group signature mechanism is a mechanism known to those skilled in the art of cryptography and is recalled below.
[0033] In a particular embodiment, the anonymous verifiable accreditation included in the verifiable presentation is not identical to that generated by the identity provider but a refresh thereof. This refresh relates to the same attributes (secret or public) but does not allow a comparison to be made with the generated accreditation. Thus, the identity provider cannot identify the user for whom the service provider requests to verify the attributes.
[0034] In a particular embodiment of the management method, the verifiable presentation further comprises a zero-knowledge disclosure proof demonstrating that the user knows how to reveal a pledge on said at least one attribute and that the verifiable anonymous accreditation is valid on said at least one pledged attribute, said method comprising: - a step of verifying the validity of said proof; - said proof of the validity of the anonymous verifiable accreditation being sent to the service provider only if said zero-knowledge proof has been determined to be valid.
[0035] This embodiment is particularly advantageous because it prevents the user from giving his accreditation to a third party.
[0036] According to a second aspect, the present disclosure also relates to an access request method, implemented by a user's device, to request access to a service provided by a service provider, said method comprising the following steps: - authentication of the user with a management device of at least one anonymous verifiable accreditation; - sending at least one user attribute to said management device; - obtaining an anonymous verifiable accreditation relating to said at least one attribute of the user, said accreditation being a blind signature calculated using a private key of said management device; - calculation of an anonymous verifiable accreditation refreshed from said accreditation; - sending, to said service provider, a verifiable presentation comprising at least said refreshed accreditation and information enabling the service provider to obtain at least one attribute of said user requested by said service provider.
[0037] Correlatively, the present disclosure also relates to a device for requesting access to a service provided by a service provider, said device comprising: - a module for authenticating a user to a device for managing at least one anonymous verifiable accreditation; - a module for sending at least one attribute of the user to said management device; - a module for obtaining anonymous verifiable accreditation relating to said at least one attribute of the user, said accreditation being a blind signature calculated using a private key of said management device; - a module for calculating an anonymous verifiable accreditation refreshed from said accreditation; - a module for sending, to said service provider, a verifiable presentation comprising at least said refreshed accreditation and information enabling the service provider to obtain at least one attribute of said user requested by said service provider.
[0038] Thus, once the user has obtained accreditation on his attributes, he can generate a verifiable presentation comprising one or more accreditations according to the attributes requested by the service provider.
[0039] Very advantageously, by using in this verifiable presentation a refresh of the signature received from the service provider, the user ensures that the service provider who will attest to the validity of these attributes will not be able to identify him.
[0040] In one embodiment of the access request method, the verifiable presentation comprises a pledge on all of the user's attributes, said information comprising opening data making it possible to open only said at least one attribute requested by said service provider.
[0041] According to a third aspect, the present disclosure relates to a method for controlling access to a service by a user, said method being implemented by a service provider and comprising the following steps: - obtaining a verifiable presentation including anonymous verifiable accreditation relating to user attributes; - obtaining information enabling the service provider to obtain at least one of said attributes and verifying said at least one attribute; - signing said verifiable presentation with a group private key to obtain a group signature; - anonymous sending, to a device configured to validate said accreditation, of said verifiable presentation and said group signature; - a positive result of a verification of said at least one attribute and obtaining proof of the validity of said accreditation being necessary conditions for authorizing the user's access to said service.
[0042] Correlatively, the present disclosure relates to a device for controlling access to a service by a user, said device comprising: - a module for obtaining a verifiable presentation comprising anonymous verifiable accreditation relating to user attributes; - an information obtaining module allowing the service provider to obtain at least one of said attributes; - a module for verifying said at least one attribute; - a module for signing said verifiable presentation with a group private key to obtain a group signature; - a module for sending, anonymously, to a device configured to validate said accreditation, said verifiable presentation and said group signature; - a module configured to authorize the user's access to said service at least if a verification of said at least one attribute is positive and if proof of the validity of said accreditation is obtained.
[0043] In one embodiment of the access control method, the verifiable presentation further comprises a zero-knowledge proof demonstrating that the user knows how to reveal a pledge on said attributes and that the verifiable anonymous accreditation is valid on all the pledged attributes, said method comprising: - a step of verifying the validity of said proof; - a positive result of said verification being a necessary condition to authorize the user's access to said service.
[0044] The present disclosure thus proposes a new hybrid architecture for digital identity between those of federated identity and that of decentralized identity introduced in the preamble: just as for decentralized identity, the user will retain total control of his identity elements, on the other hand, and like federated identity, the service provider will have to delegate the verification of the validity of a verifiable presentation to the identity providers having issued the anonymous accreditation(s) used in this presentation since only the identity provider having issued an accreditation will be able to verify the verifiable presentations based on this accreditation.
[0045] On the other hand, verifiable presentations are completely anonymous for identity providers, so they will not be able to establish users' service consumption profiles. Furthermore, verifiable presentation verification requests are signed anonymously by the service providers. Identity providers cannot identify either the service providers that originated these verification requests or the user that originated the verifiable presentations.
[0046] The invention also relates to a computer program comprising instructions for executing the steps of the method for managing at least one anonymous verifiable accreditation when said program is executed by a computer.
[0047] The invention also relates to a computer program comprising instructions for executing the steps of the method of requesting access to a service when said program is executed by a computer.
[0048] The invention also relates to a computer program comprising instructions for executing the steps of the method for controlling access to a service when said program is executed by a computer.
[0049] 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.
[0050] The invention also relates to a computer-readable information medium, and comprising instructions of a computer program as mentioned above. The information medium may be any entity or device capable of storing the program. For example, the medium may comprise a storage means, such as a ROM, a non-volatile memory of the flash type or a magnetic recording means, for example a hard disk. On the other hand, the information carrier may be a transmissible medium such as an electrical or optical signal, which may be conveyed via an electrical or optical cable, by radio or by other means. The program according to the invention may in particular be downloaded from a network such as the Internet. Alternatively, the information carrier may be an integrated circuit in which the program is incorporated, the circuit being adapted to execute or to be used in the execution of the method in question. Brief description of the drawings
[0051] Other characteristics and advantages of the present invention will emerge from the description given below, with reference to the appended drawings which illustrate exemplary embodiments thereof which are not in any limiting nature. In the figures:
[0052] [Fig-1] [Fig.l] represents a system comprising a device for managing at least at least one anonymous verifiable credential, a service access request device and a service access control device in accordance with particular embodiments of the present disclosure;
[0053] [Fig.2] [Fig.2] represents in the form of flowcharts steps of a process of managing at least one anonymous verifiable accreditation and a method of requesting access to a service in accordance with particular embodiments of the present disclosure;
[0054] [Fig.3] [Fig.3] represents in the form of flowcharts steps of a process of managing at least one anonymous verifiable accreditation, of a method of requesting access to a service and of a method of controlling access to a service in accordance with particular embodiments of the present disclosure;
[0055] [Fig.4] [Fig.4] represents the hardware architecture of the devices of [Fig.l] in a particular embodiment of the present disclosure.
[0056] As a preliminary matter, we recall cryptographic tools used in the present disclosure. Pledge schemes
[0057] Pledging a value is a cryptographic process allowing an issuer to commit to a value to a recipient without revealing it at first glance and in such a way that this commitment can no longer be modified subsequently. This value can, if necessary, be revealed subsequently by the issuer.
[0058] Thus, the recipient has the assurance that once the commitment is published, the issuer can no longer change his mind about the value contained in this commitment.
[0059] In the present disclosure, for example, a pledge scheme based on a hash function H is used. It is recalled that such a function is resistant to collisions: in other words, it must be difficult in practice to find two messages m and m' such that H(m) = H(m'). Such a function must also be difficult to invert: given a condensate C, it must be difficult in practice to find a message m such that C = H(m).
[0060] To commit to the recipient on an a priori secret value x, the sender chooses a random number 1 and calculates the commitment C = H(xjr) that it sends to the recipient. In doing so, the sender can no longer modify x because, otherwise, this would mean that it could have found another value (as well as another random number r') such that C = H(x|r'), which would contradict the hypothesis that the function H is collision-resistant.
[0061] If necessary, the transmitter can reveal the pair (x, r) to allow a third party to verify that C = H(x|r).
[0062] In a particular embodiment, the present disclosure may use the pledging scheme proposed by Pedersen in 1992 (Torben P. Pedersen. Non-interactive and information-theoretic secure verifiable secret sharing. In Joan Feigenbaum, editor, CRYPTO'91, volume 576 of LNCS, pages 129-140. Springer, Heidelberg, August 1992), which has the particularity of producing perfectly indistinguishable commitments (perfectly hiding in English). Zero-knowledge proofs
[0063] We recall that a so-called Zero-Knowledge Proof (ZKP) allows a verifier to convince himself that a certain prover knows a secret S satisfying a given predicate P, the proof revealing no information to the verifier about the secret S in question other than the fact that it verifies the given predicate P. Subsequently, to represent zero-knowledge proofs, we will sometimes use the usual notation PoK{ a, p, ... : predicate on a, p, ...} •
[0064] In some embodiments, the present invention further utilizes the designated verifier proof mechanism notably described in (Markus Jakobsson, Kazue Sako, Russell Impagliazzo: Designated Verifier Proofs and Their Applications. EUROCRYPT 1996: 143-154). Group signatures and anonymous signatures
[0065] In this disclosure, the service providers sign all their requests to the identity providers, without revealing their identity. To this end, the present disclosure proposes for example to use an anonymous signature scheme (variant of a group signature scheme), such schemes allowing a requester to prove its membership in a group (here a group of service providers) without revealing its exact identity. In particular, the group signatures have the particularity of being anonymous (the signatory cannot be identified) and untraceable (it is not possible to determine whether two signatures were issued by the same person or by two distinct people). The validity of a group signature can be verified by anyone using a public key characterizing the group (called the "group public key"). To be part of the group, a requester must register with a group manager. During this registration phase, the future member blindly obtains a group private key that will allow him to sign messages on behalf of the group. "Blindly" means in this context that the group manager does not know the private key obtained by the requester. As is well known, only a trusted authority (called a revocation authority or simply RA) has the power to revoke the anonymity of a group signature, thanks to a trapdoor (a private key) that only it possesses.In practice, this trap is shared between several trusted authorities (generally called revocation authorities) and it is necessary for them all to cooperate to lift the anonymity of a signature. The group member is thus protected against abusive lifting of anonymity.
[0066] In such a scheme, the group manager (MG) has a pair of keys, private and public (denoted (SKMG, PKMG)) and a digital signature algorithm. During the registration phase, the member of the group (denoted U) receives from the group manager MG a signature J on a public key PK generated for the occasion (of which only he knows the associated private key SK: _ [PK] ' group public key is PKMG. while user's private key is SK and his membership certificate is (PK^a).
[0067] To prove to a service provider or any other third party that he is indeed part of the group managed by MG, the user U encrypts his public key PK using the public key PKra of the revocation authority RA (C^ = Ep^^PK)), then encrypts a (C-, = EPKJa}) still with the public key PKRA. The user generates a zero-knowledge proof 77 demonstrating that he knows on the one hand the plaintext of Cx (i.e. PK) but also the private key corresponding to this plaintext (i.e. SK) and on the other hand that the plaintext of C2 (i.e. a) is indeed a signature of MG on the plaintext of C, (i.e. PK). The group signature is made up of (Cj, C2, Æ).
[0068] In a particular embodiment, the De-lerablée-Pointcheval group signature algorithm can be used (Cécile Delerablée, David Pointcheval: Dynamic Fully Anonymous Short Group Signatures. VIETCRYPT 2006: 193-210). For this algorithm, the revocation authority has a pair of keys from the El-Gamal encryption algorithm (El Gamal, T.: A public key cryptosystem and a signature scheme based on discrete logarithms. In: Blakely, GR, Chaum, D. (eds.) CRYPTO 1984. LNCS, vol. 196, pp. 10-18. Springer, Heidelberg (1985). Any other group signature scheme may, however, be implemented in this disclosure. Description of embodiments
[0069] We will now describe an example implementation of the present disclosure in which an identity provider (D-FI) generates an anonymous verifiable credential (7-) relating to attributes a^, an) of a user (D-USR), using his private key (sk^).
[0070] In this example, the user refreshes this credential (r) and sends the refreshed credential to a service provider (D-FS) in a verifiable presentation (VP) along with attributes requested by the service provider (D-FS).
[0071] In this example, the service provider (D-FS) signs the verifiable presentation (VP) with a group private key (sk^p) to obtain a group signature (^f) and anonymously requests the identity provider to validate the accreditation (t') of said verifiable presentation (VP) and said group signature (aRP).
[0072] In this example the service provider (D-FS) checks the validity of the requested attributes and waits for proof of the validity of the accreditation (r1) to authorize the user (D-USR) to access said service.
[0073] More particularly:
[0074] [Fig. 1] represents a system SYS comprising a D-FI anonymous accreditation management device implemented by an identity provider FI, a D-FS service access control device implemented by a service provider FS and a D-USR device implemented by a user USR to request access to said service.
[0075] To simplify the description, the anonymous accreditation management D-FI device will sometimes be referred to as the “D-FI device of the FI identity provider”.
[0076] Similarly, the D-FS device for controlling access to a service will sometimes be called a “D-FS device for providing a service”.
[0077] Similarly, the D-USR device for requesting access to a service will sometimes be called a “D-USR user device”.
[0078] Similarly, instead of saying “device DX” we can simply say “X”. In other words, the service provider FS can designate the D-FS device, the identity provider FI can designate the anonymous accreditation management device D-FI and the user USR can designate the service access request device D-USR.
[0079] The D-FI anonymous accreditation management device has a public and private key pair (PKh sk^.
[0080] In the embodiment described here, the service provider FS is part of a group of service providers, each member of the group having a private key of a group signature scheme. We will designate $kRP as the private key of the service provider FS and PKpp as the public key of the group of service providers.
[0081] The user's device D-USR has a pair of public and private keys (PKV, sky) to enable its authentication with the identity provider FI. In the embodiment described here, these keys ^PKu, sku) are stored in a secure element SE.
[0082] The anonymous accreditation management device D-FI is configured to, after having authenticated a user USR, issue an anonymous verifiable accreditation ' relating to at least one of the attributes ai of this user, for example secret attributes and / or public attributes, for example identity elements of this user. To simplify the description, the "anonymous verifiable accreditation T" will sometimes simply be called "accreditation r".
[0083] In accordance with this disclosure, to issue an accreditation r, the identity provider FI uses a cryptographic signature calculated from its private key sk[ (secret key). Thus, only the private key of the identity provider FI can confirm the validity of the accreditation r or any other element involving this accreditation '. Indeed, in accordance with this disclosure, the identity provider FI is the only one able to guarantee to a third party the validity of an element whose validity it has actually verified, by producing a zero-knowledge proof nox of the validity of this element. It will be noted in particular that the PKI public key of the identity provider FI does not allow the validity of an accreditation T produced by the identity provider FI to be verified.
[0084] In the particular embodiment described here, the secret key signature used by the identity provider FI to issue a verifiable anonymous credential T is a message authentication code with a group structure, known to those skilled in the art as an algebraic MAC scheme. The key pair (PK p skj) of the identity provider FI therefore conforms to such a scheme.
[0085] In a particular embodiment, the MAC_BBS+ signature algorithm already presented is used.
[0086] In the embodiment described here, the user's D-USR device comprises an M-AUTH module for authenticating the user to the D-FI device for managing at least one anonymous verifiable accreditation.
[0087] In the described embodiment, the D-USR device of the USR user comprises a WAL cryptographic module, for example an identity wallet electronic device configured to store at least one anonymous verifiable credential T issued by an identity provider FI and to generate a verifiable presentation VP to be presented to the service provider FS to access a service while protecting the confidentiality of its attributes.
[0088] The verifiable presentation VP includes an accreditation t' calculated by the user by refreshing the accreditation T.
[0089] In some embodiments, a verifiable presentation VP comprises several credentials t', each calculated by refreshing a credential T.
[0090] It will be assumed subsequently that the verifiable presentation VP only includes a single accreditation t',
[0091] The public key PK j of the identity provider FI can be used by the service provider FS to identify the identity provider FI capable of providing proof of the validity of this accreditation.
[0092] When the service provider FS requests the identity provider FI to validate an accreditation, it does so anonymously by signing the verifiable presentation VP using a group signature.
[0093] At least some of the user's attributes may be requested by the service provider FS to authorize the user USR to access a service. These are never disclosed to the identity provider.
[0094] In the embodiment described here, the WAL electronic wallet of the user device D-USR is configured to refresh a credential and generate the verifiable presentation VP with this refreshed credential.
[0095] In the embodiment described herein, the D-USR device comprises a COM3 communication module. This module can be used to send attributes ..., an user to the D-FI device, receive an anonymous verifiable accreditation T relating to these attributes, send to a service provider: -the verifiable VP presentation generated by the WAL module; and - information enabling the service provider to obtain at least one attribute of the user required to access the service.
[0096] In the embodiment described here, the D-FI device for managing at least one anonymous verifiable accreditation comprises a communication module C0M1. This module can in particular be used by the D-FI device to obtain the attributes üq, a„ je the user, send him an accreditation T, send proofs, receive a verifiable presentation.
[0097] In the embodiment described here, the D-FI device for managing at least one anonymous verifiable accreditation comprises a cryptographic module M-CRY1. This module can in particular be used to authenticate a user, generate and verify the validity of an anonymous verifiable accreditation T relating to attributes and under the form of a blind signature using the private key sk,, calculate proofs, verify signatures, including group signatures.
[0098] In the embodiment described here, the D-FS device for controlling access to a service by a user comprises an M-LS module for determining which attributes of a user must be verified before authorizing them to access a service, verifying whether the attributes obtained actually satisfy the logic of the service and, if necessary, authorizing access to the service after having verified at least one proof of the validity of an accreditation of the certification of these attributes.
[0099] In the embodiment described here, the D-FS device comprises a COM2 communication module. This module can in particular be used by the device to request attributes from the user, obtain these attributes or information allowing it to obtain these attributes, obtain a verifiable presentation comprising an anonymous verifiable accreditation relating to attributes of a user, send this accreditation and a signature of the presentation to an identity provider, obtain proof of the validity or invalidity of this accreditation.
[0100] In the embodiment described here, the D-FS device comprises a cryptographic module M-CRY2 configured in particular to sign said verifiable presentation with a group private key to obtain a group signature and to verify the validity of a proof.
[0101] Figures 2 and 3 represent in flowchart form the main steps of a method for managing at least one anonymous verifiable accreditation implemented by the identity provider FI, the main steps of a method for requesting access to a service implemented by the user USR and the main steps of an access control method implemented by the service provider FS.
[0102] In this example, the user USR uses his D-USR device to request the D-FI device of an identity provider FI to provide him with a verifiable accreditation T relating to a secret attribute ao and to n public attributes "" a". These public attributes can be sovereign attributes (surname, first name, date of birth, etc.) or not.
[0103] During a step U2, the user's device D-USR generates a random value ao. This value is intended to remain secret; it can be used by the user USR to prove that the verifiable accreditation T that he will receive from the identity provider FI is indeed his property.
[0104] During a step U4, the user USR uses his key pair {PKV, skv) to authenticate himself with the identity provider FI. In the embodiment described here, if the identity provider FI does not authenticate the user USR, the result of a test 14 is negative and the method stops.
[0105] If the authentication is successful, during a step U5, the D-USR device of The user USR calculates a pledge (or commitment) Coin on the secret value ao. This commitment Com constitutes a secret attribute, because the user does not wish to reveal ao.
[0106] In the embodiment described herein, the Coin pledge is generated with the Pedersen pledge scheme. For more information on this scheme, those skilled in the art may refer to Torben P. Pedersen: Non-interactive and information-theoretic secure verifiable secret sharing. In Joan Feigenbaum, editor, CRYPTO'91, volume 576 of LNCS, pages 129-140. Springer, Heidelberg, August 1992.
[0107] During a step U6, the user USR transmits to the identity provider FI the attributes Corn, av ..., a„ for which he wishes to obtain a verifiable accreditation T.
[0108] During a step 18, the D-FI device of the identity provider FI calculates a signature T on the attributes Com, a^, an using its private key skf.
[0109] In accordance with the present disclosure, this signature T is a blind signature. It is recalled that a blind signature is a security mechanism used in cryptography to allow a party to sign a message without knowing the content of this message so that the confidentiality of the message is preserved. In such a mechanism, the party wishing to obtain a blind signature combines the message to be signed with a randomly generated blinding factor and sends the result of this combination to the signer. The signer signs the message without knowing its actual content, and sends the resulting signature to the requester. The requester can use the blinding factor to "unblind" the signature, i.e. to cancel the effect of the blinding factor and obtain the signature of the original message.
[0110] In the embodiment described herein, the blind signature T is calculated using the algebraic MAC scheme primitive.
[0111] In the exemplary embodiment described here, the signature r is in two parts t — (tj, T?) , where — rs^'- This signature constitutes a verifiable accreditation within the meaning of the present disclosure.
[0112] During a step 110, the identity provider FI calculates a proof II । intended to convince the user USR of the validity of the accreditation T. In the embodiment described here, it only wishes to convince the user USR and it uses for this purpose a designated verifier proof mechanism known to those skilled in the art of cryptography.
[0113] During a step 112, the identity provider FI returns the accreditation T and the proof H[ to the user USR.
[0114] During a step U14, the user's D-USR device unblinds the signature T and obtains a signature also noted T for simplicity.
[0115] This deblinded signature of the message consisting of the commitment Com on the secret attribute ao and the public attributes ai' • • • ' ün of this user constitutes an anonymous verifiable accreditation which can only be verified using the secret key sk{ of the identity provider FI. In the mode described here, it is stored in the WAL wallet.
[0116] [Fig.3] represents the steps implemented by the different stakeholders (user, service provider, identity provider) when the user USR wishes to access the service offered by the service provider FS.
[0117] In accordance with the present disclosure, the user USR uses for this purpose a verifiable presentation (in English "verifiable presentation") VP generated from one or more accreditations T issued by at least one identity provider FI.
[0118] For the sake of simplicity, it is assumed that the verifiable presentation VP only includes one verifiable accreditation T.
[0119] We recall that in this example this verifiable accreditation T relates to a commitment Com on a secret attribute ao.
[0120] We will designate by D, the list of indices of the attributes { a; ] requested by the service provider FS and in this example D = {1, 21 •
[0121] During a step U20, the user USR connects anonymously to the service provider FS.
[0122] During a step S22, the service provider asks the user USR for a list D of attributes that it needs to check to give him access to its service.
[0123] In a preferred embodiment, this request is authenticated, in other words signed by the service provider FS.
[0124] During a step U24, the user calculates a pledge C on all of his certified public attributes ' an. For the sake of simplification, we will assume that he actually calculates n pledges, one pledge per public attribute: C — (Cj, C2, .... C„) where C,- (i G {1,2, ..., n}) designates a pledge on the attribute
[0125] In accordance with the present disclosure, the service provider FS will ask the identity provider FI to provide proof that it has indeed certified the user's attributes. The identity provider FI should therefore verify, with its private key skh, the accreditation T produced in step 18.
[0126] But since the identity provider FI must not be able to make the connection with the user USR who communicated his attributes to him (step U4) for the calculation of this accreditation (step 18), the user USR calculates in step U26, an accreditation anonymous verifiable refreshed t' from the accreditation T obtained in step U14.
[0127] Thus, the new verifiable accreditation t' = (r 'j, T'2) still relates to the secret attribute and to the public attributes ai- a2' a3' - an but it cannot be compared, in particular by the identity provider FI, with the accreditation T produced by the identity provider FI in step 18.
[0128] In the embodiment described here, during a step U27, the user USR generates a zero-knowledge proof demonstrating that he knows how to reveal the n pledges Cz and that the verifiable anonymous accreditation t' is valid on the set of pledged values a& a2> •••'.
[0129] During a step U28, the user USR generates a verifiable presentation VP comprising at least one verifiable accreditation r'.
[0130] In the described embodiment, the verifiable presentation VP comprises the public key PKj of the identity provider FI, the verifiable accreditation the pledges C, and the zero-knowledge proof 71v: VP^PK^c^1^
[0131] As mentioned earlier, the service provider FS needs to verify the requested public attributes fît | ajj and the user must therefore provide it with information to obtain them.
[0132] In the embodiment described herein, this information includes the data necessary to reveal the pledges C„ only for i G D.
[0133] These data are hereinafter called opening data and noted OpeniCfî •
[0134] When using a pledge scheme based on a hash function H, the pledge can be of the type C; = H(aj where ri is a random number. In this example a< and} î constitute the opening data OpeniC-).^-
[0135] During a step U30, the user provides the verifiable presentation VP and the opening data Open(C^). to the service provider FS.
[0136] During a step S32, the service provider FS verifies that the opening data Open^Cj).^ actually makes it possible to reveal the attributes Ch and that the attributes üfît of the user comply with the conditions of access to its service.
[0137] If this is not the case, in the embodiment described here, the service provider FS refuses access to the service during a step S34.
[0138] In the embodiment described here, if the attributes ü2 of the user comply with the conditions of access to his service, the service provider verifies, during a step S36, the validity of the proof 77 u with zero disclosure of knowledge. This step may not be performed, especially if the FI identity provider is configured to perform this verification (see step 144 below). However, it allows the service provider to verify that the VP verifiable presentation was indeed issued by the USR user, and that the user has not reused a third-party verifiable presentation that he or she may have fraudulently copied.
[0139] In the embodiment described here, if the service provider FS determines that the proof 77 u is invalid, it refuses access to the service during step S34.
[0140] Before allowing access to the service to the user USR, the service provider must ensure that the user's £1^ £12 attributes have been certified. In accordance with this disclosure, only the identity provider itself can provide proof of this certification.
[0141] During a step S38, the service provider anonymously signs the verifiable presentation VP with its group private key skRP.
[0142] By noting this signature 77RP, and by using the notations presented in the preamble to this disclosure: = Sign , ( VP ).
[0143] During a step S40, the service provider FS then anonymously transmits the verifiable presentation VP and the group signature 77RP to the identity provider FI identified in this example using its public key PKh. It does not transmit the opening data OpentC^^ because they would allow the identity provider to identify the service provider FS as well as the user USR.
[0144] During a step 142, the identity provider FI verifies the group signature ^RP. This operation allows it to verify that the service provider FS is one of the service providers authorized to request it but does not reveal its identity.
[0145] In certain embodiments of the present disclosure, if the identity provider FI authenticates the service provider FS as authorized, it verifies the validity of the proof 77 u during a step 144. This verification may not be carried out, in particular when the proof 77 u has been verified by the service provider in step S36. However, it advantageously allows the identity provider to verify that the verifiable presentation VP has not been fraudulently generated by the service provider itself.
[0146] In a particular embodiment, the identity provider FI systematically verifies the validity of the proof.
[0147] In the embodiment described here, if the identity provider FI fails to validate the group signature 77RP (step 142) or the proof (step 144), it sends to the service provider FS, during a step 146, a message indicating to it that the verifications requested in step S40 have failed. In the embodiment described here, the service provider FS refuses access to the service during step S34.
[0148] If these two verifications are conclusive, the identity provider FI verifies the validity of the anonymous verifiable accreditation t' refreshed during a step 148. It uses its private key $kj for this purpose.
[0149] We recall that in this example there is a two-part key of the form r' — (r'], T 2) and this verification consists of verifying that T<^ _
[0150] If the verification of the refreshed verifiable credential fails, the identity provider generates (step 150) a proof njVG demonstrating that the verifiable credential t' is invalid.
[0151] nA,c=poK^ . PKj = f^TThe identity provider FI sends this proof nAG to the service provider FS (step 152) and the service provider FS refuses access to the service during step S34.
[0152] On the contrary, if the refreshed verifiable accreditation is verified, the identity provider generates (step 154) a proof Hqk demonstrating that the verifiable accreditation r' has been validated with its secret key skj,
[0153] nNG= PoK(« : PKj = / ( a ) — T■ The identity provider FI sends this proof Uok to the service provider FS (step 156) and the service provider FS allows the user USR to access the service during a step S58.
[0154] 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.4].
[0155] This computer ORD comprises in particular a processor 10, a random access memory 11, a read only memory 12 and communication means 13.
[0156] The read-only memory 12 constitutes a recording medium within the meaning of the invention. It comprises a PG-X computer program in accordance with the invention.
[0157] For the D-USR device, this PG-X computer program is a PG-USR program comprising instructions for executing the steps of a method for requesting access to a service as described previously with reference to Figures 2 and 3. The PG-USR program defines in particular the M-AUTH modules for authentication, WAL obtaining of an anonymous accreditation, WAL calculation of a refreshed accreditation, and COM-3 communication of the D-USR device.
[0158] For the D-FI device, this PG-X computer program is a PG-FI program comprising instructions for executing the steps of a method for managing at least one anonymous verifiable accreditation as described previously with reference to Figures 2 and 3. The PG-FI program defines in particular the M-CRY1 module for authentication and generation of an anonymous verifiable accreditation, and the C0M1 module of the D-FI device.
[0159] For the D-FS device, this PG-X computer program is a PG-FS program comprising instructions for executing the steps of an access control method to a service as described previously with reference to figures 2 and 3. The PG-FS program defines in particular the M-CRY2 signature module, the ML-S attribute verification module and the COM2 communication module of the D-FS device.
Claims
Claims
1. Method for managing at least one anonymous verifiable accreditation comprising the following steps: - authentication (U4) of a user (D-USR); - obtaining (U6) at least one attribute (Com, a^, ..., a^) of the user; - generation (18) of an anonymous verifiable accreditation (r) relating at least to said at least one attribute (Com, a^, ...., an) of the user, said accreditation (r) being a blind signature calculated using a private key (sk^) of an identity provider; - sending (112) said accreditation (r) to said user.
2. Management method according to claim 1 wherein at least one of said attributes (Com) is a commitment to a secret attribute (a^) of the user.
3. Management method according to claim 1 or 2 and further comprising a calculation (110) of a proof (n^ of the validity of the verifiable accreditation (t) and the sending (112) of said proof (H j to said user (D-USR).
4. Management method according to any one of claims 1 to 3 further comprising the steps of: - anonymous reception (S40), from a service provider (FS), of a verifiable presentation (VP) comprising an anonymous verifiable accreditation (r') relating to at least one of the attributes (Com, a . . aW'a user (D-USR) and a group signature (^RP) of this presentation (VP); - verification (142) of the validity of said group signature (^RP); - verification (148) of the validity of the anonymous verifiable accreditation (t) using said private key (sk^ of the identity provider, and in case of success, generation of a proof of the validity of said accreditation (r'); - sending (156) of said proof (ü^j of the validity of the anonymous verifiable accreditation (t1) to the service provider (FS) only if said group signature (cr^) was determined (142) valid.
5. Management method according to claim 4 wherein said verifiable presentation (VP) further comprises proof Co to di- zero disclosure of knowledge demonstrating that the user (D-USR) knows how to reveal a pledge (Q) on said at least one attribute (Com, a?, ct That the verifiable anonymous accreditation (r1) is valid on said at least one attribute (Com, Oq, 6u)pledge, said method comprising: - a step (144) of verifying the validity of said proof (“'p; - said proof (üo^ of the validity of the anonymous verifiable accreditation (r') being sent to the service provider (FS) only if said proof (77^) with zero knowledge disclosure has been determined (144) to be valid.
6. Access request method, implemented by a device (D-USR) of a user, to request access to a service provided by a service provider (FS), said method comprising the following steps: - authentication (U4) of the user (D-USR) with a device (D-FI) for managing at least one anonymous verifiable accreditation; - sending (U6) at least one attribute (a}, ..., an) of the user to said management device (D-FI); - obtaining (112, U14) an anonymous verifiable accreditation (r) relating to said at least one attribute (Com, aY ..., a,^ of the user, said accreditation (t) being a blind signature calculated using a private key (sk^ of said management device (D-FI); - calculation (U26) of a refreshed anonymous verifiable accreditation (t') from said accreditation (r); - sending (U30), to said service provider (FS), a verifiable presentation (VP) comprising at least said refreshed accreditation (rr) and information (| Open(Cj). ^) allowing the service provider to obtain at least one attribute a 1 )) of said user requested by said service provider (SP).
7. Access request method according to claim 6, in which the verifiable presentation (VP) comprises a pledge (C;) on all the attributes of the user, said information comprising opening data (Open^Cy ) making it possible to open only said at least one attribute ) requested by said service provider (FS).
8. Method for controlling access to a service by a user (D-USR), said method being implemented by a service provider (D-FS) and comprising the following steps: - obtaining (U30) a verifiable presentation (VP) comprising an anonymous verifiable accreditation (r') relating to attributes ( Com. ar .... of the user; - obtaining (U30) information (| ç,j" Open(C^.^) allowing the service provider to obtain at least one of said attributes ( tn 1 ) V feD? and verification (S32) of said at least one attribute ( t. .1 ); V l heD / - signature (S38) of said verifiable presentation (VP) with a group private key (skRP) to obtain a group signature (^RP); - anonymous sending (S40), to a device (D-FI) configured to validate said accreditation (r '), of said verifiable presentation (VP) and of said group signature (^rp); - a positive result of a verification (S32) of said at least one attribute ({â} j and obtaining proof (riOAJ of the validity of said accreditation (r') being necessary conditions for authorizing (S58) the access of the user (USR) to said service.
9. Access control method according to claim 8 wherein said verifiable presentation (VP) further comprises a zero-knowledge proof (^Y) demonstrating that the user (D-USR) knows how to reveal a pledge (Cz) on said attributes (a& a and that the verifiable anonymous accreditation (r') is valid on all the attributes (a^ a2, ..., a„) pledged - said method comprising: - a step (S36) of verifying the validity of said proof (77^); - a positive result of said verification (S36) being a necessary condition for authorizing (S58) the access of the user (USR) to said service.
10. Device (D-FI) for managing at least one anonymous verifiable accreditation, this device comprising: - a module (M-CRY1) for authenticating (U4) a user (D-USR); - a module (C0M1) for obtaining (U6) at least one attribute (Com, a}, .... an) of the user; - a module (M-CRY1) for generating (18) a verifiable accreditation anonymous (t) relating at least to said at least one attribute (Com, aY . of the user, said accreditation (t) being a blind signature calculated using a private key (sk,) of the identity provider; - a module (C0M1) for sending (112) said accreditation (t) to said user.
11. Device (D-USR) for requesting access to a service provided by a service provider (FS), said device comprising: - a module (M-AUTH) for authenticating (U4) a user (D-USR) to a device (D-FI) for managing at least one anonymous verifiable accreditation; - a module (COM3) for sending (U6) at least one attribute (^, an) of the user to said management device (D-FI); - a module (WAL) for obtaining (112, U14) an anonymous verifiable accreditation (r) relating to said at least one attribute (Com, aY a.,} of the user, said accreditation (t) being a blind signature calculated using a private key (sk^ of said management device (D-FI); - a module (WAL) for calculating (U26) a refreshed anonymous verifiable accreditation (r') from said accreditation (t); - a sending module (COM3), to said service provider (FS), a verifiable presentation (VP) comprising at least said refreshed accreditation (t') and information ({ Qp , Open(Cj). $) allowing the service provider to obtain at least one attribute (fol \) of said user requested by said service provider (FS).
12. Device (D-FS) for controlling access to a service by a user (D-USR), said device comprising: - a module (COM2) for obtaining (U30) a verifiable presentation (VP) comprising an anonymous verifiable accreditation (r') relating to attributes (Com, aY ..., of the user; - a module (COM2) for obtaining (U30) information ({ Qj" Open(C^. ) allowing the service provider to obtain at least one of said attributes / fni V Va'> iëD / - a module (M-LS) for verifying (S32) said at least one attribute - a module (M-CRY2) for signing (S38) said verifiable presentation (VP) with a group private key (skKP) to obtain a group signature (^rp); - a module (COM2) for sending, anonymously (S40), to a device (D-FI) configured to validate said accreditation (r'), said verifiable presentation (VP) and said group signature (aRP); - a module (COM2) configured to authorize (S58) access of the user (USR) to said service at least if a verification (S32) of said at least one attribute j is positive and if proof of the validity of said accreditation (rr) is obtained.
13. Computer program (PG-USR, PG-FS, PG-FI) comprising instructions which, when the program is executed by a computer, cause the latter to implement: - a method for managing at least one anonymous verifiable accreditation according to any one of claims 1 to 5; or - a method for requesting access to a service according to claim 6 or 7; or - a method for controlling access to a service according to claim 8 or 9.
14. A computer-readable recording medium on which a computer program (PG) according to claim 13 is recorded.