EP4128700A1 - Procede et dispositif d'authentification d'un utilisateur aupres d'une application - Google Patents

Procede et dispositif d'authentification d'un utilisateur aupres d'une application

Info

Publication number
EP4128700A1
EP4128700A1 EP21720811.5A EP21720811A EP4128700A1 EP 4128700 A1 EP4128700 A1 EP 4128700A1 EP 21720811 A EP21720811 A EP 21720811A EP 4128700 A1 EP4128700 A1 EP 4128700A1
Authority
EP
European Patent Office
Prior art keywords
user
request
address
authentication
identifier
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
EP21720811.5A
Other languages
German (de)
English (en)
Inventor
Emmanuel Bertin
Julien HATIN
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.)
Orange SA
Original Assignee
Orange SA
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 Orange SA filed Critical Orange SA
Publication of EP4128700A1 publication Critical patent/EP4128700A1/fr
Pending legal-status Critical Current

Links

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W12/00—Security arrangements; Authentication; Protecting privacy or anonymity
    • H04W12/06—Authentication
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/50—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols using hash chains, e.g. blockchains or hash trees
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F21/00—Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G06F21/30—Authentication, i.e. establishing the identity or authorisation of security principals
    • G06F21/31—User authentication
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F21/00—Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G06F21/30—Authentication, i.e. establishing the identity or authorisation of security principals
    • G06F21/31—User authentication
    • G06F21/41—User authentication where a single sign-on provides access to a plurality of computers
    • 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/0815—Network architectures or network communication protocols for network security for authentication of entities providing single-sign-on or federations
    • 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/0861—Network architectures or network communication protocols for network security for authentication of entities using biometrical features, e.g. fingerprint, retina-scan
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/32—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials
    • H04L9/3226—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials using a predetermined code, e.g. password, passphrase or PIN
    • H04L9/3231—Biological data, e.g. fingerprint, voice or retina
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/32—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials
    • H04L9/3236—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials using cryptographic hash functions
    • H04L9/3239—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials using cryptographic hash functions involving non-keyed hash functions, e.g. modification detection codes [MDCs], MD5, SHA or RIPEMD

