EP4674088A1 - Procédé de delivrance d'une autorisation d'accès pour un individu et procédé de vérification - Google Patents

Procédé de delivrance d'une autorisation d'accès pour un individu et procédé de vérification

Info

Publication number
EP4674088A1
EP4674088A1 EP24707069.1A EP24707069A EP4674088A1 EP 4674088 A1 EP4674088 A1 EP 4674088A1 EP 24707069 A EP24707069 A EP 24707069A EP 4674088 A1 EP4674088 A1 EP 4674088A1
Authority
EP
European Patent Office
Prior art keywords
access authorization
individual
data
server
client device
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Pending
Application number
EP24707069.1A
Other languages
German (de)
English (en)
Inventor
Yann BOUAN
Paul Edmond BERTHIER
Stéphane CAUCHIE
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Idakto SAS
Original Assignee
Idakto SAS
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Idakto SAS filed Critical Idakto SAS
Publication of EP4674088A1 publication Critical patent/EP4674088A1/fr
Pending legal-status Critical Current

Links

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/08—Network architectures or network communication protocols for network security for authentication of entities
    • H04L63/0823—Network architectures or network communication protocols for network security for authentication of entities using certificates
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/06—Network architectures or network communication protocols for network security for supporting key management in a packet data network
    • H04L63/062—Network architectures or network communication protocols for network security for supporting key management in a packet data network for key distribution, e.g. centrally by trusted party
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/10—Network architectures or network communication protocols for network security for controlling access to devices or network resources
    • H04L63/102—Entity profiles
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/20—Network architectures or network communication protocols for network security for managing network security; network security policies in general

Definitions

  • the invention relates to a method and a device for issuing access authorization data for an individual and an associated method and device for verifying an access authorization of an individual.
  • Access to content, services, applications, resources or servers of a service provider is very often controlled.
  • access to the service provider may be authorized for one or more categories of persons based on characteristics specific to the person or based on the person's abilities. In other words, if the person has a given characteristic (or characteristics) or a particular ability (or abilities), he or she has access authorization. Otherwise, access is denied to the person.
  • Access control to the service provider can be carried out in a rudimentary manner. For example, before entering a specific website, the person must simply declare that he or she is an adult, enter a date of birth or click on a button such as "I am over 18". This access control is therefore subject to a verification that is based solely on a declaration by the person. This control is very often anonymous and may be based on erroneous information.
  • access control to the service provider can be achieved in a very elaborate manner. For example, before connecting to a website of a service provider, the person must register with the service provider and provide his personal information such as his name, first name, age, address and provide banking or identity card information. He then obtains an identifier and a password allowing subsequent access to the website of the service provider. In this case, access is not anonymous and each connection to the website can be traced.
  • Another solution is to use a digital identity.
  • the latter makes it possible to reduce the disclosure of identity information of the person and to achieve the objective of proving that the person has one or more specific characteristics or particular abilities.
  • the aim of the invention is to remedy these drawbacks and to allow on the one hand the delivery of access authorization data for an individual based on at least one of his attributes by an access authorization server so that the latter can then provide proof to a service provider that he has at least one attribute that satisfies the service provider.
  • the invention allows verification of an individual's access authorization, the verification being carried out anonymously and without traceability of the different accesses.
  • the subject of the invention is a method for issuing access authorization data for an individual having a public key and at least one given attribute, the method being implemented in an access authorization server capable of communicating with an identification server and a client device, the access authorization server having at least one given rule and a secret cryptographic data, the secret cryptographic data being specific for a group of individuals having at least one attribute conforming to said at least one given rule.
  • the method comprising the following steps:
  • the method according to the invention allows the delivery of access authorization information to an individual if the latter possesses one or more attributes conforming to one or more rules.
  • the access authorization information will subsequently allow the individual to prove to a service provider that he possesses one or more attributes, in a reliable and anonymous manner.
  • the access authorization server may further comprise public cryptographic data associated with said secret cryptographic data, the method may then further comprise a step of transmitting the public cryptographic data to the client device.
  • the method may further comprise a step of verifying the possession of a private key of the individual by the client device associated with the public key of the individual obtained, prior to the issuance of the access authorization data.
  • the method may further comprise a step of obtaining a request identifier for access authorization data and a step of transmitting the request identifier for access authorization data to the identification server.
  • the request identifier for access authorization data may in this case include an identifier of the individual.
  • the method may further comprise a step of obtaining an identifier of the individual from the identification server or the client device.
  • the invention also relates to a method for verifying an access authorization of an individual having an access authorization data item, the access authorization data item having been issued in accordance with the method described above.
  • the method is implemented in an access authorization server capable of communicating with a service provider, the service provider implementing an access control based on at least one attribute of the individual.
  • the access authorization server has a public cryptographic data item, the public cryptographic data item being specific for a group of individuals having at least one attribute conforming to at least one given rule, said public cryptographic data item being associated with a secret cryptographic data item, said secret cryptographic data item having been used to generate the access authorization data item.
  • the method comprises the following steps:
  • the public cryptographic data may be received from the service provider or a client device.
  • the access authorization proof information may be received from the service provider or a client device.
  • the access authorization server may further be able to communicate with a client device.
  • the method may then further comprise the following steps:
  • the access authorization server may further be capable of communicating with a client device.
  • the method may then further comprise the following steps:
  • the access authorization server may be able to communicate with an evidence database, and the method may then further comprise a step of transmitting to said evidence database the access authorization proof information received.
  • the access authorization server may further comprise data identifying the group of individuals having at least one attribute conforming to said at least one given rule, and the step of sending to the service provider information for validating the access authorization proof information may then further comprise sending the data identifying the group of individuals.
  • the invention also relates to a device configured to implement at least one of the methods described above.
  • FIG-1 illustrates an example of a system in which a method of issuing access authorization data for an individual in accordance with the invention and a method of verifying an access authorization of an individual in accordance with the invention can be implemented.
  • FIG.2 illustrates an embodiment of the method for issuing access authorization data for an individual in accordance with the invention.
  • FIG.3 illustrates a first example of a system in which an access authorization server implements an embodiment of the method for issuing access authorization data for an individual in accordance with the invention.
  • FIG.4 illustrates a second example system in which a server access authorization implements another embodiment of the method for issuing access authorization data for an individual in accordance with the invention.
  • FIG.5 illustrates an embodiment of the method for verifying an access authorization of an individual in accordance with the invention.
  • FIG.6 illustrates a first example of a system in which an access authorization server implements an embodiment of the method for verifying an access authorization of an individual in accordance with the invention.
  • FIG.7 illustrates a second example system in which an access authorization server implements another embodiment of the method for verifying an access authorization of an individual in accordance with the invention.
  • FIG.8 illustrates a first example of a system in which a control server implements an embodiment of a method for determining the identity of the individual having requested verification of an access authorization.
  • FIG.9 illustrates a second example system in which a control server implements an embodiment of a method for determining the identity of the individual having requested verification of an access authorization.
  • the present invention relates, according to a first aspect, to a secure and reliable manner of delivering access authorization data for an individual having a public key and at least one given attribute subsequently allowing anonymous and untraceable access of the individual to a service provider having access control based on attributes of the individual.
  • An access control based on one or more attributes of the individual authorizes the individual's access only if the individual is able to provide proof that one or more of his attributes comply with one or more rules.
  • Such an access control makes it possible to filter the individual's access to content, services, applications, resources or servers of a service provider.
  • the delivery of access authorization data is a function of at least one given attribute of the individual.
  • the access authorization data is generated for an individual so as to subsequently allow the latter anonymous access, therefore without having to disclose his identity and his attributes.
  • the access authorization data has a role of anonymous digital attestation certifying that the individual has at least one attribute conforming to a given rule.
  • the invention relates to a method for issuing access authorization data for an individual having a public key and at least one given attribute, implemented in an access authorization server.
  • the present invention relates according to a second aspect to a secure and reliable manner of carrying out an access authorization verification of an individual wishing to access a service provider implementing access control based on at least one attribute of the individual.
  • the verification is performed by means of access authorization proof information generated from the access authorization data previously generated for the individual.
  • Such an access authorization verification makes it possible to ensure that the individual actually has at least one attribute that complies with at least one given rule and therefore that he is legitimate to access the service provider.
  • the verification is performed without having to actually verify the conformity of the individual's attribute(s) with one or more given rules, the conformity having been previously achieved by the issuance of the access authorization data.
  • the invention relates to a method for verifying an access authorization of an individual having access authorization data implemented in an access authorization server.
  • An attribute of an individual is a characteristic of an individual, such as age, region of residence, country of residence, etc., or a capability of the individual, such as possession of a driver's license or a work permit.
  • the attribute may also include the fact that an individual has an access account with an organization, such as a government agency, a bank, etc.
  • an access authorization data is issued to an individual, if an attribute of the latter complies with a given rule or if attributes of the individual comply respectively with given rules.
  • a rule aims to define an access criterion. For example, a rule relating to the attribute "age” can be "being over 18 years old", a rule relating to the abilities of the individual can be "having a driving license”.
  • FIG. 1 an example of a system is described in which a method for issuing access authorization data for an individual in accordance with the invention and a method for verifying an access authorization of an individual in accordance with the invention can be implemented.
  • the system comprises an individual INDIV, at least one client device available to the individual DEV, an access authorization server SERV-AUTO, a service provider FRS-SERV and an identification server IDP. It may further comprise an identity support CAP of the individual INDIV and a control device CONTROL.
  • An individual INDIV is a user who wishes to access content, an application, a service, a server, etc. of a service provider using a client device DEV. He has an identifier ID U , at least one given attribute ATT, a key public key pk u and an associated secret key sk u . To prove that it has the attribute or attributes necessary for connecting to the service provider, it will first obtain access authorization data that can be stored in a secure space on the client device. Then, it will generate proof information to prove that it has access authorization for a connection to the service provider, without however disclosing to the latter its identity and its ATT attributes. In other words, it will generate proof information that must be verified to certify to the service provider that it has the attribute or attributes allowing it to connect to the latter without however the service provider having access to the identity and ATT attributes of the individual.
  • the client device DEV may be any type of device, such as a mobile phone, a tablet, a computer, etc., comprising a hardware and software platform on which software is executed, this software being either directly executable or interpreted on a virtual machine.
  • the client device DEV comprises in particular a human-machine communication interface for displaying data and receiving data from the individual INDIV.
  • This human-machine communication interface comprises for example a screen and a keyboard, or a touch screen.
  • the client device DEV may comprise an Internet browser running on the human-machine communication interface.
  • the client device is able to communicate with the access authorization server SERV-AUTO, the service provider FRS-SERV and the identification server IDP. It can also communicate with the identity support CAP.
  • the client device DEV is provided with communication means (wired or wireless).
  • the client device DEV may include network-type connectivity, either via a wired connection or via a wireless connection (e.g., compliant with the Bluetooth standard, the NFC standard, the WIFI standard or the PC/SC standard) for communication with the identity support CAP and may include network communication means compliant with any of the Ethernet standards, and/or compliant with any of the IEEE 802.11 (Wifi) standards, and/or compliant with one or more mobile telephony standards (2G, 3G, 4G, etc.) for communication with the access authorization server SERV-AUTO, the service provider FRS-SERV and the identification server IDP.
  • network-type connectivity either via a wired connection or via a wireless connection (e.g., compliant with the Bluetooth standard, the NFC standard, the WIFI standard or the PC/SC standard) for communication with the identity support CAP and may include network communication means compliant with any of the Ethernet standards, and/or compliant with any of the IEEE 802.11 (
  • the identity medium CAP is a means storing information specific to the individual INDIV. It may include in particular an identifier of the individual ID U , the attribute(s) ATT of the latter and/or a private key sk u and a public key pk u of the individual. It may be, for example, an electronic identity card, an electronic passport or a bank card. It includes connectivity means, in particular wireless communication means (for example, compliant with the standard Bluetooth, NFC or PC/SC standard) in order to be able to communicate with a DEV client device.
  • the CAP identity support may further comprise a function for establishing a secure communication channel enabling the creation of a secure communication channel between the CAP identity support and the DEV client device.
  • the establishment of a secure communication channel is based on the use of security protocols.
  • the DEV client device may also further comprise a function for establishing a secure communication channel enabling the creation of a secure channel between the DEV client device and the CAP identity support.
  • the establishment of a secure communication channel is based on the use of security protocols.
  • the identifier of the individual ID U can be stored in the client device DEV, in particular in a secure memory space.
  • the IDP identification server comprises a hardware and software platform on which software is executed. It can be used to authenticate an individual, in particular from the identifier of the latter ID U , and it can provide, in particular to the access authorization server, the ATT attribute(s) of the individual INDIV of which it has regularly had knowledge.
  • the IDP identification server stores for a set of individuals, their identifier ID U and one or more ATT attributes of these individuals.
  • An IDP identification server is, for example, a government identity provider, a bank or a secure data space.
  • the IDP identification server can comprise a function for establishing a secure communication channel allowing the creation of a secure channel between the IDP identification server and the client device DEV or between the IDP identification server and the SERV-AUTO access authorization server. Establishing a secure communication channel relies on the use of security protocols. Connecting to the IDP identification server requires strong authentication. For this, different technologies can be used such as OpenID, SAML, ISO 18013 or IS02020.
  • the ERS-SERV service provider is for example an application service provider or an online application provider. In other words, it may be a hosted application provider that provides software, content or IT services to its customers via an Internet network for example. Access to these applications is notably achieved through a web browser and using a standard protocol such as the http protocol.
  • the ERS-SERV service provider comprises a hardware and software platform on which applications run in order to provide software, services or content.
  • the service provider may want or have an obligation to ensure that the individual who wishes to access these services, applications or content belongs to a certain category of persons, for example that the individual is an adult.
  • the service provider implements access control based on at least one attribute of the individual. To do this, the service provider communicates with the SERV-AUTO access authorization server.
  • the SERV-AUTO access authorization server provides a service that delivers access authorization data to an individual and that verifies an access authorization of an individual to prove the legitimacy of an individual to access a service, content, application, etc. of a service provider.
  • the access authorization server is capable of implementing all or part of the method for delivering access authorization data for an individual or the method for verifying an access authorization of an individual in accordance with the invention. All or part of the method for delivering access authorization data for an individual and/or all or part of the method for verifying an access authorization of an individual may be implemented in software form and/or in the form of devices).
  • the embodiments of the SERV-AUTO access authorization server described below are such that the SERV-AUTO access authorization server is capable of implementing all or part of the process of issuing access authorization information for an individual and the method of verifying an access authorization of an individual.
  • the method of issuing access authorization data for an individual and the method of verifying an access authorization of an individual can be implemented in separate servers.
  • the access authorization server SERV-AUTO is able to communicate with the service provider FRS-SERV and the identification server IDP using connectivity means provided by the access authorization server SERV-AUTO.
  • the connectivity means of the access authorization server SERV-AUTO may comprise network communication means conforming to any one of the Ethernet standards, and/or conforming to any one of the IEEE 802.11 (Wifi) standards, and/or conforming to one or more mobile telephony standards (2G, 3G, 4G, etc.). It can furthermore communicate with the client device DEV and the control server CONTROL.
  • the SERV-AUTO access authorization server further comprises means for executing a calculation algorithm and exchanging cryptographic keys.
  • a control server CONTROL can be implemented to reveal the identity of the individual who submitted proof of access authorization information to the service provider. However, this server is implemented in particular in the embodiments in which it is necessary to be able to find the identity of the individual who submitted proof of access authorization information to the service provider.
  • FIG.2 illustrates an embodiment of the method for issuing access authorization data for an individual INDIV having a public key pk u and at least one given attribute ATT in accordance with the invention. The dotted steps in the figure are optional.
  • the method is implemented in an access authorization server SERV-AUTO capable of communicating with an identification server IDP and a client device DEV.
  • the access authorization server SERV-AUTO comprises at least one given rule. It further comprises a pair of cryptographic data specific to a group of individuals having at least one attribute conforming to said at least one given rule.
  • the pair of cryptographic data comprises a secret cryptographic data and a public cryptographic data.
  • a group of individuals comprises a set of individuals having obtained access authorization information because the attribute(s) of these individuals conform to said at least one given rule.
  • the method may begin with a step of obtaining a request identifier for an access authorization data item (step 210). This step may result from the generation of the request identifier by the client device DEV and the access authorization service SERV-AUTO.
  • the request identifier of an access authorization data is for example a session identifier established between the client device and the access authorization server or an authentication code.
  • the request identifier for access authorization data is obtained by the generation of an identifier by the client device and the access authorization server following, for example, the exchange of messages for the creation of a communication channel.
  • the request identifier for access authorization data may comprise an identifier of the individual ID U.
  • the identifier of the individual ID U is for example a personal identifier of this individual. It can be an identifier assigned by a specific organization (for example, a government identity provider, a bank, etc.). Thus, the identifier of the individual ID U can be an identification number or personal data such as a name, a telephone number and/or a date of birth.
  • Step 210 is followed by a step of obtaining the public key of the individual pk u (step 220).
  • step 220 may also comprise obtaining an identifier of the individual ID U associated with the public key of the individual pk u .
  • Step 220 may be followed by a step 230 of transmitting the request identifier of an access authorization data to the IDP identification server (optional step).
  • This step may allow the IDP identification server to initiate a authentication process with the individual, in particular by means of the DEV client device (via or not the access authorization server).
  • the method continues with a step 240 of obtaining at least one attribute ATT of the individual INDIV.
  • the step 240 of obtaining at least one attribute ATT is carried out by receiving said at least one attribute of the individual INDIV transmitted directly or indirectly by the identification server IDP to the access authorization server SERV-AUTO.
  • the attribute(s) of an individual are determined by the identification server IDP for example after the authentication of the individual with the identification server IDP or from the identifier of the individual ID U.
  • the method may also comprise a step of obtaining an identifier of the individual ID U originating from the identification server IDP, in particular in the case where the identifier of the individual ID U has not been transmitted by the client device.
  • the identifier of the individual ID U is then associated with the public key of the individual received.
  • Step 240 is followed by a step 250 of determining compliance of said at least one ATT attribute of the individual obtained with said at least one given rule of the access authorization server.
  • the individual's attribute includes the data that the individual is in possession of a driver's license and the rule defines a criterion relating to the possession of the driver's license.
  • the individual's attribute complies with the rule since the attribute complies with the criterion.
  • Step 250 is followed by a step 260 of testing relating to the conformity of said at least one attribute ATT of the individual to said at least one given rule. If the test is negative, step 260 is followed by a step 270 of ending the method and no access authorization data is generated and delivered to the individual. If, on the contrary, the test of step 260 is positive, then step 260 is followed by a step 280 of generating access authorization data for the individual from the secret cryptographic data and the public key of the individual pk u obtained.
  • the access authorization data for the individual is further generated from the individual identifier ID U .
  • Step 280 is then followed by a step 290 of delivering the generated access authorization data to the client device DEV.
  • This step comprises for example sending the generated access authorization data to the client device.
  • the delivery method may further comprise a step of transmitting the public cryptographic data to the client device DEV.
  • the method may further comprise a step of verifying fication of the possession of the private key sk u by the individual, in particular by the individual's client device, associated with the individual's public key pk u obtained and used for the generation of the access authorization data. This step allows the access authorization server to ensure that the generated access authorization data is delivered to the individual possessing the public key used for the generation of the access authorization data.
  • the method further comprises a step of storing in a database of individuals BD-INDIV, the identifier of the individual ID U and the public key pk u of this individual.
  • the database of individuals can be stored on a server separate from the access authorization server.
  • the identifier of the individual ID U is not provided to the access authorization server.
  • FIG. 3 illustrates a first example of a system comprising an access authorization server SERV-AUTO which implements a particular embodiment of the method for issuing access authorization data for an individual having a public key pk u and at least one given attribute ATT in accordance with the invention.
  • the system illustrated in [Fig.3] comprises, in addition to the access authorization server SERV-AUTO, a client device DEV and an identification server IDP.
  • the access authorization server SERV-AUTO comprises at least one given rule. It further comprises a pair of cryptographic data specific to a group of individuals having at least one attribute conforming to said at least one given rule.
  • the pair of cryptographic data comprises a secret cryptographic data and a public cryptographic data.
  • a group of individuals comprises a set of individuals having obtained access authorization information because the attribute(s) of these individuals conform to said at least one given rule.
  • the client device DEV is for example a mobile telephone.
  • the individual INDIV may further be provided with an identity medium CAP comprising in particular the public key pk u of the individual.
  • the identity medium CAP may also comprise an identifier of the individual ID U associated with the public key pk u of the individual.
  • the client device DEV comprises means of communication with the identity medium CAP.
  • the public key pk u of the individual can be stored on the client device DEV.
  • the access authorization server obtains a request identifier of an access authorization data (step 310).
  • This step may comprise the exchange of messages between the access authorization server SERV-AUTO and the client device DEV allowing the generation and obtaining of a request identifier for an access authorization data item.
  • This step results in the access authorization server SERV-AUTO obtaining a request identifier for an access authorization data item in accordance with step 210 previously described in the support of [Fig.2],
  • the request identifier for access authorization data further comprises an identifier of the individual ID U.
  • step 310 the access authorization server SERV-AUTO obtains the public key of the individual pk u (in accordance with step 220 described previously in the support of [Fig. 2]).
  • the client device can send the public key of the individual pk u to the access authorization server SERV-AUTO.
  • the access authorization server SERV-AUTO can also obtain the identifier of the individual ID U.
  • Step 310 may be followed by a step of transmission by the access authorization server SERV-AUTO of the request identifier for access authorization data to the identification server IDP (step 320 which complies with step 210 previously described in the support of [Fig.2]).
  • step 320 is a step of creating a secure communication channel between the access authorization server SERV-AUTO and the identification server IDP.
  • step 320 is followed by an authentication phase by the individual with the IDP identification server, for example by means of the client device.
  • the identification server IDP communicates with the client device DEV so that the individual authenticates himself (step 330). This is possible in particular when the request identifier for access authorization data received by the identification server IDP comprises the identifier of the individual ID U.
  • the authentication of the individual can be carried out via the access authorization server, the latter then having a proxy role.
  • the individual authenticates himself with the identification server IDP by means of his client device DEV prior to step 310 and then the client device transmits to the access authorization server the identifier of the authenticated individual ID U.
  • the access authorization service SERV-AUTO obtains at least one ATT attribute of the individual from the identification server IDP in accordance with step 240 previously described in support of [Fig.2].
  • the identification server IDP transmits to the access authorization server SERV-AUTO at least one attribute ATT of the individual via the client device DEV.
  • the access authorization server can further obtain from the identification server an identifier of the individual ID U.
  • Step 340 is followed by a step 350 during which the access authorization server SERV-AUTO will determine the conformity of said at least one attribute ATT of the individual obtained with said at least one given rule in accordance with step 250 described in the support of [Fig. 2]. If said at least one attribute ATT of the individual conforms to said at least one given rule, the access authorization server SERV-AUTO generates access authorization data for the individual from the secret cryptographic data and the public key of the individual pk u obtained, in accordance with steps 260 and 280 previously described in the support of [Fig. 2].
  • the access authorization data for the individual is further generated from the individual identifier ID U .
  • Step 350 is followed by a step 360 of delivery by the access authorization server SERV-AUTO of the access authorization data generated to the client device DEV in accordance with step 290 previously described in the support of [Fig. 2].
  • the access authorization server SERV-AUTO sends a message to the client device DEV containing the access authorization data generated.
  • the step of issuing the access authorization data is preceded by a step of verifying the possession of the private key sk u by the individual, in particular by the client device of the individual, associated with the public key of the individual pk u obtained. This step allows the access authorization server to verify before communicating the access authorization data to the client device, that the latter has the secret key of the individual.
  • the access authorization server may further comprise a step of storing in a database of individuals BD-INDIV, the identifier of the individual ID U and the public key of this individual pk u .
  • Other additional information relating to the individual may also be stored in the database of individuals BD-INDIV.
  • the database of individuals BD-INDIV may be stored on a server separate from the access authorization server.
  • FIG.4 illustrates a second example of a system comprising an access authorization server SERV-AUTO which implements another embodiment of the method for issuing access authorization data for an individual. in accordance with the invention and described in support of [Eig.2].
  • the access authorization server includes at least one given rule.
  • the individual comprises a pair of keys, namely a private key sk u and a public key pk u stored for example on a client device DEV or in an identity medium CAP and the control server CONTROL comprises a secret disclosure key sk o and a public disclosure key pk o
  • the public disclosure key pk o of the control server CONTROL is transmitted to the access authorization server SERV-AUTO (step 400).
  • the access authorization server SERV-AUTO will generate a specific cryptographic data pair for a group of individuals having at least one attribute conforming to said at least one given rule.
  • the cryptographic data pair comprises a public cryptographic data Gpk and a secret cryptographic data sk m .
  • the public cryptographic data Gpk comprises at least one public master key pk m and the public disclosure key pk o received from the control server CONTROL.
  • the access authorization server comprises a specific cryptographic data pair for a group of individuals having at least one attribute conforming to said at least one given rule.
  • the cryptographic data pair comprises on the one hand, a public cryptographic data Gpk composed of a public master key pk m and on the other hand, a secret cryptographic data sk m .
  • the public cryptographic data Gpk can then be transmitted to the client device DEV.
  • the access authorization server obtains a request identifier for an access authorization data (step 410) in accordance with step 210 previously described in support of [Eig.2].
  • the request identifier for an access authorization data item (step 410) can be determined by the client device from in particular the secret key sk u of the individual and the public cryptographic data item Gpk received. It can further be determined from the identifier of the individual ID U . The request identifier for an access authorization data item is then transmitted by the client device and received by the access authorization server.
  • step 410 the access authorization server SERV-AUTO obtains the key public key of the individual pk u (in accordance with step 220 described previously in the support of [Fig.2]).
  • the client device can send the public key of the individual pk u to the access authorization server SERV-AUTO.
  • Step 410 is then followed by steps 320 to 340 previously described.
  • the access authorization server SERV-AUTO will determine the conformity of said at least one attribute ATT of the individual obtained with said at least one given rule in accordance with step 240 described previously in the support of [Fig. 2]. If said at least one attribute ATT of the individual conforms to said at least one given rule, the access authorization server SERV-AUTO generates an access authorization data item for the individual gsk u from the secret cryptographic data item sk m and the public key of the individual pk u obtained, in accordance with steps 260 and 280 previously described in the support of [Fig. 2].
  • Step 450 is followed by a step 460.a of delivering the generated access authorization data gsk u to the client device DEV.
  • step 450 may also be followed by a step 460.b of storage by the access authorization server, in a database of individuals BD-INDIV of the identifier of the individual ID U and of the public individual key pk u of this individual.
  • Other additional information relating to the individual may also be stored in the database of individuals BD-INDIV.
  • the database of individuals BD-INDIV may be stored on a server separate from the access authorization server.
  • FIG.5 illustrates an embodiment of a method for verifying an access authorization of an individual having an access authorization data implemented in a SERV-AUTO access authorization server in accordance with the invention.
  • the access authorization data was issued in accordance with the method for issuing an access authorization data previously described.
  • the SERV-AUTO access authorization server is able to communicate with a FRS-SERV service provider implementing access control based on at least one attribute of the individual.
  • the SERV-AUTO access authorization server comprises a public cryptographic data, the public cryptographic data being specific for a group of individuals having at least one attribute conforming to at least one given rule.
  • the public cryptographic data is associated with a secret cryptographic data, said secret cryptographic data having been used to generate the access authorization data of the individual.
  • the public cryptographic data can be received by the access authorization server and come from the service provider.
  • FRS-SERV FRS-SERV
  • the access authorization server SERV-AUTO is able to communicate with a client device DEV of the individual
  • the public cryptographic data can be received by the access authorization server and come from the client device DEV.
  • the SERV-AUTO access authorization server implementing the method for verifying an access authorization may be the same server as that implementing the method for issuing access authorization information or a separate server.
  • the method of verifying an access authorization may follow the method of issuing access authorization data previously described in support of [Fig.2] and the following figures.
  • the purpose of the method for verifying an access authorization is to verify that the individual has the access authorization to access a service provider implementing an access control based on at least one attribute of the individual, without verifying the conformity of the attribute(s) of the individual to one or more rules given during the verification of the access authorization. Furthermore, the verification also does not use an identifier of the individual.
  • this method allows access control of an individual to a service provider implementing access control based on at least one attribute of the individual while guaranteeing anonymous and untraceable access of the individual.
  • Non-traceability consists of not being able to identify the different accesses of the same individual to the service provider. In other words, the system and the service provider cannot determine whether two distinct accesses belong to the same individual (or not).
  • the individual must provide proof that one or more of his attributes comply with one or more rules, the rules defining the access control criteria of the service provider.
  • the proof is an access authorization proof information generated by the client device by means of the access authorization data previously delivered to it.
  • the ATT attribute(s) of the individual are not communicated to the service provider.
  • the service provider implementing an access control based on at least one attribute of the individual only knows that the rule(s) relating to one or more ATT attributes of the individual are respected.
  • the method of verifying an access authorization of an individual having access authorization data begins with a step of receiving access authorization proof information (step 510).
  • the proof information access authorization proof information was generated using the individual's access authorization data, including by the individual's client device.
  • the access authorization proof information may be received by the service provider or the individual's client device from the access authorization server.
  • This step may be preceded by a step of generating verification data c by the access authorization server, a step of transmitting the generated verification data to the client device DEV.
  • the access authorization proof information received may also be generated from the verification data.
  • Step 510 is followed by a step 520 of verifying the access authorization proof information received using the public cryptographic data.
  • Step 520 is followed by a step 530 of testing the verification of the access authorization proof information. If the access authorization proof information could not be verified, then step 530 is followed by step 540 during which the access authorization server can indicate to the service provider that the access authorization proof information is invalid.
  • step 530 is followed by a step 550 of sending to the ERS-SERV service provider information validating the access authorization proof information.
  • the access authorization server does not perform a check of the conformity of the attribute(s) of the individual to one or more given rules. Furthermore, the access authorization server does not use an identifier of the individual to perform the verification of the access authorization.
  • the access authorization server further comprises data identifying the group of individuals having at least one attribute conforming to said at least one given IdToken rule.
  • the step of sending to the FRS-SERV service provider information for validating the access authorization proof information further comprises sending the data identifying the group of individuals IdToken.
  • FIG.6 illustrates a first example of a system comprising a SERV-AUTO access authorization server which implements a particular embodiment of the method for verifying an individual's access authorization in accordance with the invention.
  • the individual has access authorization data previously issued in accordance with the method of issuing access authorization data described in particular in the medium of [Fig.2].
  • the SERV-AUTO access authorization server includes cryptographic data public graph, the public cryptographic data being specific for a group of individuals having at least one attribute conforming to at least one given rule.
  • the public cryptographic data is associated with a secret cryptographic data, said specific secret cryptographic data having been used to generate the individual's access authorization data.
  • the public cryptographic data is stored in the access authorization server.
  • the public cryptographic data is received by the access authorization server of the service provider FRS-SERV.
  • the public cryptographic data is received by the access authorization server of the client device DEV.
  • the system illustrated in [Fig. 6] comprises, in addition to the access authorization server SERV-AUTO, a service provider FRS-SERV, an identification server IDP or a server comprising a database BD-PREUVES and one or more client devices DEVI, DEV2 of an individual INDIV.
  • FIG. 6] illustrates a particular system in which the individual INDIV has a first client device DEV 1 and a second client device DEV2 which may be, for example, a laptop and a mobile phone.
  • the access authorization data of the individual is, for example, stored in the second client device DEV2.
  • the first client device DEV 1 and the second client device DEV2 are the same client device.
  • the service provider must then verify that the individual has one or more attributes allowing him access.
  • the service provider FRS-SERV can communicate, in particular securely by means of a secure communication channel created for example by means of the OpenID CIBA protocol, with the access authorization server SERV-AUTO in order to verify that the individual has an access authorization to the service provider (step 620).
  • a verification request identifier SessionID is then received by the access authorization server SERV-AUTO during step 620.
  • the reception of the verification request identifier may be preceded by a step of generation of the verification request identifier by the service provider and the access authorization server.
  • the access authorization server can then generate connection information from the received verification request identifier and transmit the connection information connection generated to the service provider.
  • the service provider transmits to the client device, for example to the first client device DEV1, the connection information that it has received (step 630).
  • connection information may be, for example, a QR Code which will be displayed on the display screen of the first client device DEV1.
  • the individual scans the QR Code displayed on the first client device DEV1 by means of the second client device DEV2 (step 640).
  • a communication channel between the access authorization server and the client device, in particular the second client device DEV2, is then created by means of the connection information.
  • the second client device DEV2 then generates access authorization proof information, the access authorization proof information being generated by means of the individual's access authorization data stored for example in the second client device DEV2.
  • the access authorization server SERV-AUTO will then receive the access authorization proof information generated as previously described in step 510 on the support of [Fig.5].
  • the access authorization server receives the proof information from the individual's second client device as illustrated in [Fig.6] (step 650) via the created communication channel.
  • the client device for example the first client device DEV 1, can transmit the access authorization proof information to the access authorization server via the service provider.
  • the access authorization proof information is generated on one of the client devices DEV1 or DEV2 by means of the individual's access authorization data stored for example on the second client device DEV2.
  • the access authorization server can send the received access authorization proof information to the identification server IDP or to a BD-PREUVES evidence database in order to store the received access authorization proof information (step 650.a).
  • the access authorization server can also send the verification request identifier SessionID and/or the date and time of receipt of the access authorization proof information in order to be stored. Additional data used for example for generating the access authorization proof information can also be stored in the database. evidence.
  • the access authorization server verifies the received access authorization proof information using the public cryptographic data as previously described in step 510.
  • the access authorization server sends to the service provider FRS-SERV an access authorization proof information validation information (step 660) as previously described with regard to step 530 of [Fig. 5].
  • the access authorization server does not verify the conformity of the attribute(s) of the individual to one or more given rules. Furthermore, the access authorization server does not use the identifier of the individual.
  • the access authorization server further comprises data identifying the group of individuals having at least one attribute conforming to said at least one given rule IdToken.
  • the step of sending to the FRS-SERV service provider information for validating the access authorization proof information further comprises sending the data identifying the group of individuals IdToken.
  • the access authorization server can receive the public cryptographic data from the service provider FRS-SERV or from the client device DEV in order to carry out the verification of the access authorization proof information.
  • FIG. 7 illustrates a second example of a system comprising an access authorization server SERV-AUTO which implements another embodiment of the method for verifying an access authorization of an individual having an access authorization data item in accordance with the invention.
  • the access authorization data item gsk u of this example was generated according to the embodiment of the delivery method described in the support of [Fig. 4].
  • the access authorization server comprises a public cryptographic data Gpk.
  • the public cryptographic data is specific for a group of individuals having at least one attribute conforming to at least one given rule.
  • the public cryptographic data is associated with a secret cryptographic data sk m . Said secret cryptographic data was used for generate the access authorization data as described in the embodiment illustrated in [Fig.4].
  • the public cryptographic data Gpk comprises at least one public master key pk m .
  • the public cryptographic data Gpk may further comprise a public disclosure key pk o .
  • the public cryptographic data is stored in the access authorization server.
  • the public cryptographic data is received by the access authorization server of the service provider FRS-SERV.
  • the public cryptographic data is received by the access authorization server of the client device DEV.
  • the access authorization proof information o is generated by the client device by means of a signature algorithm having as parameter the access authorization data gsk u and a verification data c to be signed generated by the access authorization server and transmitted to the client device.
  • the verification data is for example a random or semi-random number.
  • the access authorization proof information is generated on one of the client devices DEV1 or DEV2 by means of the access authorization data gsk u the individual stored for example on the second client device DEV2.
  • the access authorization proof information is then verified by the access authorization server by means of a signature verification algorithm having as parameters, the access authorization proof information o, the verification data c and the public cryptographic data Gpk (step 750).
  • the access authorization server can send the access authorization proof information o received to the identification server IDP or to a BD-PREUVES evidence database in order to store the access authorization proof information o received (step 75O.a).
  • the access authorization server can also send the verification request identifier SessionID, the date and time of receipt of the access authorization proof information o in order to be stored. Additional data used for example for generating the access authorization proof information can also be stored in the evidence database, such as the verification data c.
  • FIG.8 Illustrated in [Fig.8] is a first example of a system in which a CONTROL control server determines the identity of the individual who requested verification of an access authorization.
  • the CONTROL control server can in fact implement a de- termination of an individual's identifier from an access authorization proof information provided to the service provider and stored in a BD-PREUVES evidence database.
  • the BD-PREUVES evidence database stores the different access authorization proof information submitted by individuals to the service provider to show that they are legitimate to access the service provider.
  • the verification request identifier SessionID and the verification data c are associated.
  • the date and time of receipt of the access authorization proof information by the access authorization server can also be stored for each stored proof information.
  • the BD-PREUVES evidence database can be stored on the IDP identification server.
  • the system further comprises a database of individuals BD-INDIV storing the identifier ID U of the individuals having requested access authorization data from the access authorization server. Each identifier of an individual is associated with the public key pk u of the latter.
  • the method for determining the identifier of an individual implemented in the CONTROL control server aims to lift the anonymity of the individual having requested verification of an access authorization.
  • the method for determining the identifier of an individual begins with a step of receiving a request for determining the identifier of an individual (step 810) and a step of receiving a verification request identifier SessionID from the service provider FRS-SERV (step 820).
  • the verification request identifier SessionID identifies a session between the service provider FRS-SERV and the access authorization server SERV-AUTO so that the latter verifies information providing proof of access authorization of an individual.
  • the control server From the verification request identifier SessionID, the control server performs a search in the evidence database BD-PREUVES in order to identify the stored access authorization proof information o and the associated verification data c (step 830).
  • Step 830 is followed by a step 840 of determining the identifier of the individual from the access authorization proof information o and the verification data c.
  • the control server first determines the public key of the individual pk u . Then, from the determined public key pk u , the control server performs a search in the database of individuals BD-INDIV for the identifier of the individual ID U having the determined public key pk u .
  • Step 840 is followed by step 850 of sending the identifier of the determined individual ID U.
  • step 850 illustrates a second example of a system in which a control server determines the identity of the individual who requested verification of an access authorization.
  • the control server CONTROL comprises a secret disclosure key sk o and a public disclosure key pk o
  • the access authorization server is as described in [Fig. 4] and [Fig. 7] and comprises a public cryptographic data Gpk.
  • the public cryptographic data Gpk is specific for a group of individuals having at least one attribute conforming to at least one given rule. Said public cryptographic data is associated with a secret cryptographic data sk m .
  • the public cryptographic data Gpk comprises a public master key pk m and a public disclosure key pk o , the public disclosure key being the public key of the control server CONTROL.
  • the individual database BD-INDIV stores the identifier ID U of the individuals who have requested access authorization data from the access authorization server according to the embodiment described in the support of [Eig.4]. Each individual identifier ID U is associated with the public key pk u of the latter.
  • the BD-PREUVES evidence database comprises the various access authorization evidence information o submitted by individuals to the service provider to show that they are legitimate to access the service provider as described in the support of [Eig.7].
  • the verification request identifier SessionID and the verification data c are associated.
  • the date and time of receipt of the access authorization proof information by the access authorization server may also be stored for each stored evidence information.
  • the method for determining the identifier of an individual implemented in the CONTROL control server aims to lift the anonymity of the individual having requested verification of an access authorization.
  • the method for determining the identifier of an individual begins with steps 810 and 820 previously described in support of [Eig.8]. In addition, the method continues in step 925 by the control server obtaining the public cryptographic data Gpk, originating from the access authorization server SERV-AUTO. The method continues in step 830 previously described in support of [Eig.8].
  • the control server CONTROL has obtained the public cryptographic data Gpk, the data of verification c, and the access authorization proof information o. From the secret disclosure key sk o and the obtained data and information, the control server CONTROL determines the public key of the individual pk u who generated the access authorization proof information o.
  • step 840 previously described in support of [Fig.8] during which, from the determined public key pk u , the control server CONTROL will search in the database of individuals BD-INDIV for the identifier of the individual ID U having the determined public key pk u .
  • Step 840 is followed by step 850 of sending the identifier of the determined individual ID U.

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Security & Cryptography (AREA)
  • Computer Hardware Design (AREA)
  • Computing Systems (AREA)
  • General Engineering & Computer Science (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Financial Or Insurance-Related Operations Such As Payment And Settlement (AREA)
  • Computer And Data Communications (AREA)

Abstract

L'invention concerne un procédé de délivrance d'une donnée d'autorisation d'accès pour un individu ayant une clé publique et un attribut donné, mis en œuvre dans un serveur d'autorisation d'accès apte à communiquer avec un serveur d'identification et un dispositif client. Le serveur d'autorisation d'accès a une règle et une donnée cryptographique secrète, la donnée cryptographique secrète étant spécifique pour un groupe d'individus ayant un attribut conforme à la règle. Le procédé comprend notamment une étape d'obtention d'un attribut de l'individu, une étape de détermination d'une conformité de l'attribut de l'individu à la règle. Si l'attribut de l'individu est conforme à la règle alors le procédé comprend une étape de génération d'une donnée d'autorisation d'accès pour l'individu à partir de la donnée cryptographique secrète et de la clé publique de l'individu et une étape de délivrance de la donnée d'autorisation d'accès au dispositif client. L'invention concerne également un procédé de vérification d'une autorisation d'accès d'un individu.

Description

Description
Titre de l'invention : Procédé de délivrance d'une autorisation d'accès pour un individu et procédé de vérification
[0001] L'invention concerne un procédé et un dispositif de délivrance d'une donnée d'autorisation d'accès pour un individu et un procédé et un dispositif de vérification d'une autorisation d'accès d'un individu associés.
[0002] L'accès à des contenus, des services, des applications, des ressources ou des serveurs d'un fournisseur de services est très souvent contrôlé. En particulier, l'accès au fournisseur de services peut être autorisé pour une ou plusieurs catégories de personnes en fonction de caractéristiques propres à la personne ou en fonction de capacités de la personne. Autrement dit, si la personne possède une (ou plusieurs) caractéristique donnée ou une (ou plusieurs) capacité particulière, il dispose d'une autorisation d'accès. Dans le cas contraire, l'accès est refusé à la personne.
[0003] Le contrôle d'accès au fournisseur de services peut être réalisé de manière rudimentaire. Par exemple, avant d'entrer sur un site web spécifique, la personne doit simplement déclarer qu'elle est majeure, saisir une date de naissance ou cliquer sur un bouton du type "j'ai plus de 18 ans". Ce contrôle d'accès est donc soumis à une vérification qui est basée uniquement sur une déclaration de la personne. Ce contrôle est très souvent anonyme et peut être basé sur des informations erronées.
[0004] A l'inverse, le contrôle de l'accès au fournisseur de services peut être réalisé d'une manière très élaborée. Par exemple, avant de se connecter sur une site web d'un fournisseur de services, la personne doit s'enregistrer auprès de celui-ci et fournir ses informations personnelles telles que son nom, son prénom, son âge, son adresse et fournir des informations bancaires ou de carte d'identité. Il obtient alors un identifiant et un mot de passe permettant un accès ultérieur au site web du fournisseur de services. Dans ce cas, l'accès n'est pas anonyme et chaque connexion au site web peut être tracée.
[0005] Une autre solution consiste à utiliser une identité numérique. Cette dernière permet de réduire la divulgation d'informations d'identité de la personne et d'atteindre l'objectif de prouver que la personne possède une ou plusieurs caractéristiques propres ou des capacités particulières.
[0006] Toutefois, ces solutions ne sont pas satisfaisantes pour plusieurs raisons. Le contrôle d'accès à un fournisseur de services en fonction de caractéristiques propres à la personne est réalisé soit en fonction d'informations déclaratives pouvant être erronées soit suite à un enregistrement auprès de ce fournisseur de services avec la fourniture à ce dernier d'informations relatives à la personne. Ainsi, les solutions actuellement dis- ponibles ne permettent pas un accès au fournisseur de services fiable au regard des caractéristiques de la personne, anonyme et non traçable.
[0007] Le but de l'invention est de remédier à ces inconvénients et de permettre d'une part la délivrance d'une donnée d'autorisation d'accès pour un individu en fonction d'au moins un de ses attributs par un serveur d'autorisation d'accès afin que ce dernier apporte ensuite la preuve à un fournisseur de services qu'il possède au moins un attribut qui satisfasse le fournisseur de services.
[0008] D'autre part, l'invention permet une vérification d'une autorisation d'accès d'un individu, la vérification étant réalisée de manière anonyme et sans traçabilité des différents accès.
[0009] Ainsi, l'invention a pour objet un procédé de délivrance d'une donnée d'autorisation d'accès pour un individu ayant une clé publique et au moins un attribut donné, le procédé étant mis en œuvre dans un serveur d'autorisation d'accès apte à communiquer avec un serveur d'identification et un dispositif client, le serveur d'autorisation d'accès ayant au moins une règle donnée et une donnée cryptographique secrète, la donnée cryptographique secrète étant spécifique pour un groupe d'individus ayant au moins un attribut conforme à ladite au moins une règle donnée. Le procédé comprenant les étapes suivantes :
• obtention de la clé publique de l'individu ;
• obtention dudit moins un attribut de l'individu provenant du serveur d'identification ;
• détermination d'une conformité dudit au moins un attribut de l'individu obtenu à ladite au moins une règle donnée ;
• si ledit au moins un attribut de l'individu est conforme à ladite au moins une règle donnée, génération d'une donnée d'autorisation d'accès pour l'individu à partir de la donnée cryptographique secrète et de la clé publique de l'individu obtenue ;
• délivrance de la donnée d'autorisation d'accès générée au dispositif client. [0010] Le procédé conforme à l'invention permet la délivrance d'une information d'autorisation d'accès à un individu si ce dernier possède un ou plusieurs attributs conformes à une ou plusieurs règles. L'information d'autorisation d'accès permettra ultérieurement à l'individu de prouver à un fournisseur de services qu'il possède un ou plusieurs attributs, de manière fiable et anonyme.
[0011] Le serveur d'autorisation d'accès peut comprendre en outre une donnée cryptographique publique associée à ladite donnée cryptographique secrète, le procédé peut comprendre alors en outre une étape de transmission de la donnée cryptographique publique au dispositif client.
[0012] Le procédé peut comprendre en outre une étape de vérification de la possession d'une clé privée de l'individu par le dispositif client associée à la clé publique de l'individu obtenue, préalablement à la délivrance de la donnée d'autorisation d'accès.
[0013] Le procédé peut comprendre en outre une étape d'obtention d'un identifiant de demande d'une donnée d'autorisation d'accès et une étape de transmission de l'identifiant de demande d'une donnée d'autorisation d'accès au serveur d'identification.
[0014] L'identifiant de demande d'une donnée d'autorisation d'accès peut dans ce cas comprendre un identifiant de l'individu.
[0015] Alternativement, le procédé peut comprendre en outre, une étape d'obtention d'un identifiant de l'individu provenant du serveur d'identification ou du dispositif client.
[0016] L'invention a également pour objet un procédé de vérification d'une autorisation d'accès d'un individu ayant une donnée d'autorisation d'accès, la donnée d'autorisation d'accès ayant été délivrée conformément au procédé décrit précédemment. Le procédé est mis en œuvre dans un serveur d'autorisation d'accès apte à communiquer avec un fournisseur de services, le fournisseur de services mettant en œuvre un contrôle d'accès en fonction d'au moins un attribut de l'individu. Le serveur d'autorisation d'accès a une donnée cryptographique publique, la donnée cryptographique publique étant spécifique pour un groupe d'individus ayant au moins un attribut conforme à au moins une règle donnée, ladite donnée cryptographique publique étant associée à une donnée cryptographique secrète, ladite donnée cryptographique secrète ayant été utilisée pour générer la donnée d'autorisation d'accès. Le procédé comprend les étapes suivantes :
• réception d'une information de preuve d'autorisation d'accès, l'information de preuve d'autorisation d'accès ayant été générée au moyen de la donnée d'autorisation d'accès de l'individu ;
• vérification de l'information de preuve d'autorisation d'accès reçue en utilisant la donnée cryptographique publique ;
• si l'information de preuve d'autorisation d'accès est vérifiée, envoi au fournisseur de services d'une information de validation de l'information de preuve d'autorisation d'accès, sans vérification de la conformité d'au moins un attribut de l'individu à ladite au moins une règle donnée lors de la vérification de l'autorisation d'accès.
[0017] La donnée cryptographique publique peut être reçue du fournisseur de services ou d'un dispositif client.
[0018] L'information de preuve d'autorisation d'accès peut être reçue du fournisseur de services ou d'un dispositif client.
[0019] Le serveur d'autorisation d'accès peut en outre être apte à communiquer avec un dispositif client. Le procédé peut alors comprendre en outre, les étapes suivantes :
• réception d'un identifiant de demande de vérification provenant du fournisseur de services ; • génération d'une information de connexion à partir de l'identifiant de demande de vérification reçu ;
• transmission au fournisseur de services de l'information de connexion générée
• création d'un canal de communication entre le serveur d'autorisation d'accès et le dispositif client au moyen de l'information de connexion ;
• réception de l'information de preuve d'autorisation d'accès du dispositif client via le canal de communication créé.
[0020] Le serveur d'autorisation d'accès peut en outre être apte à communiquer avec un dispositif client. Le procédé peut alors comprendre en outre les étapes suivantes :
• génération d'une donnée de vérification ;
• transmission de la donnée de vérification générée au dispositif client ;
• l'information de preuve d'autorisation d'accès reçue étant en outre générée à partir de la donnée de vérification.
[0021] Le serveur d'autorisation d'accès peut être apte à communiquer avec une base de données de preuves, et le procédé peut alors comprendre en outre, une étape de transmission à ladite base de données de preuves de l'information de preuve d'autorisation d'accès reçue.
[0022] Le serveur d'autorisation d'accès peut comprendre en outre une donnée identifiant le groupe d'individus ayant au moins un attribut conforme à ladite au moins une règle donnée, et l'étape d'envoi au fournisseur de services d'une information de validation de l'information de preuve d'autorisation d'accès peut alors comprendre en outre l'envoi de la donnée identifiant le groupe d'individus.
[0023] L'invention a également pour objet un dispositif configuré pour mettre en œuvre au moins l'un des procédés précédemment décrits.
[0024] On va maintenant décrire des exemples de réalisation de la présente invention en référence aux figures annexées où les mêmes références désignent d'une figure à l'autre des éléments identiques ou fonctionnellement semblables :
[0025] [Fig-1] illustre un exemple d'un système dans lequel un procédé de délivrance d'une donnée d'autorisation d'accès pour un individu conformément à l'invention et un procédé de vérification d'une autorisation d'accès d'un individu conformément à l'invention peuvent être mis en œuvre.
[0026] [Fig.2] illustre un mode de réalisation du procédé de délivrance d'une donnée d'autorisation d'accès pour un individu conformément à l'invention.
[0027] [Fig.3] illustre un premier exemple de système dans lequel un serveur d'autorisation d'accès met en œuvre un mode de réalisation du procédé de délivrance d'une donnée d'autorisation d'accès pour un individu conformément à l'invention.
[0028] [Fig.4] illustre un deuxième exemple de système dans lequel un serveur d'autorisation d'accès met en œuvre un autre mode de réalisation du procédé de délivrance d'une donnée d'autorisation d'accès pour un individu conformément à l'invention.
[0029] [Fig.5] illustre un mode de réalisation du procédé de vérification d'une autorisation d'accès d'un individu conformément à l'invention.
[0030] [Fig.6] illustre un premier exemple de système dans lequel un serveur d'autorisation d'accès met en œuvre un mode de réalisation du procédé de vérification d'une autorisation d'accès d'un individu conformément à l'invention.
[0031] [Fig.7] illustre un deuxième exemple de système dans lequel un serveur d'autorisation d'accès met en œuvre un autre mode de réalisation du procédé de vérification d'une autorisation d'accès d'un individu conformément à l'invention.
[0032] [Fig.8] illustre un premier exemple de système dans lequel un serveur de contrôle met en œuvre un mode de réalisation d'un procédé de détermination de l'identité de l'individu ayant demandé une vérification d'une autorisation d'accès.
[0033] [Fig.9] illustre un deuxième exemple de système dans lequel un serveur de contrôle met en œuvre un mode de réalisation d'un procédé de détermination de l'identité de l'individu ayant demandé une vérification d'une autorisation d'accès.
[0034] La présente invention concerne selon un premier aspect, une manière sûre et fiable, de délivrer une donnée d'autorisation d'accès pour un individu ayant une clé publique et au moins un attribut donné permettant ultérieurement un accès anonyme et non- traçable de l'individu auprès d'un fournisseur de services disposant d'un contrôle d'accès en fonction d'attributs de l'individu.
[0035] Un contrôle d'accès en fonction d'un ou plusieurs attributs de l'individu autorise l'accès de l'individu uniquement si celui-ci est capable d'apporter la preuve qu'un ou plusieurs de ses attributs sont conformes à une ou plusieurs règles. Un tel contrôle d'accès permet de filtrer l'accès de l'individu à un contenu, des services, des applications, des ressources ou des serveurs d'un fournisseur de services. La délivrance d'une donnée d'autorisation d'accès est fonction d'au moins un attribut donné de l'individu.
[0036] La donnée d'autorisation d'accès est générée pour un individu de sorte à permettre ultérieurement à ce dernier un accès anonyme, donc sans avoir à divulguer son identité et ses attributs. La donnée d'autorisation d'accès a un rôle d'attestation numérique anonyme certifiant que l'individu a au moins un attribut conforme à une règle donnée. En particulier, l'invention concerne un procédé de délivrance d'une donnée d'autorisation d'accès pour un individu ayant une clé publique et au moins un attribut donné, mis en œuvre dans un serveur d'autorisation d'accès.
[0037] La présente invention concerne selon un deuxième aspect une manière sûre et fiable de réaliser une vérification d'autorisation d'accès d'un individu souhaitant accéder à un fournisseur de services mettant en œuvre un contrôle d'accès en fonction d'au moins un attribut de l'individu. La vérification est réalisée au moyen d'une information de preuve d'autorisation d'accès générée à partir de la donnée d'autorisation d'accès préalablement générée pour l'individu. Une telle vérification d'autorisation d'accès permet de s'assurer que l'individu a effectivement au moins un attribut conforme à au moins une règle donnée et donc qu'il est légitime pour accéder au fournisseur de services. Toutefois, la vérification est réalisée sans avoir à vérifier effectivement la conformité du ou des attributs de l'individu à une ou des règles données, la conformité ayant été réalisée précédemment par la délivrance de la donnée d'autorisation d'accès.
[0038] Ainsi, il est rendu possible de vérifier une autorisation d'accès d'un individu à un fournisseur de services au moyen d'une information de preuve d'autorisation d'accès générée à partir de la donnée d'autorisation d'accès de l'individu, de manière anonyme et sans pouvoir tracer les connexions de l'individu. En particulier, l'invention concerne un procédé de vérification d'une autorisation d'accès d'un individu ayant une donnée d'autorisation d'accès mis en œuvre dans un serveur d'autorisation d'accès.
[0039] Un attribut d'un individu est une caractéristique d'un individu, telle que son âge, sa région de domiciliation, son pays de domiciliation, etc., ou une capacité de l'individu, telle que la possession du permis de conduire ou d'un permis de travail. L'attribut peut également comprendre le fait pour un individu de disposer d'un compte d'accès auprès d'un organisme, tel qu'un organisme public, une banque, etc.
[0040] Conformément à l'invention, une donnée d'autorisation d'accès est délivrée à un individu, si un attribut de ce dernier est conforme à une règle donnée ou si des attributs de l'individu sont conformes respectivement à des règles données. Une règle a pour but de définir un critère d'accès. Par exemple, une règle relative à l'attribut "âge" peut être "avoir plus de 18 ans", une règle relative aux capacités de l'individu peut être "avoir un permis de conduire".
[0041] En référence à la [Fig.1], il est décrit un exemple d'un système dans lequel peut être mis en œuvre un procédé de délivrance d'une donnée d'autorisation d'accès pour un individu conformément à l'invention et un procédé de vérification d'une autorisation d'accès d'un individu conformément à l'invention.
[0042] Le système comprend un individu INDIV, au moins un dispositif client à la disposition de l'individu DEV, un serveur d'autorisation d'accès SERV-AUTO, un fournisseur de services FRS-SERV et un serveur d'identification IDP. Il peut comprendre en outre un support d'identité CAP de l'individu INDIV et un dispositif de contrôle CONTROL.
[0043] Un individu INDIV est un utilisateur qui souhaite accéder à un contenu, une application, un service, un serveur, etc. d'un fournisseur de services en utilisant un dispositif client DEV. Il a un identifiant IDU, au moins un attribut donné ATT, une clé publique pku et une clé secrète sku associée. Pour prouver qu'il possède l'attribut ou les attributs nécessaires à la connexion au fournisseur de services, il va tout d'abord obtenir une donnée d'autorisation d'accès qui peut être mémorisée dans un espace sécurisé du dispositif client. Ensuite, il va générer une information de preuve afin de prouver qu'il dispose d'une autorisation d'accès pour une connexion au fournisseur de services, sans toutefois divulguer à ce dernier son identité et ses attributs ATT. Autrement dit, il va générer une information de preuve qui devra être vérifiée permettant de certifier au fournisseur de services qu'il dispose du ou des attributs lui permettant une connexion à ce dernier sans toutefois que le fournisseur de services n'est accès à l'identité et aux attributs ATT de l'individu.
[0044] Le dispositif client DEV peut être tout type de dispositif, tel qu'un téléphone portable, une tablette, un ordinateur, etc., comprenant une plateforme matérielle et logicielle sur laquelle s'exécutent des logiciels, ces logiciels étant soit directement exécutables soit interprétés sur une machine virtuelle. Le dispositif client DEV comprend en particulier une interface de communication homme-machine permettant d'afficher des données et de recevoir des données provenant de l'individu INDIV. Cette interface de communication homme-machine comprend par exemple un écran et un clavier, ou un écran tactile. Le dispositif client DEV peut comprendre un navigateur Internet s'exécutant sur l'interface de communication homme-machine. Le dispositif client est apte à communiquer avec le serveur d'autorisation d'accès SERV-AUTO, le fournisseur de services FRS-SERV et le serveur d'identification IDP. Il peut aussi communiquer avec le support d'identité CAP. Pour cela, le dispositif client DEV est muni de moyens de communication (filaire ou sans fil). Par exemple, le dispositif client DEV peut comprendre une connectivité de type réseau, soit via une connexion filaire soit via une connexion sans fil (par exemple, conforme à la norme Bluetooth, à la norme NFC, à la norme WIFI ou à la norme PC/SC) pour une communication avec le support d'identité CAP et peut comprendre des moyens de communication réseau conformes à l'une quelconques des normes Ethernet, et/ou conformes à l'une quelconque des normes IEEE 802.11 (Wifi), et/ou conformes à une ou plusieurs normes de téléphonie mobile (2G, 3G, 4G, etc.) pour une communication avec le serveur d'autorisation d'accès SERV-AUTO, le fournisseur de services FRS-SERV et le serveur d'identification IDP.
[0045] Le support d'identité CAP est un moyen mémorisant des informations propres à l'individu INDIV. Il peut comprendre notamment un identifiant de l'individu IDU, le ou les attributs ATT de ce dernier et/ou une clé privée sku et une clé publique pku de l'individu. Il peut s'agir par exemple, d'une carte d'identité électronique, d'un passeport électronique ou d'une carte bancaire. Il comprend des moyens de connectivité, notamment des moyens de communication sans fil (par exemple, conforme à la norme Bluetooth, à la norme NFC ou à la norme PC/SC) afin d'être apte à communiquer avec un dispositif client DEV. Le support d'identité CAP peut comprendre en outre, une fonction d'établissement d'un canal de communication sécurisé permettant la création d'un canal de communication sécurisé entre le support d'identité CAP et le dispositif client DEV. L'établissement d'un canal de communication sécurisé s'appuie sur l'utilisation de protocoles de sécurité. Le dispositif client DEV peut également comprendre en outre, une fonction d'établissement d'un canal de communication sécurisé permettant la création d'un canal sécurisé entre le dispositif client DEV et le support d'identité CAP. L'établissement d'un canal de communication sécurisé s'appuie sur l'utilisation de protocoles de sécurité.
[0046] Selon un mode de réalisation dans lequel le système ne comprend pas de support d'identité CAP, l'identifiant de l'individu IDU, le ou les attributs ATT de ce dernier et/ou une clé privée sku et une clé publique pku de l'individu INDIV peuvent être mémorisés dans le dispositif client DEV, notamment dans un espace mémoire sécurisé.
[0047] Le serveur d'identification IDP comprend une plateforme matérielle et logicielle sur laquelle s'exécutent des logiciels. Il peut être utilisé pour authentifier un individu, notamment à partir de l'identifiant de ce dernier IDU, et il peut fournir, notamment au serveur d'autorisation d'accès, le ou les attributs ATT de l'individu INDIV dont il a eu régulièrement la connaissance. En particulier, le serveur d'identification IDP mémorise pour un ensemble d'individus, leur identifiant IDU et un ou plusieurs attributs ATT de ces individus. Un serveur d'identification IDP est, par exemple un fournisseur d'identité gouvernemental, une banque ou un espace sécurisé de données. Le serveur d'identification IDP peut comprendre une fonction d'établissement d'un canal de communication sécurisé permettant la création d'un canal sécurisé entre le serveur d'identification IDP et le dispositif client DEV ou entre le serveur d'identification IDP et le serveur d'autorisation d'accès SERV-AUTO. L'établissement d'un canal de communication sécurisé s'appuie sur l'utilisation de protocoles de sécurité La connexion au serveur d'identification IDP nécessite une authentification sévère. Pour cela, différentes technologies peuvent être utilisées telles que OpenID, SAML, ISO 18013 ou IS02020.
[0048] Le fournisseur de services ERS-SERV est par exemple un fournisseur de services d'applications ou un fournisseur d'applications en ligne. Autrement dit, il peut s'agir d'un fournisseur d'applications hébergées qui fournit des logiciels, des contenus ou des services informatiques à ses clients au travers d'un réseau Internet par exemple. L'accès à ces applications est notamment réalisé à travers un navigateur web et en utilisant un protocole standard comme le protocole http. Ainsi, le fournisseur de services ERS- SERV comprend une plateforme matérielle et logicielle sur laquelle s'exécutent des applications afin de fournir des logiciels, des services ou des contenus. Selon le cas, le fournisseur de services peut vouloir ou a une obligation de s'assurer que l'individu qui souhaite accéder à ces services, applications ou contenus appartienne à une certaine catégorie de personnes, par exemple que l'individu soit majeur. En d'autres termes, dans ce cas, le fournisseur de services met en œuvre un contrôle d'accès en fonction d'au moins un attribut de l'individu. Pour ce faire, le fournisseur de services communique avec le serveur d'autorisation d'accès SERV-AUTO.
[0049] Le serveur d'autorisation d'accès SERV-AUTO fournit un service qui délivre une donnée d'autorisation d'accès à un individu et qui vérifie une autorisation d'accès d'un individu pour prouver la légitimité d'un individu à accéder à un service, un contenu, une application, etc. d'un fournisseur de services. Le serveur d'autorisation d'accès est apte à mettre en œuvre tout ou partie du procédé de délivrance d'une donnée d'autorisation d'accès pour un individu ou du procédé de vérification d'une autorisation d'accès d'un individu conformément à l'invention. Tout ou partie du procédé de délivrance d'une donnée d'autorisation d'accès pour un individu et/ou tout ou partie du procédé de vérification d'une autorisation d'accès d'un individu peuvent être mis en œuvre sous forme logicielle et/ou sous forme de dispositifs). Les modes de réalisation du serveur d'autorisation d'accès SERV-AUTO décrits ci-après sont tels que le serveur d'autorisation d'accès SERV-AUTO est apte à mettre en œuvre tout ou partie du précédé de délivrance d'une information d'autorisation d'accès pour un individu et du procédé de vérification d'une autorisation d'accès d'un individu. Cependant, selon d'autres modes de réalisation, le procédé de délivrance d'une donnée d'autorisation d'accès pour un individu et le procédé de vérification d'une autorisation d'accès d'un individu peuvent être mis en œuvre dans des serveurs distincts.
[0050] Le serveur d'autorisation d'accès SERV-AUTO est apte à communiquer avec le fournisseur de services FRS-SERV et le serveur d'identification IDP en utilisant des moyens de connectivité dont est pourvu le serveur d'autorisation d'accès SERV-AUTO. Les moyens de connectivité du serveur d'autorisation d'accès SERV-AUTO peuvent comprendre des moyens des communication réseau conformes à l'une quelconques des normes Ethernet, et/ou conformes à l'une quelconque des normes IEEE 802.11 (Wifi), et/ou conformes à une ou plusieurs normes de téléphonie mobile (2G, 3G, 4G, etc.). Il peut en outre communiquer avec le dispositif client DEV et le serveur de contrôle CONTROL.
[0051] Le serveur d'autorisation d'accès SERV-AUTO comprend en outre, des moyens d'exécution d'un algorithme de calcul et d'échange de clés cryptographiques.
[0052] Un serveur de contrôle CONTROL peut être mis en œuvre pour révéler l'identité de l'individu qui a soumis une information de preuve d'autorisation d'accès au fournisseur de services. Toutefois, ce serveur est mis en œuvre notamment dans les modes de réalisation dans lesquels il est nécessaire de pouvoir retrouver l'identité de l'individu ayant soumis une information de preuve d'autorisation d'accès au fournisseur de services. [0053] La [Fig.2] illustre un mode de réalisation du procédé de délivrance d'une donnée d'autorisation d'accès pour un individu INDIV ayant une clé publique pku et au moins un attribut donné ATT conformément à l'invention. Les étapes en pointillées sur la figure sont optionnelles.
[0054] Le procédé est mis en œuvre dans un serveur d'autorisation d'accès SERV-AUTO apte à communiquer avec un serveur d'identification IDP et un dispositif client DEV.
[0055] Le serveur d'autorisation d'accès SERV-AUTO comprend au moins une règle donnée. Il comprend en outre une paire de données cryptographiques spécifiques pour un groupe d'individus ayant au moins un attribut conforme à ladite au moins une règle donnée. La paire de données cryptographiques comprend une donnée cryptographique secrète et une donnée cryptographique publique. Un groupe d'individus comprend un ensemble d'individus ayant obtenu une information d'autorisation d'accès car le ou les attributs de ces individus sont conformes à ladite au moins une règle donnée.
[0056] Le procédé peut débuter par une étape d'obtention d'un identifiant de demande d'une donnée d'autorisation d'accès (étape 210). Cette étape peut résulter de la génération de l'identifiant de la demande par le dispositif client DEV et le service d'autorisation d'accès SERV-AUTO.
[0057] L'identifiant de demande d'une donnée d'autorisation d'accès est par exemple un identifiant de session établi entre le dispositif client et le serveur d'autorisation d'accès ou un code d'authentification.
[0058] Selon un mode de réalisation, l'identifiant de demande d'une donnée d'autorisation d'accès est obtenu par la génération d'un identifiant par le dispositif client et le serveur d'autorisation d'accès suite, par exemple, à l'échange de messages pour la création d'un canal de communication.
[0059] Selon un mode de réalisation particulier, l'identifiant de demande d'une donnée d'autorisation d'accès peut comprendre un identifiant de l'individu IDU.
[0060] L'identifiant de l'individu IDU est par exemple un identifiant personnel de cet individu. Il peut s'agir d'un identifiant attribué par un organisme spécifique (par exemple, un fournisseur d'identité gouvernemental, une banque, etc.). Ainsi, l'identifiant de l'individu IDU peut être un numéro d'identification ou des données personnelles comme un nom, un numéro de téléphone et/ou une date de naissance.
[0061] L'étape 210 est suivie d'une étape d'obtention de la clé publique de l'individu pku (étape 220). Selon un mode de réalisation particulier, l'étape 220 peut également comprendre l'obtention d'un identifiant de l'individu IDU associé à la clé publique de l'individu pku.
[0062] L'étape 220 peut être suivie d'une étape 230 de transmission de l'identifiant de demande d'une donnée d'autorisation d'accès au serveur d'identification IDP (étape optionnelle) Cette étape peut permettre au serveur d'identification IDP d'initier un processus d'authentification avec l'individu notamment au moyen du dispositif client DEV (via ou non le serveur d'autorisation d'accès).
[0063] Le procédé se poursuit par une étape 240 d'obtention d'au moins un attribut ATT de l'individu INDIV. L'étape 240 d'obtention d'au moins un attribut ATT est réalisée par la réception dudit au moins un attribut de l'individu INDIV transmis directement ou indirectement par le serveur d'identification IDP au serveur d'autorisation d'accès SERV- AUTO. Le ou les attributs d'un individu sont déterminées par le serveur d'identification IDP par exemple après l'authentification de l'individu auprès du serveur d'identification IDP ou à partir de l'identifiant de l'individu IDU.
[0064] Selon un mode de réalisation particulier, le procédé peut également comprendre une étape d'obtention d'un identifiant de l'individu IDU provenant du serveur d'identification IDP, notamment dans le cas où l'identifiant de l'individu IDU n'a pas été transmis par le dispositif client. L'identifiant de l'individu IDU est alors associée à la clé publique de l'individu reçue.
[0065] L'étape 240 est suivie d'une étape 250 de détermination d'une conformité dudit au moins un attribut ATT de l'individu obtenu à ladite au moins une règle donnée du serveur d'autorisation d'accès.
[0066] Selon un exemple particulier, l'attribut de l'individu comprend la donnée selon laquelle l'individu est en possession d'un permis de conduire et la règle définit un critère relatif à la possession du permis de conduire. Dans le présent exemple, l'attribut de l'individu est conforme à la règle puisque l'attribut est conforme au critère.
[0067] L'étape 250 est suivie d'une étape 260 de test relatif à la conformité dudit au moins un attribut ATT de l'individu à ladite au moins une règle donnée. Si le test est négatif, l'étape 260 est suivie d'une étape 270 de fin du procédé et aucune donnée d'autorisation d'accès n'est générée et délivrée à l'individu. Si, au contraire, le test de l'étape 260 est positif, alors l'étape 260 est suivie d'une étape 280 de génération d'une donnée d'autorisation d'accès pour l'individu à partir de la donnée cryptographique secrète et de la clé publique de l'individu pku obtenue.
[0068] Dans le mode de réalisation dans lequel le serveur d'autorisation d'accès a obtenu l'identifiant de l'individu IDU, la donnée d'autorisation d'accès pour l'individu est en outre générée à partir de l'identifiant de l'individu IDU.
[0069] L'étape 280 est ensuite suivie d'une étape 290 de délivrance de la donnée d'autorisation d'accès générée au dispositif client DEV. Cette étape comprend par exemple l'envoi de la donnée d'autorisation d'accès générée au dispositif client.
[0070] Le procédé de délivrance peut en outre comprendre une étape de transmission de la donnée cryptographique publique au dispositif client DEV.
[0071] Selon un mode de réalisation, préalablement à l'étape de délivrance de la donnée d'autorisation d'accès générée, le procédé peut comprendre en outre une étape de véri- fication de la possession de la clé privée sku par l'individu, en particulier par le dispositif client de l'individu, associée à la clé publique de l'individu pku obtenue et utilisée pour la génération de la donnée d'autorisation d'accès. Cette étape permet au serveur d'autorisation d'accès de s'assurer que la donnée d'autorisation d'accès générée est délivrée à l'individu possédant la clé publique utilisée pour la génération de la donnée d'autorisation d'accès.
[0072] Selon un mode de réalisation particulier dans lequel le serveur d'autorisation d'accès a obtenu l'identifiant de l'individu IDU, le procédé comprend en outre une étape de mémorisation dans une base de données d'individus BD-INDIV, de l'identifiant de l'individu IDU et de la clé publique pku de cet individu. La base de données d'individus peut être mémorisées sur un serveur distinct du serveur d'autorisation d'accès.
[0073] Selon un autre mode de réalisation particulier du procédé de délivrance d'une donnée d'autorisation d'accès pour un individu, l'identifiant de l'individu IDU n'est pas fourni au serveur d'autorisation d'accès.
[0074] La [Fig.3] illustre un premier exemple d'un système comprenant un serveur d'autorisation d'accès SERV-AUTO lequel met en œuvre un mode de réalisation particulier du procédé de délivrance d'une donnée d'autorisation d'accès pour un individu ayant une clé publique pku et au moins un attribut donné ATT conformément à l'invention.
[0075] Le système illustré en [Fig.3] comprend en plus du serveur d'autorisation d'accès SERV-AUTO, un dispositif client DEV et un serveur d'identification IDP.
[0076] Le serveur d'autorisation d'accès SERV-AUTO comprend au moins une règle donnée. Il comprend en outre une paire de données cryptographiques spécifiques pour un groupe d'individus ayant au moins un attribut conforme à ladite au moins une règle donnée. La paire de données cryptographiques comprend une donnée cryptographique secrète et une donnée cryptographique publique. Un groupe d'individus comprend un ensemble d'individus ayant obtenu une information d'autorisation d'accès car le ou les attributs de ces individus sont conformes à ladite au moins une règle donnée.
[0077] Le dispositif client DEV est par exemple un téléphone portable. L'individu INDIV peut en outre être muni d'un support d'identité CAP comprenant notamment la clé publique pku de l'individu. Le support d'identité CAP peut également comprendre un identifiant de l'individu IDU associé à la clé publique pku de l'individu. Le dispositif client DEV comprend des moyens de communication avec le support d'identité CAP.
[0078] Selon un autre mode de réalisation, la clé publique pku de l'individu peut être mémorisée sur le dispositif client DEV.
[0079] Selon le système illustré, le serveur d'autorisation d'accès obtient un identifiant de demande d'une donnée d'autorisation d'accès (étape 310). Cette étape peut comprendre l'échange de messages entre le serveur d'autorisation d'accès SERV-AUTO et le dispositif client DEV permettant la génération et l'obtention d'un identifiant de demande d'une donnée d'autorisation d'accès. Cette étape aboutit à l'obtention par le serveur d'autorisation d'accès SERV-AUTO d'un identifiant de demande d'une donnée d'autorisation d'accès conformément à l'étape 210 précédemment décrite au support de la [Fig.2],
[0080] Selon un mode de réalisation particulier, l'identifiant de demande d'une donnée d'autorisation d'accès comprend en outre un identifiant de l'individu IDU.
[0081] Lors de l'étape 310, le serveur d'autorisation d'accès SERV-AUTO obtient la clé publique de l'individu pku (conformément à l'étape 220 décrite précédemment au support de la [Fig.2]). En particulier, le dispositif client peut envoyer la clé publique de l'individu pku au serveur d'autorisation d'accès SERV-AUTO.
[0082] Selon un mode de réalisation particulier, lors de l'étape 310, le serveur d'autorisation d'accès SERV-AUTO peut également obtenir l'identifiant de l'individu IDU.
[0083] L'étape 310 peut être suivie d'une étape de transmission par le serveur d'autorisation d'accès SERV-AUTO de l'identifiant de demande d'une donnée d'autorisation d'accès au serveur d'identification IDP (étape 320 qui conforme à l'étape 210 précédemment décrite au support de la [Fig.2]).
[0084] Selon un autre mode de réalisation, l'étape 320 est une étape de création d'un canal de communication sécurisé entre le serveur d'autorisation d'accès SERV-AUTO et le serveur d'identification IDP.
[0085] Selon le mode de réalisation illustré, l'étape 320 est suivie d'une phase d'authentification par l'individu auprès du serveur d'identification IDP, par exemple au moyen du dispositif client.
[0086] Pour cela, selon un premier mode de réalisation illustré à la [Fig.3], le serveur d'identification IDP communique avec le dispositif client DEV afin que l'individu s'authentifie (étape 330). Cela est possible notamment lorsque l'identifiant de demande d'une donnée d'autorisation d'accès reçu par le serveur d'identification IDP comprend l'identifiant de l'individu IDU.
[0087] Selon un autre mode de réalisation, l'authentification de l'individu peut être réalisée via le serveur d'autorisation d'accès, ce dernier ayant alors un rôle de proxy.
[0088] Selon encore un autre mode de réalisation, l'individu s'authentifie auprès du serveur d'identification IDP au moyen de son dispositif client DEV préalablement à l'étape 310 puis le dispositif client transmet au serveur d'autorisation d'accès, l'identifiant de l'individu IDU authentifié.
[0089] Suite à l'authentification de l'individu auprès du serveur d'identification IDP, ce dernier transmet au serveur d'autorisation d'accès SERV-AUTO au moins un attribut ATT de l'individu (étape 340). Ainsi, le service d'autorisation d'accès SERV-AUTO obtient au moins un attribut ATT de l'individu provenant du serveur d'identification IDP conformément à l'étape 240 précédemment décrite au support de la [Fig.2].
[0090] Selon un mode de réalisation particulier, le serveur d'identification IDP transmet au serveur d'autorisation d'accès SERV-AUTO au moins un attribut ATT de l'individu via le dispositif client DEV.
[0091] Selon un mode de réalisation particulier, le serveur d'autorisation d'accès peut en outre obtenir du serveur d'identification un identifiant de l'individu IDU.
[0092] L'étape 340 est suivie d'une étape 350 au cours de laquelle le serveur d'autorisation d'accès SERV-AUTO va déterminer la conformité dudit au moins un attribut ATT de l'individu obtenu à ladite au moins une règle donnée conformément à l'étape 250 décrit au support de la [Fig.2]. Si ledit au moins un attribut ATT de l'individu est conforme à ladite au moins une règle donnée, le serveur d'autorisation d'accès SERV-AUTO génère une donnée d'autorisation d'accès pour l'individu à partir de la donnée cryptographique secrète et de la clé publique de l'individu pku obtenue, conformément aux étapes 260 et 280 précédemment décrites au support de la [Fig.2].
[0093] Dans le mode de réalisation dans lequel le serveur d'autorisation d'accès a obtenu l'identifiant de l'individu IDU, la donnée d'autorisation d'accès pour l'individu est en outre générée à partir de l'identifiant de l'individu IDU.
[0094] L'étape 350 est suivie d'une étape 360 de délivrance par le serveur d'autorisation d'accès SERV-AUTO de la donnée d'autorisation d'accès générée au dispositif client DEV conformément à l'étape 290 précédemment décrite au support de la [Fig.2]. Pour cela, le serveur d'autorisation d'accès SERV-AUTO envoie un message au dispositif client DEV contenant la donnée d'autorisation d'accès générée.
[0095] Selon un mode de réalisation particulier, l'étape de délivrance de la donnée d'autorisation d'accès est précédée d'une étape de vérification de la possession de la clé privée sku par l'individu, en particulier par le dispositif client de l'individu, associée à la clé publique de l'individu pku obtenue. Cette étape permet au serveur d'autorisation d'accès de vérifier avant de communiquer la donnée d'autorisation d'accès au dispositif client, que ce dernier dispose de la clé secrète de l'individu.
[0096] Dans le mode de réalisation particulier dans lequel le serveur d'autorisation d'accès a obtenu l'identifiant de l'individu IDU, le serveur d'autorisation d'accès peut comprendre en outre une étape de mémorisation dans une base de données d'individus BD-INDIV, de l'identifiant de l'individu IDU et de la clé publique de cet individu pku. D'autres informations additionnelles relatives à l'individu peuvent également être mémorisées dans la base de données d'individus BD-INDIV. La base de données d'individus BD- INDIV peut être mémorisée sur un serveur distinct du serveur d'autorisation d'accès.
[0097] La [Fig.4] illustre un deuxième exemple d'un système comprenant un serveur d'autorisation d'accès SERV-AUTO lequel met en œuvre un autre mode de réalisation du procédé de délivrance d'une donnée d'autorisation d'accès pour un individu conformément à l'invention et décrit au support de la [Eig.2].
[0098] On ne décrira en détail ci-après que les étapes qui diffèrent de celles du premier exemple de système décrit au support de la [Fig.3]. Pour le reste, il est renvoyé au premier exemple décrit au support de la [Fig.3].
[0099] Le serveur d'autorisation d'accès comprend au moins une règle donnée.
[0100] Dans cet exemple de système, l'individu comprend une paire de clés, à savoir une clé privée sku et une clé publique pku mémorisées par exemple sur un dispositif client DEV ou dans un support d'identité CAP et le serveur de contrôle CONTROL comprend une clé de divulgation secrète sko et une clé de divulgation publique pko
[0101] La clé de divulgation publique pko du serveur de contrôle CONTROL est transmise au serveur d'autorisation d'accès SERV-AUTO (étape 400).
[0102] Suite à la réception de la clé de divulgation publique pko provenant du serveur de contrôle CONTROL, le serveur d'autorisation d'accès SERV-AUTO va générer une paire de données cryptographique spécifique pour un groupe d'individus ayant au moins un attribut conforme à ladite au moins une règle donnée. La paire de données cryptographique comprend une donnée cryptographique publique Gpk et une donnée cryptographique secrète skm.
[0103] Dans l'exemple de réalisation illustré en [Eig.4], la donnée cryptographique publique Gpk comprend au moins une clé maitre publique pkm et la clé de divulgation publique pko reçue du serveur de contrôle CONTROL.
[0104] Selon un autre mode de réalisation dans lequel le système ne comprend pas de serveur de contrôle CONTROL, le serveur d'autorisation d'accès comprend une paire de données cryptographique spécifique pour un groupe d'individus ayant au moins un attribut conforme à ladite au moins une règle donnée. La paire de données cryptographique comprend d'une part, une donnée cryptographique publique Gpk composée d'une clé maitre publique pkm et d'autre part, une donnée cryptographique secrète skm.
[0105] La donnée cryptographique publique Gpk peut ensuite être transmise au dispositif client DEV.
[0106] Selon le système illustré, le serveur d'autorisation d'accès obtient un identifiant de demande d'une donnée d'autorisation d'accès (étape 410) conformément à l'étape 210 précédemment décrite au support de la [Eig.2].
[0107] Selon un mode de réalisation particulier, l'identifiant de demande d'une donnée d'autorisation d'accès (étape 410) peut être déterminé par le dispositif client à partir notamment de la clé secrète sku de l'individu et de la donnée cryptographique publique Gpk reçue. Il peut en outre être déterminé à partir de l'identifiant de l'individu IDU. L'identifiant de demande d'une donnée d'autorisation d'accès est ensuite transmis par le dispositif client et reçu par le serveur d'autorisation d'accès.
[0108] Lors de l'étape 410, le serveur d'autorisation d'accès SERV-AUTO obtient la clé publique de l'individu pku (conformément à l'étape 220 décrite précédemment au support de la [Fig.2]). En particulier, le dispositif client peut envoyer la clé publique de l'individu pku au serveur d'autorisation d'accès SERV-AUTO.
[0109] L'étape 410 est ensuite suivie des étapes 320 à 340 précédemment décrites.
[0110] A l'issue de l'étape 340, le serveur d'autorisation d'accès SERV-AUTO va déterminer la conformité dudit au moins un attribut ATT de l'individu obtenu à ladite au moins une règle donnée conformément à l'étape 240 décrite précédemment au support de la [Fig.2]. Si ledit au moins un attribut ATT de l'individu est conforme à ladite au moins une règle donnée, le serveur d'autorisation d'accès SERV-AUTO génère une donnée d'autorisation d'accès pour l'individu gsku à partir de la donnée cryptographique secrète skm et de la clé publique de l'individu pku obtenue, conformément aux étapes 260 et 280 précédemment décrites au support de la [Fig.2].
[0111] L'étape 450 est suivie d'une étape 46O.a de délivrance de la donnée d'autorisation d'accès gsku générée, au dispositif client DEV.
[0112] Dans le mode de réalisation dans lequel le serveur d'autorisation d'accès a reçu l'identifiant de l'individu IDU l'étape 450 peut également être suivie d'une étape 46O.b de mémorisation par le serveur d'autorisation d'accès, dans une base de données d'individus BD-INDIV de l'identifiant de l'individu IDU et de la clé d'individu publique pku de cet individu. D'autres informations additionnelles relatives à l'individu peuvent également être mémorisées dans la base de données d'individus BD-INDIV. La base de données d'individus BD-INDIV peut être stockée sur un serveur distinct du serveur d'autorisation d'accès.
[0113] La [Fig.5] illustre un mode de réalisation d'un procédé de vérification d'une autorisation d'accès d'un individu ayant une donnée d'autorisation d'accès mis en œuvre dans un serveur d'autorisation d'accès SERV-AUTO conformément à l'invention. La donnée d'autorisation d'accès a été délivrée conformément au procédé de délivrance d'une donnée d'autorisation d'accès précédemment décrit.
[0114] Le serveur d'autorisation d'accès SERV-AUTO est apte à communiquer avec un fournisseur de services FRS-SERV mettant en œuvre un contrôle d'accès en fonction d'au moins un attribut de l'individu.
[0115] Le serveur d'autorisation d'accès SERV-AUTO comprend une donnée cryptographique publique, la donnée cryptographique publique étant spécifique pour un groupe d'individus ayant au moins un attribut conforme à au moins une règle donnée. La donnée cryptographique publique est associée à une donnée cryptographique secrète, ladite donnée cryptographique secrète ayant été utilisée pour générer la donnée d'autorisation d'accès de l'individu.
[0116] Selon un mode de réalisation particulier, la donnée cryptographique publique peut être reçue par le serveur d'autorisation d'accès et provenir du fournisseur de services FRS-SERV. Selon un autre mode de réalisation dans lequel le serveur d'autorisation d'accès SERV-AUTO est apte à communiquer avec un dispositif client DEV de l'individu, la donnée cryptographique publique peut être reçue par le serveur d'autorisation d'accès et provenir du dispositif client DEV.
[0117] Le serveur d'autorisation d'accès SERV-AUTO mettant en œuvre le procédé de vérification d'une autorisation d'accès peut être le même serveur que celui mettant en œuvre le procédé de délivrance d'une information d'autorisation d'accès ou un serveur distinct.
[0118] Le procédé de vérification d'une autorisation d'accès peut faire suite au procédé de délivrance d'une donnée d'autorisation d'accès précédemment décrit au support de la [Fig.2] et des figures suivantes.
[0119] L'objet du procédé de vérification d'une autorisation d'accès est de vérifier que l'individu dispose de l'autorisation d'accès pour accéder à un fournisseur de services mettant en œuvre un contrôle d'accès en fonction d'au moins un attribut de l'individu, sans vérification de la conformité du ou des attributs de l'individu à une ou plusieurs règles données lors de la vérification de l'autorisation d'accès. En outre, la vérification n'utilise pas non plus, un identifiant de l'individu.
[0120] Ainsi, ce procédé permet un contrôle d'accès d'un individu à un fournisseur de services mettant en œuvre un contrôle d'accès en fonction d'au moins un attribut de l'individu tout en garantissant un accès anonyme et non traçable de l'individu.
[0121] La non-traçabilité consiste à ne pas pouvoir identifier les différents accès d'un même individu au fournisseur de services. En d'autres termes, le système et le fournisseur de services ne peuvent pas déterminer si deux accès distincts appartiennent à un même individu (ou non).
[0122] Selon ce procédé, l'individu doit apporter une preuve qu'un ou plusieurs de ses attributs sont conformes à une ou plusieurs règles, les règles définissant les critères du contrôle d'accès du fournisseur de services. Pour cela, la preuve est une information de preuve d'autorisation d'accès générée par le dispositif client au moyen de la donnée d'autorisation d'accès qui lui a été précédemment délivrée.
[0123] En outre, selon le procédé de vérification conforme à l'invention, le ou les attributs ATT de l'individu ne sont pas communiquées au fournisseur de services. Toutefois, si l'information de preuve d'autorisation d'accès est validée par le procédé de vérification, le fournisseur de services mettant en œuvre un contrôle d'accès en fonction d'au moins un attribut de l'individu sait uniquement que la ou les règles relatives à un ou plusieurs attributs ATT de l'individu sont respectées.
[0124] Tel qu'illustré à la [Fig.5], le procédé de vérification d'une autorisation d'accès d'un individu ayant une donnée d'autorisation d'accès débute par une étape de réception d'une information de preuve d'autorisation d'accès (étape 510). L'information de preuve d'autorisation d'accès a été générée au moyen de la donnée d'autorisation d'accès de l'individu, notamment par le dispositif client de l'individu. L'information de preuve d'autorisation d'accès peut parvenir au serveur d'autorisation d'accès à partir du fournisseur de services ou du dispositif client de l'individu.
[0125] Cette étape peut être précédée d'une étape de génération d'une donnée de vérification c par le serveur d'autorisation d'accès, d'une étape de transmission de la donnée de vérification générée au dispositif client DEV. Dans ce cas, l'information de preuve d'autorisation d'accès reçue peut être en outre générée à partir de la donnée de vérification.
[0126] L'étape 510 est suivie d'une étape 520 de vérification de l'information de preuve d'autorisation d'accès reçue en utilisant la donnée cryptographique publique.
[0127] L'étape 520 est suivie d'une étape 530 de test de la vérification de l'information de preuve d'autorisation d'accès. Si l'information de preuve d'autorisation d'accès n'a pas pu être vérifiée, alors l'étape 530 est suivie de l'étape 540 au cours de laquelle le serveur d'autorisation d'accès peut indiquer au fournisseur de services que l'information de preuve d'autorisation d'accès est non valide.
[0128] Si, au contraire, l'information de preuve d'autorisation d'accès a pu être vérifiée, autrement dit l'information de preuve d'autorisation d'accès est valide, alors l'étape 530 est suivie d'une étape 550 d'envoi au fournisseur de services ERS-SERV d'une information de validation de l'information de preuve d'autorisation d'accès. Ainsi, lors de la vérification de l'autorisation d'accès, le serveur d'autorisation d'accès ne réalise pas de vérification de la conformité du ou des attributs de l'individu à une ou plusieurs règles données. En outre, le serveur d'autorisation d'accès n'utilise pas un identifiant de l'individu pour réaliser la vérification de l'autorisation d'accès.
[0129] Selon un mode de réalisation particulier, le serveur d'autorisation d'accès comprend en outre une donnée identifiant le groupe d'individus ayant au moins un attribut conforme à ladite au moins une règle donnée IdToken. Selon ce mode de réalisation l'étape d'envoi au fournisseur de services FRS-SERV d'une information de validation de l'information de preuve d'autorisation d'accès comprend en outre l'envoi de la donnée identifiant le groupe d'individus IdToken.
[0130] La [Fig.6] illustre un premier exemple d'un système comprenant un serveur d'autorisation d'accès SERV-AUTO lequel met en œuvre un mode de réalisation particulier du procédé de vérification d'une autorisation d'accès d'un individu conformément à l'invention.
[0131] L'individu a une donnée d'autorisation d'accès précédemment délivrée conformément au procédé de délivrance d'une donnée d'autorisation d'accès décrit notamment au support de la [Fig.2].
[0132] Le serveur d'autorisation d'accès SERV-AUTO comprend une donnée crypto- graphique publique, la donnée cryptographique publique étant spécifique pour un groupe d'individus ayant au moins un attribut conforme à au moins une règle donnée. La donnée cryptographique publique est associée à une donnée cryptographique secrète, ladite donnée cryptographique secrète spécifique ayant été utilisée pour générer la donnée d'autorisation d'accès de l'individu.
[0133] Selon un mode de réalisation particulier, la donnée cryptographique publique est mémorisée dans le serveur d'autorisation d'accès. Selon un autre mode de réalisation, la donnée cryptographique publique est reçue par le serveur d'autorisation d'accès du fournisseur de services FRS-SERV. Selon encore un autre mode de réalisation, la donnée cryptographique publique est reçue par le serveur d'autorisation d'accès du dispositif client DEV.
[0134] Le système illustré en [Fig.6] comprend en plus du serveur d'autorisation d'accès SERV-AUTO, un fournisseur de services FRS-SERV, un serveur d'identification IDP ou un serveur comprenant une base de données BD-PREUVES et un ou plusieurs dispositifs client DEVI, DEV2 d'un individu INDIV. La [Fig.6] illustre un système particulier dans lequel l'individu INDIV dispose d'un premier dispositif client DEV 1 et d'un second dispositif client DEV2 qui peuvent être par exemple un ordinateur portable et un téléphone portable. Dans le système illustré, la donnée d'autorisation d'accès de l'individu est par exemple mémorisée dans le second dispositif client DEV2. Toutefois, selon un autre mode de réalisation du système, le premier dispositif client DEV 1 et le second dispositif client DEV2 sont un même dispositif client.
[0135] Lorsque l'individu INDIV souhaite accéder par exemple à un contenu, une application ou un service, etc. d'un fournisseur de services mettant en œuvre un contrôle d'accès en fonction d'au moins un attribut de l'individu, il peut utiliser un navigateur internet pour réaliser un tel accès (étape 610).
[0136] Le fournisseur de services doit alors vérifier que l'individu dispose d'un ou plusieurs attributs lui permettant l'accès. Pour ce faire, le fournisseur de services FRS-SERV peut communiquer, notamment de manière sécurisée au moyen d'un canal de communication sécurisé créé par exemple au moyen du protocole OpenID CIBA, avec le serveur d'autorisation d'accès SERV-AUTO afin de vérifier que l'individu dispose d'une autorisation d'accès au fournisseur de services (étape 620).
[0137] Un identifiant de demande de vérification SessionID est alors reçu par le serveur d'autorisation d'accès SERV-AUTO lors de l'étape 620. La réception de l'identifiant de demande de vérification peut être précédée d'une étape de génération de l'identifiant de demande de vérification par le fournisseur de services et le serveur d'autorisation d'accès.
[0138] Le serveur d'autorisation d'accès peut ensuite générer une information de connexion à partir de l'identifiant de demande de vérification reçu et transmettre l'information de connexion générée au fournisseur de services.
[0139] Selon le mode de réalisation illustré à la [Fig.6], le fournisseur de services transmet au dispositif client, par exemple au premier dispositif client DEV1, l'information de connexion qu'il a reçue (étape 630).
[0140] L'information de connexion peut être par exemple un QR Code qui va s'afficher sur l'écran d'affichage du premier dispositif client DEV1.
[0141] Selon un exemple de réalisation, l'individu scanne le QR Code s'affichant sur le premier dispositif client DEV1 au moyen du second dispositif client DEV2 (étape 640). Un canal de communication entre le serveur d'autorisation d'accès et le dispositif client, notamment le second dispositif client DEV2, est alors créé au moyen de l'information de connexion.
[0142] Le second dispositif client DEV2 génère ensuite une information de preuve d'autorisation d'accès, l'information de preuve d'autorisation d'accès étant générée au moyen de la donnée d'autorisation d'accès de l'individu mémorisée par exemple dans le second dispositif client DEV2.
[0143] Le serveur d'autorisation d'accès SERV-AUTO va alors recevoir l'information de preuve d'autorisation d'accès généré tel que précédemment décrit à l'étape 510 au support de la [Fig.5].
[0144] Le serveur d'autorisation d'accès reçoit l'information de preuve du second dispositif client de l'individu tel qu'illustré en [Fig.6] (étape 650) via le canal de communication créé.
[0145] Selon un autre mode de réalisation dans lequel aucun canal de communication entre le serveur d'autorisation d'accès SERV-AUTO et le dispositif client DEV n'est créé, le dispositif client, par exemple le premier dispositif client DEV 1, peut transmettre l'information de preuve d'autorisation d'accès au serveur d'autorisation d'accès via le fournisseur de services. Dans ce mode de réalisation, l'information de preuve d'autorisation d'accès est générée sur l'un des dispositifs client DEV1 ou DEV2 au moyen de la donnée d'autorisation d'accès de l'individu mémorisée par exemple sur le second dispositif client DEV2.
[0146] Selon un mode de réalisation particulier, le serveur d'autorisation d'accès peut envoyer l'information de preuve d'autorisation d'accès reçue au serveur d'identification IDP ou à une base de données de preuves BD-PREUVES afin de mémoriser l'information de preuve d'autorisation d'accès reçue (étape 650.a). Outre l'information de preuve, le serveur d'autorisation d'accès peut également envoyer l'identifiant de demande de vérification SessionID et/ou la date et l'heure de la réception de l'information de preuve d'autorisation d'accès afin d'être mémorisées. Des donnés additionnelles utilisées par exemple pour la génération de l'information de preuve d'autorisation d'accès peuvent également être mémorisées dans la base de données de preuves.
[0147] Le serveur d'autorisation d'accès vérifie l'information de preuve d'autorisation d'accès reçue en utilisant la donnée cryptographique publique tel que précédemment décrit à l'étape 510.
[0148] Si l'information de preuve d'autorisation d'accès est vérifiée, alors le serveur d'autorisation d'accès envoie au fournisseur de services FRS-SERV une information de validation de l'information de preuve d'autorisation d'accès (étape 660) tel que précédemment décrit au regard de l'étape 530 de la [Fig.5]. Lors de la vérification de l'autorisation d'accès de l'individu, le serveur d'autorisation d'accès ne vérifie pas la conformité du ou des attributs de l'individu à une ou plusieurs règles données. En outre, le serveur d'autorisation d'accès n'utilise pas l'identifiant de l'individu.
[0149] Selon un mode de réalisation particulier, le serveur d'autorisation d'accès comprend en outre une donnée identifiant le groupe d'individus ayant au moins un attribut conforme à ladite au moins une règle donnée IdToken. Selon ce mode de réalisation l'étape d'envoi au fournisseur de services FRS-SERV d'une information de validation de l'information de preuve d'autorisation d'accès comprend en outre l'envoi de la donnée identifiant le groupe d'individus IdToken.
[0150] Suite à la réception de l'information de validation de l'information de preuve d'autorisation d'accès par le fournisseur de services, celui-ci permet l'accès au fournisseur de services (étape 670).
[0151] Selon un mode de réalisation particulier, le serveur d'autorisation d'accès peut recevoir la donnée cryptographique publique du fournisseur de services FRS-SERV ou du dispositif client DEV afin de réaliser la vérification de l'information de preuve d'autorisation d'accès.
[0152] La [Fig.7] illustre un deuxième exemple d'un système comprenant un serveur d'autorisation d'accès SERV-AUTO lequel met en œuvre un autre mode de réalisation du procédé de vérification d'une autorisation d'accès d'un individu ayant une donnée d'autorisation d'accès conformément à l'invention. La donnée d'autorisation d'accès gsk u de cet exemple a été générée selon le mode de réalisation du procédé de délivrance décrit au support de la [Fig.4].
[0153] On ne décrira en détail ci-après que les étapes qui diffèrent de celles du premier exemple de système décrit à la [Fig.6]. Pour le reste, il est renvoyé au premier exemple décrit au support de la [Fig.6].
[0154] Dans cet exemple de réalisation, le serveur d'autorisation d'accès comprend une donnée cryptographique publique Gpk. La donnée cryptographique publique est spécifique pour un groupe d'individus ayant au moins un attribut conforme à au moins une règle donnée. La donnée cryptographique publique est associée à une donnée cryptographique secrète skm. Ladite donnée cryptographique secrète a été utilisée pour générer la donnée d'autorisation d'accès tel que décrit dans le mode de réalisation illustré à la [Fig.4].
[0155] La donnée cryptographique publique Gpk comprend au moins une clé maitre publique pkm. La donnée cryptographique publique Gpk peut en outre comprendre une clé de divulgation publique pko.
[0156] Selon un mode de réalisation particulier, la donnée cryptographique publique est mémorisée dans le serveur d'autorisation d'accès. Selon un autre mode de réalisation, la donnée cryptographique publique est reçue par le serveur d'autorisation d'accès du fournisseur de services FRS-SERV. Selon encore un autre mode de réalisation, la donnée cryptographique publique est reçue par le serveur d'autorisation d'accès du dispositif client DEV.
[0157] Tel qu'illustré à la [Fig.7], l'information de preuve d'autorisation d'accès o est générée par le dispositif client au moyen d'un algorithme de signature ayant pour paramètre la donnée d'autorisation d'accès gsku et une donnée de vérification c à signer générée par le serveur d'autorisation d'accès et transmise au dispositif client. La donnée de vérification est par exemple un nombre aléatoire ou semi-aléatoire.
[0158] Dans le mode de réalisation illustré, l'information de preuve d'autorisation d'accès est générée sur l'un des dispositifs client DEV1 ou DEV2 au moyen de la donnée d'autorisation d'accès gsku l'individu mémorisée par exemple sur le second dispositif client DEV2.
[0159] L'information de preuve d'autorisation d'accès est ensuite vérifiée par le serveur d'autorisation d'accès au moyen d'un algorithme de vérification de signature ayant comme paramètres, l'information de preuve d'autorisation d'accès o, la donnée de vérification c et la donnée cryptographique publique Gpk (étape 750).
[0160] Selon un mode de réalisation particulier, le serveur d'autorisation d'accès peut envoyer l'information de preuve d'autorisation d'accès o reçue au serveur d'identification IDP ou à une base de données de preuves BD-PREUVES afin de mémoriser l'information de preuve d'autorisation d'accès o reçue (étape 75O.a). Outre l'information de preuve, le serveur d'autorisation d'accès peut également envoyer l'identifiant de demande de vérification SessionID, la date et l'heure de la réception de l'information de preuve d'autorisation d'accès o afin d'être mémorisées. Des donnés additionnelles utilisées par exemple pour la génération de l'information de preuve d'autorisation d'accès peuvent également être mémorisées dans la base de données de preuves, tel que la donnée de vérification c.
[0161] Il est illustré à la [Fig.8] un premier exemple de système dans lequel un serveur de contrôle CONTROL détermine l'identité de l'individu ayant demandé une vérification d'une autorisation d'accès.
[0162] Le serveur de contrôle CONTROL peut en effet mettre en œuvre un procédé de dé- termination de l'identifiant d'un individu à partir d'une information de preuve d'autorisation d'accès fournie au fournisseur de services et mémorisée dans une base de données de preuves BD-PREUVES. La base de données de preuves BD-PREUVES mémorise les différentes informations de preuve d'autorisation d'accès soumises par les individus au fournisseur de services pour montrer qu'ils sont légitimes à accéder au fournisseur de services. En outre pour chaque information de preuve o mémorisée, sont associées l'identifiant de demande de vérification SessionID et la donnée de vérification c. La date et l'heure de la réception de l'information de preuve d'autorisation d'accès par le serveur d'autorisation d'accès peuvent également être mémorisées pour chaque information de preuve mémorisée.
[0163] La base de données de preuves BD-PREUVES peut être mémorisée sur le serveur d'identification IDP.
[0164] Le système comprend en outre une base de données d'individus BD-INDIV mémorisant l'identifiant IDU des individus ayant demandé une donnée d'autorisation d'accès auprès du serveur d'autorisation d'accès. A chaque identifiant d'un individu est associée la clé publique pku de ce dernier.
[0165] Le procédé de détermination de l'identifiant d'un individu mis en œuvre dans le serveur de contrôle CONTROL a pour objectif de lever l'anonymat de l'individu ayant demandé une vérification d'une autorisation d'accès.
[0166] Le procédé de détermination de l'identifiant d'un individu débute par une étape de réception d'une demande de détermination de l'identifiant d'un individu (étape 810) et une étape de réception d'un identifiant de demande de vérification SessionID provenant du fournisseur de services FRS-SERV (étape 820). L'identifiant de demande de vérification SessionID identifie une session intervenue entre le fournisseur de services FRS-SERV et le serveur d'autorisation d'accès SERV-AUTO afin que ce dernier vérifie une information de preuve d'autorisation d'accès d'un individu.
[0167] A partir de l'identifiant de demande de vérification SessionID, le serveur de contrôle effectue une recherche dans la base de données de preuves BD-PREUVES afin d'identifier l'information de preuve d'autorisation d'accès o mémorisée et la donnée de vérification c associées (étape 830).
[0168] L'étape 830 est suivie d'une étape 840 de détermination de l'identifiant de l'individu à partir de l'information de preuve d'autorisation d'accès o et de la donnée de vérification c. Pour cela, le serveur de contrôle détermine tout d'abord la clé publique de l'individu pku. Ensuite, à partir de la clé publique déterminée pku, le serveur de contrôle effectue une recherche dans la base de données d'individus BD-INDIV de l'identifiant de l'individu IDU ayant la clé publique pku déterminée.
[0169] L'étape 840 est suivie de l'étape 850 d'envoi de l'identifiant de l'individu IDU déterminé. [0170] Il est illustre à la [Fig.9] un deuxième exemple de système dans lequel un serveur de contrôle détermine l'identité de l'individu ayant demandé une vérification d'une autorisation d'accès.
[0171] On ne décrira en détail ci-après que les étapes qui diffèrent de celles du premier exemple de système décrit à la [Fig.8]. Pour le reste, il est renvoyé au premier exemple décrit au support de la [Fig.8].
[0172] Selon ce mode de réalisation, le serveur de contrôle CONTROL comprend une clé de divulgation secrète sko et une clé de divulgation publique pko En outre, le serveur d'autorisation d'accès est tel que décrit à la [Fig.4] et à la [Fig.7] et comprend une donnée cryptographique publique Gpk. La donnée cryptographique publique Gpk est spécifique pour un groupe d'individus ayant au moins un attribut conforme à au moins une règle donnée. Ladite donnée cryptographique publique est associée à une donnée cryptographique secrète skm. La donnée cryptographique publique Gpk comprend une clé maitre publique pkm et une clé de divulgation publique pko, la clé de divulgation publique étant la clé publique du serveur de contrôle CONTROL.
[0173] La base de données d'individus BD-INDIV mémorise l'identifiant IDU des individus ayant demandé une donnée d'autorisation d'accès auprès du serveur d'autorisation d'accès selon le mode de réalisation décrit au support de la [Eig.4]. A chaque identifiant IDU d'individu est associée la clé publique pku de ce dernier.
[0174] En outre, la base de données de preuves BD-PREUVES comprend les différentes informations de preuves d'autorisation d'accès o soumises par les individus au fournisseur de services pour montrer qu'ils sont légitimes à accéder au fournisseur de services tel que décrit au support de la [Eig.7]. Dans la base de données de preuves BD-PREUVES, pour chaque information de preuve mémorisée o, sont associées l'identifiant de demande de vérification SessionID et la donnée de vérification c. La date et l'heure de la réception de l'information de preuve d'autorisation d'accès par le serveur d'autorisation d'accès peuvent également être mémorisées pour chaque information de preuve mémorisée.
[0175] Le procédé de détermination de l'identifiant d'un individu mis en œuvre dans le serveur de contrôle CONTROL a pour objectif de lever l'anonymat de l'individu ayant demandé une vérification d'une autorisation d'accès.
[0176] Le procédé de détermination de l'identifiant d'un individu débute par les étapes 810 et 820 précédemment décrites au support de la [Eig.8]. En outre, le procédé se poursuit à l'étape 925 par l'obtention par le serveur de contrôle de la donnée cryptographique publique Gpk, provenant du serveur d'autorisation d'accès SERV-AUTO. Le procédé se poursuit à l'étape 830 précédemment décrite au support de la [Eig.8].
[0177] Selon ce mode de réalisation, à l'issue des étapes 820, 925 et 830, le serveur de contrôle CONTROL a obtenu la donnée cryptographique publique Gpk, la donnée de vérification c, et l'information de preuve d'autorisation d'accès o. A partir de la clé de divulgation secrète sko et des données et informations obtenues, le serveur de contrôle CONTROL détermine la clé publique de l'individu pku qui a généré l'information de preuve d'autorisation d'accès o.
[0178] Le procédé se poursuit alors à l'étape 840 précédemment décrite au support de la [Fig.8] au cours de laquelle, à partir de la clé publique déterminée pku, le serveur de contrôle CONTROL va rechercher dans la base de données d'individus BD-INDIV l'identifiant de l'individu IDU ayant la clé publique pku déterminée.
[0179] L'étape 840 est suivie de l'étape 850 d'envoi de l'identifiant de l'individu IDU déterminé.

Claims

Revendications
[Revendication 1] Procédé de délivrance d'une donnée d'autorisation d'accès pour un individu ayant une clé publique (pku) et au moins un attribut donné (ATT), le procédé étant mis en œuvre dans un serveur d'autorisation d'accès (SERV-AUTO) apte à communiquer avec un serveur d'identification (IDP) et un dispositif client (DEV), le serveur d'autorisation d'accès (SERV-AUTO) ayant au moins une règle donnée et une donnée cryptographique secrète, la donnée cryptographique secrète étant spécifique pour un groupe d'individus ayant au moins un attribut conforme à ladite au moins une règle donnée, le procédé comprenant les étapes suivantes :
• obtention de la clé publique de l'individu (pku) (étape 220) ;
• obtention dudit au moins un attribut (ATT) de l'individu provenant du serveur d'identification (IDP) (étape 240) ;
• détermination d'une conformité dudit au moins un attribut (ATT) de l'individu obtenu à ladite au moins une règle donnée (étape 250) ;
• si ledit au moins un attribut (ATT) de l'individu est conforme à ladite au moins une règle donnée, génération d'une donnée d'autorisation d'accès pour l'individu à partir de la donnée cryptographique secrète et de la clé publique de l'individu (pku ) obtenue (étapes 260, 280) ;
• délivrance de la donnée d'autorisation d'accès générée au dispositif client (DEV) (étape 290).
[Revendication 2] Procédé selon la revendication précédente, caractérisé en ce que le serveur d'autorisation d'accès comprend en outre une donnée cryptographique publique associée à ladite donnée cryptographique secrète, et en ce que le procédé comprend en outre une étape de transmission de la donnée cryptographique publique au dispositif client (DEV).
[Revendication 3] Procédé selon l'une quelconque des revendications précédentes, caractérisé en ce que le procédé comprend en outre une étape de vérification de la possession d'une clé privée de l'individu (sku) par le dispositif client associée à la clé publique de l'individu (pku) obtenue, préalablement à la délivrance de la donnée d'autorisation d'accès.
[Revendication 4] Procédé selon l'une quelconque des revendications précédentes, caractérisé en ce que le procédé comprend en outre une étape d'obtention d'un identifiant de demande d'une donnée d'autorisation d'accès (étape 210) et une étape de transmission de l'identifiant de demande d'une donnée d'autorisation d'accès au serveur d'identification (IDP) (étape 230).
[Revendication 5] Procédé selon la revendication précédente, caractérisé en ce que l'identifiant de demande d'une donnée d'autorisation d'accès comprend un identifiant de l'individu (IDU).
[Revendication 6] Procédé selon l'une quelconque des revendications 1 à 4, caractérisé en ce que le procédé comprend en outre, une étape d'obtention d'un identifiant de l'individu (IDU) provenant du serveur d'identification (IDP) ou du dispositif client (DEV).
[Revendication 7] Procédé de vérification d'une autorisation d'accès d'un individu ayant une donnée d'autorisation d'accès, la donnée d'autorisation d'accès ayant été délivrée conformément au procédé selon l'une quelconque des revendications 1 à 6, le procédé étant mis en œuvre dans un serveur d'autorisation d'accès (SERV-AUTO) apte à communiquer avec un fournisseur de services (FRS-SERV), le fournisseur de services mettant en œuvre un contrôle d'accès en fonction d'au moins un attribut de l'individu, le serveur d'autorisation d'accès (SERV-AUTO) ayant une donnée cryptographique publique, la donnée cryptographique publique étant spécifique pour un groupe d'individus ayant au moins un attribut conforme à au moins une règle donnée, ladite donnée cryptographique publique étant associée à une donnée cryptographique secrète, ladite donnée cryptographique secrète ayant été utilisée pour générer la donnée d'autorisation d'accès, le procédé comprenant les étapes suivantes :
• réception d'une information de preuve d'autorisation d'accès, l'information de preuve d'autorisation d'accès ayant été générée au moyen de la donnée d'autorisation d'accès de l'individu (étape 510) ;
• vérification de l'information de preuve d'autorisation d'accès reçue en utilisant la donnée cryptographique publique (étape si l'information de preuve d'autorisation d'accès est vérifiée, envoi au fournisseur de services (FRS-SERV) d'une information de validation de l'information de preuve d'autorisation d'accès, sans vérification de la conformité d'au moins un attribut de l'individu à ladite au moins une règle donnée lors de la vérification de l'autorisation d'accès (étapes 530, 550).
[Revendication 8] Procédé selon la revendication précédente, caractérisé en ce que la donnée cryptographique publique est reçue du fournisseur de services (FRS-SERV) ou d'un dispositif client (DEV).
[Revendication 9] Procédé selon la revendication 7 ou 8, caractérisé en ce que l'information de preuve d'autorisation d'accès est reçue du fournisseur de services (FRS-SERV) ou d'un dispositif client (DEV).
[Revendication 10] Procédé selon la revendication 7 ou 8, caractérisé en ce que le serveur d'autorisation d'accès est en outre apte à communiquer avec un dispositif client (DEV), et en ce que le procédé comprend en outre, les étapes suivantes : réception d'un identifiant de demande de vérification (SessionID) provenant du fournisseur de services (FRS-SERV) ; génération d'une information de connexion à partir de l'identifiant de demande de vérification reçu ; transmission au fournisseur de services (FRS-SERV) de l'information de connexion générée ; création d'un canal de communication entre le serveur d'autorisation d'accès (SERV-AUTO) et le dispositif client (DEV) au moyen de l'information de connexion ; réception de l'information de preuve d'autorisation d'accès du dispositif client (DEV) via le canal de communication créé.
[Revendication 11] Procédé selon l'une quelconque des revendications 7 à 10, caractérisé en ce que le serveur d'autorisation d'accès est en outre apte à communiquer avec un dispositif client (DEV), et en ce que le procédé comprend en outre les étapes suivantes :
• génération d'une donnée de vérification (c) ; transmission de la donnée de vérification générée au dispositif client (DEV) ; l'information de preuve d'autorisation d'accès reçue étant en outre générée à partir de la donnée de vérification.
[Revendication 12] Procédé selon l'une quelconque des revendications 7 à 11, caractérisé en ce que le serveur d'autorisation d'accès (SERV-AUTO) est apte à communiquer avec une base de données de preuves (BD-PREUVES), et en ce que le procédé comprend en outre, une étape de transmission à ladite base de données de preuves (BD-PREUVES) de l'information de preuve d'autorisation d'accès reçue.
[Revendication 13] Procédé selon l'une quelconque des revendications 7 à 12, caractérisé en ce que le serveur d'autorisation d'accès comprend en outre une donnée identifiant le groupe d'individus ayant au moins un attribut conforme à ladite au moins une règle donnée (IdToken), et en ce que l'étape d'envoi au fournisseur de services (FRS-SERV) d'une information de validation de l'information de preuve d'autorisation d'accès comprend en outre l'envoi de la donnée identifiant le groupe d'individus (IdToken).
[Revendication 14] Dispositif configuré pour mettre en œuvre le procédé selon l'une quelconque des revendications 1 à 6 ou le procédé selon l'une quelconque des revendications 7 à 13.
EP24707069.1A 2023-02-28 2024-02-27 Procédé de delivrance d'une autorisation d'accès pour un individu et procédé de vérification Pending EP4674088A1 (fr)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
FR2301862A FR3146219A1 (fr) 2023-02-28 2023-02-28 Procédé de délivrance d'une autorisation d'accès pour un individu et procédé de vérification
PCT/EP2024/054930 WO2024180049A1 (fr) 2023-02-28 2024-02-27 Procede de delivrance d'une autorisation d'acces pour un individu et procede de verification

Publications (1)

Publication Number Publication Date
EP4674088A1 true EP4674088A1 (fr) 2026-01-07

Family

ID=86764643

Family Applications (1)

Application Number Title Priority Date Filing Date
EP24707069.1A Pending EP4674088A1 (fr) 2023-02-28 2024-02-27 Procédé de delivrance d'une autorisation d'accès pour un individu et procédé de vérification

Country Status (3)

Country Link
EP (1) EP4674088A1 (fr)
FR (1) FR3146219A1 (fr)
WO (1) WO2024180049A1 (fr)

Also Published As

Publication number Publication date
FR3146219A1 (fr) 2024-08-30
WO2024180049A1 (fr) 2024-09-06

Similar Documents

Publication Publication Date Title
AU2013272184B2 (en) Enhanced 2CHK authentication security with query transactions
CA2875503C (fr) Association 2chk declenchee par entreprise
EP3262860B1 (fr) Procédé de reconnaissance automatique entre un appareil mobile et un véhicule automobile aptes à fonctionner selon le protocole ble
US9165149B2 (en) Use of a mobile telecommunication device as an electronic health insurance card
EP1549011A1 (fr) Procédé et système de communication entre un terminal et au moins un équipment communicant
EP1612991B1 (fr) Procédé et système de vote électronique en réseau à haute sécurité
WO2013079848A1 (fr) Protocole d'authentification mutuelle d' entitees ayant prealablement initie une transaction en ligne
WO2013021107A1 (fr) Procede, serveur et systeme d'authentification d'une personne
FR2973909A1 (fr) Procede d'acces a une ressource protegee d'un dispositif personnel securise
JP2001216270A (ja) 認証局、認証システム及び認証方法
KR20180037168A (ko) Otp를 이용한 상호 인증 방법 및 시스템
WO2016102834A1 (fr) Procédé d'authentification d'un utilisateur et d'un module sécurisé, appareil électronique et système associes
EP2056565A1 (fr) Procédé d'authentification d'un utilisateur accédant à un serveur distant à partir d'un ordinateur
EP3570518B1 (fr) Systeme et procede d'authentification utilisant un jeton a usage unique de duree limitee
WO2024180049A1 (fr) Procede de delivrance d'une autorisation d'acces pour un individu et procede de verification
FR3118225A1 (fr) Procédé et dispositif de génération d'informations d'authentification pour une entité sécurisée et procédé et dispositif de contrôle d'identité associés
WO2012022856A1 (fr) Procédé d'authentification d' un utilisateur du réseau internet
FR3007929A1 (fr) Procede d'authentification d'un utilisateur d'un terminal mobile
FR3157960A3 (fr) Procédé d’authentification d’un individu pour la mise en œuvre d’une transaction sur un terminal marchand.
EP2630746A1 (fr) Procede et systeme d'authentification
EP2115657A2 (fr) Procede et systeme d'autorisation d'acces a un serveur
KR20160020314A (ko) 전자서명을 이용하여 대출서비스를 제공하기 위한 장치 및 그 방법
FR3074944A1 (fr) Procede de securisation d'une transaction electronique
HK1207714B (en) Enhanced 2chk authentication security with query transactions

Legal Events

Date Code Title Description
STAA Information on the status of an ep patent application or granted ep patent

Free format text: STATUS: UNKNOWN

STAA Information on the status of an ep patent application or granted ep patent

Free format text: STATUS: THE INTERNATIONAL PUBLICATION HAS BEEN MADE

PUAI Public reference made under article 153(3) epc to a published international application that has entered the european phase

Free format text: ORIGINAL CODE: 0009012

STAA Information on the status of an ep patent application or granted ep patent

Free format text: STATUS: REQUEST FOR EXAMINATION WAS MADE

17P Request for examination filed

Effective date: 20250926

AK Designated contracting states

Kind code of ref document: A1

Designated state(s): AL AT BE BG CH CY CZ DE DK EE ES FI FR GB GR HR HU IE IS IT LI LT LU LV MC ME MK MT NL NO PL PT RO RS SE SI SK SM TR

RAP3 Party data changed (applicant data changed or rights of an application transferred)

Owner name: IDAKTO SAS