Definitions

  • the invention relates to the general field of telecommunications networks, and more specifically to blockchain technology.
  • SSO Single Sign-On
  • IdP Identity Providers
  • OIDC OpenID Connect
  • the invention improves the state of the art and proposes a method for authenticating a user to at least one application, called a service application, said user being equipped with a user device having at least one address and being able to obtain at least one piece of authentication data from said user, the method being implemented by a device for authenticating a user and characterized in that it comprises:
  • - a step of receiving, from said at least one service application, a request comprising at least one identifier of said user; a first step of sending, to an application registered in a blockchain, a request comprising said at least one identifier of said user;
  • the service provider who wishes to authenticate a user will request the authentication device by sharing with it an identifier entered for example by the user at the level of the man-machine interface of the service.
  • the authentication device will then retrieve, from an application registered in a blockchain, an address of a device belonging to the user.
  • This user device is for example a USB security key, a mobile, a PC, a virtual machine located in the network, or any other terminal capable of obtaining and supplying data for example encrypted from a user allowing his authentication such as for example authentication tokens.
  • the method will contact the user device via a redirection request redirecting to the address of the service which wishes to authenticate the user.
  • the user's device completes the request with authentication data such as an authentication token.
  • the token can for example be generated by the user device as a function of data entered by the user such as biometric data.
  • service application is understood to mean any application capable of rendering at least one service for the needs of a user and executed for example on a server located in a network such as the Internet network.
  • the application can also be executed at the level of a terminal such as for example a connected object, a smartphone, a personal computer, or any other terminal capable of executing a computer application.
  • this method makes it possible to guarantee the identity of the user through the use of the blockchain.
  • blockchain technology is a technology for storing and transmitting information without a control organ.
  • it is a distributed database whose information sent by users and internal links to the base are verified and grouped at regular time intervals into blocks, the whole being secured by cryptography, and thus forming chain.
  • a blockchain is a distributed database that maintains a list of records protected against tampering or modification by storage nodes; it is therefore a distributed and secure register of all transactions carried out since the start of the distributed system ”.
  • Blockchains are further characterized in that their contents cannot be changed or deleted: information published in a blockchain remains so forever. By information "published” in a blockchain, we mean information recorded or saved in it.
  • a method as described above is characterized in that the first emission step is followed:
  • This embodiment of the invention makes it possible to provide, at the end of G authentication, at least one piece of data to the service provider such as for example one or more attributes of the user, an error code, etc. necessary for the proper functioning of the service.
  • the embodiment allows the user to remain in control of the attributes that he shares with the service providers. He can know the data requested by the service provider and knowingly agree to share it or not.
  • attribute is meant a user's personal data such as a name, first name, telephone number, biometric fingerprint, postal address, e-mail address, age, profession, etc.
  • the attribute can also be a multimedia object such as a photo, video, text document, etc.
  • a method as described above is characterized in that the fourth emission step is preceded:
  • the device will for example obtain, from a trusted entity, a hash (digital fingerprint used to quickly identify initial data produced via a function which takes the data as input) of the user's attribute and compare it with the hash of the attribute of the user generated by the authentication device itself. If the two hashes match, then the attributes received are considered valid. They are then inserted into the data sent by the authentication process to the services application.
  • a trusted entity is a device such as a server, a personal computer, a mobile terminal, a connected object capable of obtaining for example from a user and providing certified data such as attributes of a user.
  • a method as described above is characterized in that the trusted entity is an application registered in a chain of blocks.
  • This embodiment ensures that the evidence has not been corrupted, as the data written in a blockchain cannot be modified or deleted.
  • a method as described above is characterized in that said first address corresponds to said second address of said user device.
  • This embodiment makes it possible to use the same user terminal to retrieve the authentication data (s) and the attribute (s).
  • a method as described above is characterized in that said at least one attribute is encrypted data and in that the generation step is preceded by a step decryption of said at least one attribute.
  • This embodiment allows the user not to transmit unencrypted his attributes or personal data.
  • the invention also relates to a device for authenticating a user to at least one application, called a service application, said user being equipped with a user device capable of obtaining at least one piece of authentication data from said user, and characterized in that it comprises:
  • a second module for receiving a response message, originating from said application registered to a chain of blocks, comprising at least a first piece of data corresponding to a first address of said user device, said at least one first datum having been obtained as a function of said at least one identifier of said user;
  • module can correspond both to a software component and to a hardware component or a set of hardware and software components, a software component itself corresponding to one or more computer programs or subroutines or more generally. to any element of a program capable of implementing a function or a set of functions as described for the modules concerned.
  • a hardware component corresponds to any element of a hardware assembly capable of implementing a function or a set of functions for the module concerned (integrated circuit, smart card, memory card, etc. .).
  • the invention also relates to a server characterized in that it comprises a device for authenticating a user as described above.
  • the invention also relates to a computer program comprising instructions for implementing the above method according to any one of the particular embodiments described above, when said program is executed by a processor.
  • the method can be implemented in various ways, in particular in wired form or in software form.
  • This program can use any programming language, and be in the form of source code, object code, or intermediate code between source code and object code, such as in a partially compiled form, or in any other. desirable form.
  • the invention also relates to a recording medium or information medium readable by a computer, and comprising instructions of a computer program as mentioned above.
  • the aforementioned recording media can be any entity or device capable of storing the program.
  • the medium may comprise a storage means, such as a ROM, for example a CD ROM or a microelectronic circuit ROM, or else a magnetic recording means, for example a Hard disk.
  • the recording media can correspond to a transmissible medium such as an electrical or optical signal, which can be conveyed via an electrical or optical cable, by radio or by other means.
  • the programs according to the invention can in particular be downloaded from an Internet type network.
  • the recording media can correspond to an integrated circuit in which the program is incorporated, the circuit being adapted to execute or to be used in the execution of the method in question.
  • This device for authenticating a user and this computer program have characteristics and advantages similar to those described above in connection with the method for authenticating a user.
  • Figure 1 shows the hardware architecture of an authentication device according to a particular embodiment of the invention
  • FIG 2 shows in flowchart form the main steps of an authentication method according to a particular embodiment of the invention.
  • FIG. 1 represents the hardware architecture of an authentication device DA in accordance with the invention.
  • this device has the hardware architecture of a computer. It notably comprises a processor PROC1, a random access memory MV1, a read only memory MEM1 and a non-volatile flash memory MF1.
  • the read only memory constitutes a recording medium in accordance with the invention, readable by the processor PROC1 and on which is recorded here a computer program PG1 in accordance with the invention, this program comprising instructions for implementing the steps of the method of controlling access to a function as described above, when the program is executed by the processor PROC1.
  • the code instructions of the computer program PG1 are for example loaded into a memory before being executed by the PROC1 processor.
  • the processor PROC1 of the processing unit UT1 notably implements the steps of the method of controlling access to a function according to any one of the particular embodiments described in relation to FIG. 2, according to the instructions of the program d computer PG1.
  • the device DA also comprises reception modules RECV1 and RECV2 capable of receiving communications via for example an IP network and / or circuit.
  • the RECV 1 reception module is for example used to receive requests from a service application comprising at least one identifier of a user.
  • the RECV2 reception module is for example used to receive a message comprising at least one piece of data corresponding to an address of a device of a user.
  • the RECV1 and RECV2 modules can be one and the same reception module.
  • the DA device further comprises SND1 and SND2 transmission modules capable of transmitting communications via for example an IP network and / or circuit.
  • the SND1 transmission module is for example used to send, to an application registered in a blockchain, a request comprising at least one identifier of a user.
  • the SND2 module is for example used to send, to an address of a user device, a request allowing the sending of a message, to an address of a service application comprising at least one authentication datum. of a user.
  • the SND1 and SND2 modules can be one and the same reception module.
  • the modules RECV1, RECV2, SND1 and SND2 can be one and the same communication module COM1 (not shown).
  • the communication module COM1 can also be used to receive, from a service application, a request for attributes from a user and comprising at least one authentication datum. and an identifier of the user.
  • the communication module COM1 can also be used to send to an address of a device of the user a request for attributes of the user, the address of the user. device having been obtained according to a user identifier, for example via an application registered in a blockchain or from digital storage such as a database, file or memory.
  • the communication module COM1 can also be used to receive a response to the request for attributes, the response comprising at least one attribute of the user or a status message such as an error code.
  • the communication module COM1 can also be used to send to a service application, a response to the request for attributes coming from the service application, comprising at least data such as an error code, a status, a transaction identifier, an attribute, etc.
  • the device DA comprises an obtaining module (OBT) capable of obtaining from a trusted entity at least one piece of data, called proof, obtained by applying a function F1 to one or several attributes of the user.
  • the function Fl is for example a function making it possible to create a hash and / or a function allowing encryption and / or a function making it possible to sign the attribute (s) of the user. It can be executed, for example, by the trusted entity or else by a user device or any other device capable of providing the evidence (s) to the trusted entity.
  • the device DA comprises a generation module (GEN) capable of generating the proof (s), by applying the function F1 to one or more attributes of the user received via the module COM1 .
  • the evidence (s) generated can then be compared by the comparison module (COMP) to the evidence obtained through the OBT obtaining module. If the result of the comparison is positive then the attributes are considered valid. Otherwise the attributes are considered invalid.
  • the DA device comprises a module (not shown) allowing the decryption of the evidence obtained.
  • This embodiment makes it possible for example to decipher the proofs obtained before being able to compare them with the proofs generated by the DA device.
  • the modules COM1 and OBT can be one and the same communication module.
  • FIG. 2 we will now describe the main steps E20, E21, E22, E23, E25, E26, E27, E28 and E29 of an authentication method according to embodiments of the invention.
  • FIG. 2 consists of a terminal T such as for example a mobile terminal, a USB key (Universal Serial Bus), a connected object or a computer capable of obtaining and providing data, for example encrypted, of a user allowing his authentication as for example authentication tokens or personal data.
  • FIG. 2 also includes a BC device registered to a blockchain for example capable of performing decentralized functions or DApps within the meaning of blockchain technology but also an SA device such as a server, a personal computer, an object connected or any other terminal capable of providing a service to a user. It also consists of a DA device capable of performing the authentication method within the meaning of the invention.
  • a terminal T such as for example a mobile terminal, a USB key (Universal Serial Bus), a connected object or a computer capable of obtaining and providing data, for example encrypted, of a user allowing his authentication as for example authentication tokens or personal data.
  • FIG. 2 also includes a BC device registered to a blockchain for example capable of performing decentralized functions or DApps within the meaning of blockchain
  • the device SA sends an authentication request to the device DA.
  • This request follows a request from a user's terminal to access a service provided by the DA device.
  • the authentication device DA receives the authentication request which may include several parameters such as an identifier of the user wishing to access the service provided by the device SA, a transaction number, a service identifier , an identifier of the SA device, an address of the SA device, a time slot, or any other information related to the service or to the user.
  • step E21 the authentication method will send to the device BC a request comprising at least one identifier of the user retrieved during step E20.
  • the request is then received by the device BC in step E31.
  • step E32 the BC device will send back to the DA device a response containing an address, such as for example a MAC address or an IP address, of a terminal T belonging to the user.
  • the address of the terminal T corresponds to a first datum within the meaning of the invention. This address is selected by the BC device as a function of the user identifier received in step E31.
  • the BC device can send a response comprising a list of addresses of the user's devices, this list being able for example to be ordered, the first address being for example the one to be used by default.
  • the addresses can also be associated with data indicating the nature of the data that can be obtained via each user device (authentication data, user attributes, etc.).
  • the response from the BC device is then received by the DA device in step E22.
  • the latter will send (E23) to the address of the terminal T a redirection request, that is to say a request asking the terminal T d 'in turn send a message to the SA device.
  • the request sent by the device DA in step E23 and received by the terminal T in step E43 can include parameters such as the identifier of the service provided by the device SA and / or the address of the device SA and / or any other information such as a parameter supplied by the device SA and received by the device DA during step E20.
  • the message sent by the terminal T in step E44 and received by the device SA in step E14 comprises at least one piece of user authentication data such as, for example, personal data or an authentication token.
  • the authentication data can be generated at the terminal T via, for example, data collected by a biometric sensor used to obtain a fingerprint, an iris, a face, a voice, etc. of the user.
  • the authentication datum may vary as a function of one or more parameters, for example received by the terminal T in step E43 and / or obtained by the terminal T, for example the current time obtained via a clock internal to the device T.
  • one of the parameters is a parameter of the request received during step E43
  • this one can be a parameter previously received by the device DA during of step E20 such as a time slot, an identifier of the service or of the device SA.
  • the device SA sends during step E15 a request for attributes from the user to the device DA.
  • the request comprises at least one authentication datum received by the device SA during step E14 and an identifier of the user which is for example the same as that transmitted in the request sent by the device SA during step E10. It can also include other parameters such as a service identifier executed by the device SA, a transaction number, an identifier of the device SA, or any other information related to the service.
  • the device DA receives the request at step E25 and goes to step E26 to send a request for attributes to a device of the user.
  • This attribute query can include parameters received from the device SA during step E25.
  • the request is received in step E46 by the user device which is, in the case described in support of FIG. 2, the terminal T.
  • the user device which receives the attribute request (E46) may be different from the user device which receives the redirection request (E43).
  • step E47 the terminal T transmits to the device DA one or more attributes of the user.
  • the attributes are for example a function of a service identifier, a transaction number, an identifier of the SA device, or any other information related to the service and received during step E46.
  • the DA device receives the attribute (s) from the user in step E27 and then transmits it (s) to the SA device in step E29. The attribute or attributes are then received by the device SA in step El 9.
  • the device DA can, after having retrieved the attributes of the user (E27), decrypt, for example via a key shared with the terminal T, the attributes before transmitting them to the device SA ( E29).
  • the device DA can, after having retrieved the attributes of the user (E27), verify the signature of the attributes via for example a key shared with the terminal T before transmitting them to the device. SA (E29).
  • the device DA can obtain from a trusted entity (not shown) one or more hashes of an attribute, of several attributes or of a concatenation of attributes of the user.
  • the DA device will then calculate the hash of an attribute, of several attributes or of a concatenation of attributes retrieved from the user during step E27 by applying the same function as that which made it possible to generate the one or more. hash obtained from the trusted entity.
  • the device will then, during step E28, compare the calculated hash (s) with those obtained from the trusted entity. If the result of the comparison is positive then the attributes are considered valid. Otherwise, the attributes are considered to be invalid and an error message such as for example a code is returned to the device SA during step E29.

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Security & Cryptography (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Computer Hardware Design (AREA)
  • Theoretical Computer Science (AREA)
  • General Engineering & Computer Science (AREA)
  • Computing Systems (AREA)
  • General Health & Medical Sciences (AREA)
  • Biomedical Technology (AREA)
  • Software Systems (AREA)
  • Physics & Mathematics (AREA)
  • General Physics & Mathematics (AREA)
  • Health & Medical Sciences (AREA)
  • Life Sciences & Earth Sciences (AREA)
  • Biodiversity & Conservation Biology (AREA)
  • Storage Device Security (AREA)

Abstract

L'invention concerne un procédé d'authentification d'un utilisateur auprès d'au moins une application, dite application de services, ledit utilisateur étant équipé d'un dispositif utilisateur possédant au moins une adresse et étant apte à obtenir au moins une donnée d'authentification dudit utilisateur, le procédé étant mis en œuvre par un dispositif d'authentification d'un utilisateur et caractérisé en ce qu'il comprend : - une étape de réception, en provenance de ladite au moins une application de services, d'une requête comprenant au moins un identifiant dudit utilisateur; - une première étape d'émission, à destination d'une application inscrite à une chaîne de blocs, d'une requête comprenant ledit au moins un identifiant dudit utilisateur; - une deuxième étape de réception, en réponse à l'étape d'émission, d'un message comprenant au moins une première donnée correspondant à une première adresse dudit dispositif utilisateur, ladite au moins une première donnée ayant été obtenue en fonction dudit au moins un identifiant dudit utilisateur; - une deuxième étape d'émission, à destination de ladite première adresse, d'une requête pour émettre un message comprenant ladite au moins une donnée d'authentification dudit utilisateur vers une adresse de ladite application de services.

Description

DESCRIPTION
Titre : Procédé et dispositif d’authentification d’un utilisateur auprès d’une application.
1. Domaine de l'invention
L’invention se rapporte au domaine général des réseaux de télécommunications, et plus précisément à la technologie des chaînes de blocs (en anglais « blockchain »).
2. Art Antérieur
Nous vivons dans un monde toujours plus connecté, conséquence d’une digitalisation de plus en plus poussée de nos processus traditionnels tels que les courriers, les démarches administratives, les services bancaires, le paiement, etc. Pour accéder aux services digitalisés et à leurs contenus/fonctionnalités, il est souvent demandé à un utilisateur de s’identifier grâce à une identité numérique. Cette identité numérique est le plus souvent différente d’un service à un autre ce qui implique une multitude d’ identifiants à mémoriser pour Tutilisateur.
Il existe aujourd’hui des solutions pour résoudre ce problème comme par exemple les solutions de type SSO (Single Sign-On) qui propose à Tutilisateur de se connecter à de multiples applications via un seul identifiant. Concrètement, ces solutions reposent sur la délégation de l’authentification à des fournisseurs d’identités ou IdP pour « Identity Providers » qui créent, gèrent et maintiennent l’identité d’un utilisateur pour le compte de fournisseurs de services. Les fournisseurs d’identités sont par exemple de type SAML (Security Assertion Markup Language) ou OIDC (OpenID Connect).
La délégation de l’authentification à des fournisseurs d’identités peut poser un problème concernant la protection des données à caractère personnel. En effet, ces solutions imposent à Tutilisateur de partager au préalable avec le ou les fournisseurs d’identités de nombreuses données personnelles. Un acteur malveillant qui proposerait un tel service pourrait récupérer des données sensibles des utilisateurs et les revendre sans que les utilisateurs en aient conscience. De plus, Tutilisateur n’a pas le contrôle sur le nombre et la nature des informations communiquées aux services digitaux par le fournisseur d’identités lors des demandes d’authentification. 3. Exposé de l'invention
L’invention vient améliorer l’état de la technique et propose un procédé d’authentification d’un utilisateur auprès d’au moins une application, dite application de services, ledit utilisateur étant équipé d’un dispositif utilisateur possédant au moins une adresse et étant apte à obtenir au moins une donnée d’authentification dudit utilisateur, le procédé étant mis en œuvre par un dispositif d’authentification d’un utilisateur et caractérisé en ce qu’il comprend :
- une étape de réception, en provenance de ladite au moins une application de services, d’une requête comprenant au moins un identifiant dudit utilisateur ; une première étape d’émission, à destination d’une application inscrite à une chaîne de blocs, d’une requête comprenant ledit au moins un identifiant dudit utilisateur ;
- une deuxième étape de réception, en réponse à l’étape d’émission, d’un message comprenant au moins une première donnée correspondant à une première adresse dudit dispositif utilisateur, ladite au moins une première donnée ayant été obtenue en fonction dudit au moins un identifiant dudit utilisateur ;
- une deuxième étape d’émission, à destination de ladite première adresse, d’une requête pour émettre un message comprenant ladite au moins une donnée d’authentification dudit utilisateur vers une adresse de ladite application de services.
Ainsi, le fournisseur de services qui souhaite authentifier un utilisateur va solliciter le dispositif d’authentification en lui partageant un identifiant renseigné par exemple par l’utilisateur au niveau de l’interface homme-machine du service. Le dispositif d’authentification va alors récupérer, depuis une application inscrite à une chaîne de blocs, une adresse d’un dispositif appartenant à l’utilisateur. Ce dispositif utilisateur est par exemple une clef de sécurité USB, un mobile, un PC, une machine virtuelle située dans le réseau, ou tout autre terminal apte à obtenir et fournir des données par exemple chiffrées d’un utilisateur permettant son authentification comme par exemple des jetons d’authentification. Une fois l’adresse du dispositif utilisateur récupérée, le procédé va contacter le dispositif utilisateur via une requête de redirection redirigeant vers l’adresse du service qui souhaite procéder à l’authentification de l’utilisateur. Lors de la redirection, le dispositif de l’utilisateur complète la requête avec une donnée d’authentification telle qu’un jeton d’authentification. Le jeton peut par exemple être généré par le dispositif utilisateur en fonction de données renseignées par l’utilisateur telles que des données biométriques. On entend par application de services, toute application apte à rendre au moins un service pour les besoins d’un utilisateur et exécutée par exemple sur un serveur situé dans un réseau tel que le réseau Internet. L’application peut également être exécutée au niveau d’un terminal comme par exemple un objet connecté, un smartphone (téléphone intelligent en anglais), un ordinateur personnel, ou tout autre terminal apte à exécuter une application informatique.
Avantageusement, ce procédé permet de garantir l’identité de l’utilisateur grâce à l’utilisation de la chaîne de blocs. Comme indiqué dans le document (https://ff.wikipedia.org/wiki/Blockchain), on rappelle que « la technologie des chaînes de blocs est une technologie de stockage et de transmission d'informations sans organe de contrôle. Techniquement, il s'agit d'une base de données distribuée dont les informations envoyées par les utilisateurs et les liens internes à la base sont vérifiés et groupés à intervalles de temps réguliers en blocs, l'ensemble étant sécurisé par cryptographie, et formant ainsi une chaîne. Par extension, une chaîne de blocs est une base de données distribuée qui gère une liste d'enregistrements protégés contre la falsification ou la modification par les nœuds de stockage ; c'est donc un registre distribué et sécurisé de toutes les transactions effectuées depuis le démarrage du système réparti». Les chaînes de blocs sont caractérisées en outre en ce que leurs contenus ne peuvent pas être modifiés ou supprimés : une information publiée dans une chaîne de blocs le reste pour toujours. Nous désignons par information « publiée » dans une chaîne de blocs, une information enregistrée ou sauvegardée dans celle-ci.
Selon un mode de mise en œuvre particulier de l'invention, un procédé tel que décrit ci- dessus est caractérisé en ce que la première étape d’émission est suivie :
- d’une troisième étape de réception, en provenance de ladite application de services, d’une requête d’attributs dudit utilisateur, ladite requête comprenant ladite au moins une donnée d’authentification et ledit au moins un identifiant dudit utilisateur ;
- d’une troisième étape d’émission, à destination d’une deuxième adresse d’un dispositif dudit utilisateur obtenue en fonction dudit au moins un identifiant dudit utilisateur, d’une requête d’attributs dudit utilisateur ;
- d’une quatrième étape de réception d’une réponse à la requête d’attributs, la réponse comportant au moins un attribut dudit utilisateur ; - d’une quatrième étape d’émission, à destination de ladite application de services, d’une réponse à la requête d’attributs, la réponse comportant au moins une deuxième donnée.
Ce mode de mise en œuvre de l'invention permet de fournir, à l’issue de G authentification, au moins une donnée au fournisseur du service comme par exemple un ou des attributs de l’utilisateur, un code d’erreur, etc. nécessaires au bon fonctionnement du service. Avantageusement, le mode de réalisation permet à l’utilisateur de rester maître des attributs qu’il partage avec les fournisseurs de services. Il peut connaître les données demandées par le fournisseur de service et accepter en connaissance de cause de les partager ou non.
On entend par attribut une donnée personnelle de l’utilisateur telle qu’un nom, prénom, numéro de téléphone, empreinte biométrique, adresse postale, adresse e-mail, âge, profession, etc. l’attribut peut être également un objet multimédia tel qu’une photo, une vidéo, un document de texte, etc.
Selon un mode de mise en œuvre particulier de l'invention, un procédé tel que décrit ci- dessus est caractérisé en ce que la quatrième étape d’émission est précédée :
- d’une étape d’obtention, depuis une entité de confiance, d’au moins une troisième donnée obtenue par application d’une fonction audit au moins un attribut dudit utilisateur;
- d’une étape de génération d’au moins une quatrième donnée obtenue par application de ladite fonction audit au moins un attribut dudit utilisateur reçu lors de la quatrième étape de réception ;
- d’une étape d’ajout dudit au moins un attribut dudit utilisateur au contenu de ladite au moins une deuxième donnée en fonction du résultat de la comparaison de ladite au moins une troisième donnée avec ladite au moins une quatrième donnée.
Ce mode de réalisation permet d’assurer que les attributs de l’utilisateur sont valides. Le dispositif va par exemple obtenir, depuis une entité de confiance, un hash (empreinte numérique servant à identifier rapidement une donnée initiale réalisée via une fonction qui prend en entrée la donnée) de l’attribut de l’utilisateur et le comparer avec le hash de l’attribut de l’utilisateur généré par le dispositif d’authentification lui-même. Si les deux hash correspondent, alors les attributs reçus sont considérés comme valides. Ils sont alors insérés dans les données envoyées par le procédé d’authentification à l’application de services. On appelle entité de confiance un dispositif tel qu’un serveur, un ordinateur personnel, un terminal mobile, un objet connecté apte à obtenir par exemple d’un utilisateur et à fournir des données certifiées telles que des attributs d’un utilisateur.
Selon un mode de mise en œuvre particulier de l'invention, un procédé tel que décrit ci- dessus est caractérisé en ce que l’entité de confiance est une application inscrite à une chaîne de blocs.
Ce mode de réalisation permet de s’assurer que les preuves n’ont pas été corrompues, les données inscrites dans une chaîne de blocs ne pouvant être modifiées ou supprimées.
Selon un mode de mise en œuvre particulier de l'invention, un procédé tel que décrit ci- dessus est caractérisé en ce que ladite première adresse correspond à ladite deuxième adresse dudit dispositif utilisateur.
Ce mode de réalisation permet d’utiliser le même terminal utilisateur pour récupérer la ou les données d’authentification et le ou les attributs.
Selon un mode de mise en œuvre particulier de l'invention, un procédé tel que décrit ci- dessus est caractérisé en ce que ledit au moins un attribut est une donnée chiffrée et en ce que l’étape de génération est précédée d’une étape de déchiffrement dudit au moins un attribut.
Ce mode de réalisation permet à l’utilisateur de ne pas transmettre en clair ses attributs ou données personnelles.
L’invention concerne également un dispositif d’authentification d’un utilisateur auprès d’au moins une application, dite application de services, ledit utilisateur étant équipé d’un dispositif utilisateur apte à obtenir au moins une donnée d’authentification dudit utilisateur, et caractérisé en ce qu’il comprend :
- un module de réception d’une requête en provenance de ladite au moins une application de services comprenant au moins un identifiant dudit utilisateur ; un module d’émission à destination d’une application inscrite à une chaîne de blocs d’une requête comprenant ledit au moins un identifiant dudit utilisateur ;
- un deuxième module de réception d’un message de réponse, en provenance de ladite application inscrite à une chaîne de blocs, comprenant au moins une première donnée correspondant à une première adresse dudit dispositif utilisateur, ladite au moins une première donnée ayant été obtenue en fonction dudit au moins un identifiant dudit utilisateur ;
- un deuxième module d’émission, à destination de ladite première adresse, d’une requête pour émettre un message, vers une adresse de ladite application de services, comprenant ladite au moins une donnée d’authentification dudit utilisateur.
Le terme module peut correspondre aussi bien à un composant logiciel qu’à un composant matériel ou un ensemble de composants matériels et logiciels, un composant logiciel correspondant lui-même à un ou plusieurs programmes ou sous-programmes d’ordinateur ou de manière plus générale à tout élément d’un programme apte à mettre en œuvre une fonction ou un ensemble de fonctions telles que décrites pour les modules concernés. De la même manière, un composant matériel correspond à tout élément d’un ensemble matériel (ou hardware) apte à mettre en œuvre une fonction ou un ensemble de fonctions pour le module concerné (circuit intégré, carte à puce, carte à mémoire, etc.).
L'invention concerne également un serveur caractérisé en ce qu’il comporte un dispositif d’authentification d’un utilisateur tel que décrit précédemment.
L'invention concerne également un programme d'ordinateur comportant des instructions pour la mise en œuvre du procédé ci-dessus selon l’un quelconque des modes particuliers de réalisation décrits précédemment, lorsque ledit programme est exécuté par un processeur. Le procédé peut être mis en œuvre de diverses manières, notamment sous forme câblée ou sous forme logicielle. Ce programme peut utiliser n'importe quel langage de programmation, et être sous la forme de code source, code objet, ou de code intermédiaire entre code source et code objet, tel que dans une forme partiellement compilée, ou dans n’importe quelle autre forme souhaitable.
L’invention vise aussi un support d’enregistrement ou support d’informations lisible par un ordinateur, et comportant des instructions d'un programme d'ordinateur tel que mentionné ci- dessus. Les supports d’enregistrement mentionnés ci-avant peuvent être n’importe quelle entité ou dispositif capable de stocker le programme. Par exemple, le support peut comporter un moyen de stockage, tel qu’une ROM, par exemple un CD ROM ou une ROM de circuit microélectronique, ou encore un moyen d'enregistrement magnétique, par exemple un disque dur. D'autre part, les supports d'enregistrement peuvent correspondre à un support transmissible tel qu'un signal électrique ou optique, qui peut être acheminé via un câble électrique ou optique, par radio ou par d'autres moyens. Les programmes selon l'invention peuvent être en particulier téléchargés sur un réseau de type Internet.
Alternativement, les supports d'enregistrement peuvent correspondre à un circuit intégré dans lequel le programme est incorporé, le circuit étant adapté pour exécuter ou pour être utilisé dans l'exécution du procédé en question.
Ce dispositif d’authentification d’un utilisateur et ce programme d'ordinateur présentent des caractéristiques et avantages analogues à ceux décrits précédemment en relation avec le procédé d’authentification d’un utilisateur.
4. Liste des figures
D’autres caractéristiques et avantages de l’invention apparaîtront plus clairement à la lecture de la description suivante de modes de réalisation particuliers, donnés à titre de simples exemples illustratifs et non limitatifs, et des dessins annexés, parmi lesquels :
[Fig 1] La figure 1 représente l’architecture matérielle d’un dispositif d’authentification selon un mode particulier de réalisation de l’invention ;
[Fig 2] La figure 2 représente sous forme d’organigramme les principales étapes d’un procédé d’authentification selon un mode particulier de réalisation de l’invention.
5. Description d’un mode de réalisation de l’invention
La figure 1 représente l’architecture matérielle d’un dispositif d’authentification DA conforme à l’invention. Dans le mode de réalisation décrit ici, ce dispositif a l’architecture matérielle d’un ordinateur. Il comprend notamment un processeur PROC1, une mémoire vive MV1, une mémoire morte MEM1 et une mémoire flash non volatile MF1. De tels moyens sont connus en soi et ne sont pas décrits plus en détail ici. La mémoire morte constitue un support d’enregistrement conforme à l’invention, lisible par le processeur PROC1 et sur lequel est enregistré ici un programme d’ordinateur PG1 conforme à l’invention, ce programme comportant des instructions pour mettre en œuvre les étapes du procédé de contrôle d’accès à une fonction tel que décrit précédemment, lorsque le programme est exécuté par le processeur PROC1. A l'initialisation, les instructions de code du programme d’ordinateur PG1 sont par exemple chargées dans une mémoire avant d’être exécutées par le processeur PROC1. Le processeur PROC1 de l'unité de traitement UT1 met notamment en œuvre les étapes du procédé de contrôle d’accès à une fonction selon l'un quelconque des modes particuliers de réalisation décrits en relation avec la figure 2, selon les instructions du programme d'ordinateur PG1.
Le dispositif DA comprend également des modules de réception RECV1 et RECV2 aptes recevoir des communications via par exemple un réseau IP et/ou circuit. Le module de réception RECV 1 est par exemple utilisé pour recevoir des requêtes en provenance d’une application de services comprenant au moins un identifiant d’un utilisateur. Le module de réception RECV2 est par exemple utilisé pour recevoir un message comprenant au moins une donnée correspondant à une adresse d’un dispositif d’un utilisateur.
Selon un mode particulier de réalisation de l’invention, les modules RECV1 et RECV2 peuvent être un seul et même module de réception.
Le dispositif DA comprend en outre des modules d’émission SND1 et SND2 aptes à émettre des communications via par exemple un réseau IP et/ou circuit. Le module d’émission SND1 est par exemple utilisé pour émettre, à destination d’une application inscrite à une chaîne de blocs, une requête comprenant au moins un identifiant d’un utilisateur. Le module SND2 est par exemple utilisé pour émettre, à destination d’une adresse d’un dispositif utilisateur, une requête permettant l'émission d’un message, vers une adresse d’une application de services comprenant au moins une donnée d’authentification d’un utilisateur. Selon un mode particulier de réalisation de l’invention, les modules SND1 et SND2 peuvent être un seul et même module de réception.
Selon un mode particulier de réalisation de l’invention, les modules RECV1, RECV2, SND1 et SND2 peuvent être un seul et même module de communication COM1 (non représenté).
Selon un mode particulier de réalisation de l’invention, le module de communication COM1 peut aussi être utilisé pour recevoir, en provenance d’une application de services, une requête d’attributs d’un utilisateur et comprenant au moins une donnée d’authentification et un identifiant de l’utilisateur.
Selon un mode particulier de réalisation de l’invention, le module de communication COM1 peut aussi être utilisé pour émettre à destination d’une adresse d’un dispositif de l’utilisateur une requête d’attributs de l’utilisateur, l’adresse du dispositif ayant été obtenue en fonction d’un identifiant de utilisateur par exemple via une application inscrite à une chaîne de blocs ou depuis un espace de stockage numérique tel qu’une base de données, un fichier ou une mémoire. Le module de communication COM1 peut également être utilisé pour recevoir une réponse à la requête d’attributs, la réponse comportant au moins un attribut de Putilisatcur ou un message de statut tel qu’un code d’erreur.
Selon un mode particulier de réalisation de l’invention, le module de communication COM1 peut aussi être utilisé pour émettre à destination d’une application de services, une réponse à la requête d’attributs provenant de l’application de services, comportant au moins une donnée telle qu’un code d’erreur, un statut, un identifiant de transaction, un attribut, etc.
Selon un mode particulier de réalisation de l’invention, le dispositif DA comprend un module d’obtention (OBT) apte à obtenir depuis une entité de confiance au moins une donnée, dite preuve, obtenue par application d’une fonction Fl à un ou plusieurs attributs de l’utilisateur. La fonction Fl est par exemple une fonction permettant de créer un hash et/ou une fonction permettant le chiffrement et/ou une fonction permettant de signer le ou les attributs de l’utilisateur. Elle peut être exécutée par exemple par l’entité de confiance ou bien par un dispositif utilisateur ou tout autre dispositif apte à fournir la ou les preuves à l’entité de confiance.
Selon un mode particulier de réalisation de l’invention, le dispositif DA comprend un module de génération (GEN) apte à générer la ou les preuves, par application de la fonction Fl à un ou plusieurs attributs de l’utilisateur reçus via le module COM1. La ou les preuves générées peuvent être ensuite comparées par le module de comparaison (COMP) aux preuves obtenues via le module d’obtention OBT. Si le résultat de la comparaison est positif alors les attributs sont considérés comme valides. Dans le cas contraire les attributs sont considérés comme non valides.
Selon un mode particulier de réalisation de l’invention, le dispositif DA comprend un module (non représenté) permettant le déchiffrement des preuves obtenues. Ce mode de réalisation permet par exemple de déchiffrer les preuves obtenues avant de pouvoir les comparer aux preuves générées par le dispositif DA.
Selon un mode particulier de réalisation de l’invention, les modules COM1 et OBT peuvent être un seul et même module de communication. En référence à la figure 2, nous allons maintenant décrire les principales étapes E20, E21, E22, E23, E25, E26, E27, E28 et E29 d’un procédé d’authentification selon des modes de réalisation de l’invention.
La figure 2 est constituée d’un terminal T comme par exemple un terminal mobile, une clef USB (Universal Serial Bus), un objet connecté ou un ordinateur apte à obtenir et fournir des données par exemple chiffrées d’un utilisateur permettant son authentification comme par exemple des jetons d’authentification ou des données personnelles. La figure 2 comprend également un dispositif BC inscrit à une chaîne de blocs par exemple apte à exécuter des fonctions décentralisées ou DApps au sens de la technologie des chaînes de blocs mais aussi un dispositif SA tel qu’un serveur, un ordinateur personnel, un objet connecté ou tout autre terminal apte à fournir un service à un utilisateur. Elle est en outre constituée d’un dispositif DA apte à exécuter le procédé d’authentification au sens de l’invention.
Au cours d’une première étape E10, le dispositif SA envoie une demande d’authentification au dispositif DA. Cette demande fait suite à une requête émise par un terminal d’un utilisateur pour accéder à un service fourni par le dispositif DA.
A l’étape E20 le dispositif d’authentification DA reçoit la demande d’authentification qui peut comprendre plusieurs paramètres tel qu’un identifiant de l’utilisateur souhaitant accéder au service fourni par le dispositif SA, un numéro de transaction, un identifiant de service, un identifiant du dispositif SA, une adresse du dispositif SA, une plage horaire, ou tout autre information liée au service ou à l’utilisateur.
A l’étape E21, le procédé d’authentification va émettre à destination du dispositif BC une requête comprenant au moins un identifiant de l’utilisateur récupéré lors de l’étape E20. La requête est ensuite reçue par le dispositif BC à l’étape E31.
A l’étape E32, le dispositif BC va renvoyer au dispositif DA une réponse contenant une adresse, comme par exemple une adresse MAC ou une adresse IP, d’un terminal T appartenant à l’utilisateur. L’adresse du terminal T correspond à une première donnée au sens de l’invention. Cette adresse est sélectionnée par le dispositif BC en fonction de l’identifiant de l’utilisateur reçu à l’étape E31.
Selon un mode particulier de réalisation de l’invention, le dispositif BC peut envoyer une réponse comprenant une liste d’adresses de dispositifs de l’utilisateur, cette liste pouvant par exemple être ordonnée, la première adresse étant par exemple celle à utiliser par défaut. Les adresses peuvent également être associées à une donnée indiquant la nature des données qu’il est possible d’obtenir via chaque dispositif utilisateur (donnée d’authentification, attributs utilisateurs, etc.).
La réponse du dispositif BC est ensuite reçue par le dispositif DA à l’étape E22. Une fois l’adresse du terminal T reçue par le dispositif DA, celui-ci va émettre (E23) à destination de l’adresse du terminal T une requête de redirection, c’est-à-dire une requête demandant au terminal T d’émettre à son tour un message, à destination du dispositif SA. La requête émise par le dispositif DA à l’étape E23 et reçue par le terminal T à l’étape E43, peut comprendre des paramètres tels que l’identifiant du service fourni par le dispositif SA et/ou l’adresse du dispositif SA et/ou toute autre information telle qu’un paramètre fourni par le dispositif SA et reçu par le dispositif DA lors de l’étape E20. Le message émise par le terminal T à l’étape E44 et reçue par le dispositif SA à l’étape E14 comprend au moins une donnée d’authentification de l’utilisateur comme par exemple une donnée personnelle ou un jeton d’ authentification.
A noter que les données d’authentification peuvent être générées au niveau du terminal T via par exemple des données collectées par un capteur biométrique utilisé pour obtenir une empreinte digitale, un iris, un visage, une voix, etc. de l’utilisateur.
Selon un mode particulier de réalisation de l’invention, la donnée d’authentification peut varier en fonction d’un ou de plusieurs paramètres par exemple reçus par le terminal T à l’étape E43 et/ou obtenus par le terminal T comme par exemple l’heure courante obtenue via une horloge interne au dispositif T. Dans le cas où l’un des paramètres est un paramètre de la requête reçue lors de l’étape E43, celui-ci peut être un paramètre reçu précédemment par le dispositif DA lors de l’étape E20 tel qu’une plage horaire, un identifiant du service ou du dispositif SA.
Selon un mode particulier de réalisation de l’invention, le dispositif SA émet lors de l’étape E15 une demande d’attributs de l’utilisateur à destination du dispositif DA. La requête comprend au moins une donnée d’authentification reçue par le dispositif SA lors de l’étape E14 et un identifiant de l’utilisateur qui est par exemple le même que celui transmis dans la requête émise par le dispositif SA lors de l’étape E10. Elle peut comprendre également d’autres paramètres comme un identifiant de service exécuté par le dispositif SA, un numéro de transaction, un identifiant du dispositif SA, ou tout autre information liée au service. Le dispositif DA reçoit la requête à l’étape E25 et va à l’étape E26 émettre une requête d’attributs à destination d’un dispositif de l’utilisateur. Cette requête d’attributs peut comprendre des paramètres reçus du dispositif SA lors de l’étape E25. La requête est reçue à l’étape E46 par le dispositif utilisateur qui est dans le cas décrit à l’appui de la figure 2 le terminal T.
Selon une variante de ce mode de mise en œuvre particulier, le dispositif utilisateur qui reçoit la requête d’attribut (E46) peut être différent du dispositif utilisateur qui reçoit la requête de redirection (E43).
A l’étape E47, le terminal T transmet au dispositif DA un ou des attributs de l’utilisateur.
Les attributs sont par exemple fonction d’un identifiant de service, d’un numéro de transaction, d’un identifiant du dispositif SA, ou tout autre information liée au service et reçue lors de l’étape E46. Le dispositif DA reçoit le ou les attributs de l’utilisateur à l’étape E27 puis va le ou les transmettre au dispositif SA lors de l’étape E29. Le ou les attributs sont ensuite reçus par le dispositif SA à l’étape El 9.
Selon un mode particulier de réalisation de l’invention, le dispositif DA peut, après avoir récupéré les attributs de l’utilisateur (E27), déchiffrer via par exemple une clef partagée avec le terminal T les attributs avant de les transmettre au dispositif SA (E29).
Selon un mode particulier de réalisation de l’invention, le dispositif DA peut, après avoir récupéré les attributs de l’utilisateur (E27), vérifier la signature des attributs via par exemple une clef partagée avec le terminal T avant de les transmettre au dispositif SA (E29).
Les processus de chiffrement et/ou de signature des attributs par des clefs partagées entre le terminal T et le dispositif DA sont des procédés connus de l’état de l’art et de ce fait ne sont pas décrits plus en détail ici.
Selon un mode particulier de réalisation de l’invention, le dispositif DA peut obtenir depuis une entité de confiance (non représentée) un ou plusieurs hash d’un attribut, de plusieurs attributs ou d’une concaténation d’attributs de l’utilisateur. Le dispositif DA va alors calculer le hash d’un attribut, de plusieurs attributs ou d’une concaténation d’attributs récupérés de l’utilisateur lors de l’étape E27 en appliquant la même fonction que celle qui a permis de générer le ou les hash obtenus depuis l’entité de confiance. Le dispositif va ensuite, lors de l’étape E28, comparer le ou les hash calculés avec ceux obtenus de l’entité de confiance. Si le résultat de la comparaison est positif alors les attributs sont considérés comme valides. Dans le cas contraire les attributs sont considérés comme non valides et un message d’erreur comme par exemple un code est renvoyé au dispositif SA lors de l’étape E29. Il va de soi que le mode de réalisation qui a été décrit ci-dessus a été donné à titre purement indicatif et nullement limitatif, et que de nombreuses modifications peuvent être facilement apportées par l’homme de l’art sans pour autant sortir du cadre de l’invention.

Claims

REVENDICATIONS
1. Procédé d’authentification d’un utilisateur auprès d’au moins une application, dite application de services, ledit utilisateur étant équipé d’un dispositif utilisateur possédant au moins une adresse et étant apte à obtenir au moins une donnée d’authentification dudit utilisateur, le procédé étant mis en œuvre par un dispositif d’authentification d’un utilisateur et caractérisé en ce qu’il comprend :
- une étape de réception (E20), en provenance de ladite au moins une application de services, d’une requête comprenant au moins un identifiant dudit utilisateur ;
- une première étape d’émission (E21), à destination d’une application inscrite à une chaîne de blocs, d’une requête comprenant ledit au moins un identifiant dudit utilisateur ;
- une deuxième étape de réception (E22), en réponse à l’étape d’émission, d’un message comprenant au moins une première donnée correspondant à une première adresse dudit dispositif utilisateur, ladite au moins une première donnée ayant été obtenue en fonction dudit au moins un identifiant dudit utilisateur ;
- une deuxième étape d’émission (E23), à destination de ladite première adresse, d’une requête pour émettre un message comprenant ladite au moins une donnée d’authentification dudit utilisateur vers une adresse de ladite application de services.
2. Procédé d’authentification selon la revendication 1 dans lequel la première étape d’émission est suivie :
- d’une troisième étape de réception, en provenance de ladite application de services, d’une requête d’attributs dudit utilisateur, ladite requête comprenant ladite au moins une donnée d’authentification et ledit au moins un identifiant dudit utilisateur ;
- d’une troisième étape d’émission, à destination d’une deuxième adresse d’un dispositif dudit utilisateur obtenue en fonction dudit au moins un identifiant dudit utilisateur, d’une requête d’attributs dudit utilisateur ;
- d’une quatrième étape de réception d’une réponse à la requête d’attributs, la réponse comportant au moins un attribut dudit utilisateur ;
- d’une quatrième étape d’émission, à destination de ladite application de services, d’une réponse à la requête d’attributs, la réponse comportant au moins une deuxième donnée.
3. Procédé d’authentification selon la revendication 2 dans lequel la quatrième étape d’émission est précédée : - d’une étape d’obtention, depuis une entité de confiance, d’au moins une troisième donnée obtenue par application d’une fonction audit au moins un attribut dudit utilisateur;
- d’une étape de génération d’au moins une quatrième donnée obtenue par application de ladite fonction audit au moins un attribut dudit utilisateur reçu lors de la quatrième étape de réception ;
- d’une étape d’ajout dudit au moins un attribut dudit utilisateur au contenu de ladite au moins une deuxième donnée en fonction du résultat de la comparaison de ladite au moins une troisième donnée avec ladite au moins une quatrième donnée.
4. Procédé d’authentification selon la revendication 3 dans lequel l’entité de confiance est une application inscrite à une chaîne de blocs.
5. Procédé d’authentification selon les revendications 2 ou 3 dans lequel ladite première adresse correspond à ladite deuxième adresse dudit dispositif utilisateur.
6. Procédé d’authentification selon la revendication 3 dans lequel ledit au moins un attribut est une donnée chiffrée et en ce que l’étape de génération est précédée d’une étape de déchiffrement dudit au moins un attribut.
7. Dispositif d’authentification d’un utilisateur auprès d’au moins une application, dite application de services, ledit utilisateur étant équipé d’un dispositif utilisateur apte à obtenir au moins une donnée d’authentification dudit utilisateur, et caractérisé en ce qu’il comprend :
- un module de réception d’une requête en provenance de ladite au moins une application de services comprenant au moins un identifiant dudit utilisateur ;
- un module d’émission à destination d’une application inscrite à une chaîne de blocs d’une requête comprenant ledit au moins un identifiant dudit utilisateur ;
- un deuxième module de réception d’un message de réponse, en provenance de ladite application inscrite à une chaîne de blocs, comprenant au moins une première donnée correspondant à une première adresse dudit dispositif utilisateur, ladite au moins une première donnée ayant été obtenue en fonction dudit au moins un identifiant dudit utilisateur ;
- un deuxième module d’émission, à destination de ladite première adresse, d’une requête pour émettre un message, vers une adresse de ladite application de services, comprenant ladite au moins une donnée d’authentification dudit utilisateur.
8. Serveur caractérisé en ce qu’il comporte un dispositif d’authentification selon la revendication 7.
9. Programme d'ordinateur comportant des instructions pour la mise en œuvre du procédé selon l’une quelconque des revendications 1 à 6, lorsque le programme est exécuté par un processeur.
EP21720811.5A 2020-03-30 2021-03-29 Procede et dispositif d'authentification d'un utilisateur aupres d'une application Pending EP4128700A1 (fr)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
FR2003133A FR3108818A1 (fr) 2020-03-30 2020-03-30 Procédé et dispositif d’authentification d’un utilisateur auprès d’une application.
PCT/FR2021/050549 WO2021198606A1 (fr) 2020-03-30 2021-03-29 Procede et dispositif d'authentification d'un utilisateur aupres d'une application

Publications (1)

Publication Number Publication Date
EP4128700A1 true EP4128700A1 (fr) 2023-02-08

Family

ID=74205885

Family Applications (1)

Application Number Title Priority Date Filing Date
EP21720811.5A Pending EP4128700A1 (fr) 2020-03-30 2021-03-29 Procede et dispositif d'authentification d'un utilisateur aupres d'une application

Country Status (4)

Country Link
US (1) US20230130191A1 (fr)
EP (1) EP4128700A1 (fr)
FR (1) FR3108818A1 (fr)
WO (1) WO2021198606A1 (fr)

Family Cites Families (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
FR2985149A1 (fr) * 2011-12-23 2013-06-28 France Telecom Procede d'acces par un terminal de telecommunication a une base de donnees hebergee par une plateforme de services accessible via un reseau de telecommunications
EP3120591B1 (fr) * 2014-03-17 2019-09-25 Telefonaktiebolaget LM Ericsson (publ) Dispositif sur la base d'un identifiant d'utilisateur, système de gestion d'identité et d'activité
RS56400B1 (sr) * 2014-07-07 2017-12-29 Finpin Tech Gmbh Postupak i sistem za autentifikaciju korisnika

Also Published As

Publication number Publication date
FR3108818A1 (fr) 2021-10-01
US20230130191A1 (en) 2023-04-27
WO2021198606A1 (fr) 2021-10-07

Similar Documents

Publication Publication Date Title
EP2884716B1 (fr) Mécanisme d'authentificaiton par jeton
EP2494489B1 (fr) Procédé et agent client pour contrôler l'utilisation d'un contenu protégé
FR2930390A1 (fr) Procede de diffusion securisee de donnees numeriques vers un tiers autorise.
WO2006021661A2 (fr) Procede d'authentification securisee pour la mise en œuvre de services sur un reseau de transmission de donnees
EP2301187A1 (fr) Terminal d'authentification forte d'un utilisateur
WO2019115943A1 (fr) Technique de protection d'une clé cryptographique au moyen d'un mot de passe utilisateur
EP1794926A1 (fr) Systeme et procede cryptographique a cle publique et serveur de certification, memoires adaptees pour ce systeme
EP3732849B1 (fr) Procédé et système d'identification de terminal d'utilisateur pour la réception de contenus multimédia protégés et fournis en continu
EP4128700A1 (fr) Procede et dispositif d'authentification d'un utilisateur aupres d'une application
EP4241416A1 (fr) Procede de delegation d'acces a une chaine de blocs
EP3899765B1 (fr) Réinitialisation d'un secret applicatif au moyen du terminal
WO2012156365A1 (fr) Procede de securisation d'une platforme d'authentification, dispositifs materiels et logiciels correspondants
WO2021240098A1 (fr) Procede de delegation de la livraison de contenus a un serveur cache
EP1992104B1 (fr) Authentification d'un dispositif informatique au niveau utilisateur
WO2024089378A1 (fr) Procede et dispositif de stockage en ligne reparti de fichiers dans un contexte zero confiance
EP4362391A1 (fr) Procédé de gestion d'accès d'un utilisateur à au moins une application, programme d'ordinateur et système associés
WO2022208016A1 (fr) Procédé et système informatique de stockage decentralisé et de partage de fichiers numériques certifiés
EP4160987A1 (fr) Procédé pour générer une signature électronique au moyen du protocole fido
FR2888437A1 (fr) Procede et systeme de controle d'acces a un service d'un fournisseur d'acces implemente sur un serveur multimedia, module, serveur, terminal et programmes pour ce systeme
FR2927750A1 (fr) Terminal de paiement electronique pour l'echange de donnees securise sur un reseau ouvert
FR2862827A1 (fr) Procede de gestion de donnees de securite
EP1649657A1 (fr) Procede et dispositif d'accreditation d'un utilisateur a un fournisseur de services
FR2880703A1 (fr) Procede d'identification d'utilisateur, de creation d'un document de partage et de service correspondant dans un systeme de partage d'un reseau pair a pair

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: 20221028

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 MK MT NL NO PL PT RO RS SE SI SK SM TR

DAV Request for validation of the european patent (deleted)
DAX Request for extension of the european patent (deleted)
RAP3 Party data changed (applicant data changed or rights of an application transferred)

Owner name: ORANGE